Определяем цели и задачи бизнес-заказчиков, выявляем потребительские боли. Проводим серию интервью, формируем видение проекта и верхнеуровневый план развития.
Конкурентный анализ и бенчмаркинг — важная часть исследования: оцениваем сильные и слабые стороны исследуемой системы, разрабатываем рекомендации по стратегии её развития.
Пользовательский анализ:
Определяем целевую аудиторию, обозначаем приоритетные сегменты. Собираем требования у пользователей системы и анализируем их боли посредством глубинных интервью и анкетирования.
Проводим анализ систем веб-аналитики и технического состояния сайта на предмет ошибок интерфейса и функционала, составляем список рекомендаций.
Мы берём интервью у рабочей группы заказчика, собираем брифы и общаемся с IT-службой клиента.
Из этой работы рождается Техническое задание: документ, по которому будет сдаваться сайт. Также мы делаем визуализацию — рисуем интерактивные прототипы будущего сайта.
Это последовательная модель разработки: ТЗ, прототипы, дизайн, верстка, программирование, 2 цикла тестирования и сдача.
Пример: портал HOFF Time с несколькими интеграциями, онбордингом и геймификацией. Запустили портал за 5 месяцев.
Срочная
Здесь этапы идут параллельно, например, отрисовав только главную страницу сайта, мы уже отдаем ее на верстку. Или сверстав половину макетов — начинаем их внедрение. Позволяет сэкономить срок в два раза, но и стоит на 50-100% дороже.
Пример: eCom для VIVO — параллельная разработка сайта и личного кабинета + параллельное выполнение этапов работ (2 и 3 месяца соответственно на сайт и ЛК).
Agile (T&M)
Гибкая методология, идеально подходит для корпоративных порталов, где правильнее утверждать и делать по одной задаче, чем полгода проектировать то, что к моменту утверждения устареет. Agile состоит из недельных спринтов, причем каждую неделю можно управлять разработкой и менять вектор развития проекта.
Мы пишем специальный документ: программу и методику испытаний. По ней проводится сдача системы. Также при сдаче проекта мы пишем автотесты (Selenium), далее в Allure смотрим наглядные отчеты по их прохождению.
Нагрузочное тестирование выполняется на сервере Заказчика, мы используем Яндекс.Танк и еще ряд сервисов.
После сдачи мы сопровождаем проект, используя Jenkins для continuous integration — непрерывной отгрузки обновлений, и GIT для контроля версий.
Контроль рисков
В процессе написания техзадания мы формируем схему блоков сайта с зависимостями: это позволяет программировать поэтапно, а также давать параллельные задачи программистам.
С помощью системы контроля версий на проект можно поставить сразу несколько программистов, причем их изменения легко отслеживать. Эта же технология применяется и при дальнейшей поддержке сайта.
При сдаче проекта мы применяем как автоматическое, так и ручное тестирование, чтобы все предусмотреть.
На этом этапе мы работаем с IT-службой Заказчика: разрабатываем API обмена, проектируем каналы обмена данными. Результат: одно- или двусторонний обмен с 1С, ERP, AXAPTA, SAP и еще 20+ менее известными системами учета и автоматизации.
Мы настроим Вам CRM (Битрикс24, AMOCrm или RetailCRM), после чего у Вас будут детальные отчеты по продажам, «нарезка» по разным типам Клиентов — для SMS и e-mail рассылок, а также аналитика по прибыли в разрезе источников рекламы и типов товаров/услуг.
У нас свои инженеры DevOps: построим оптимальную схему развертывания обновлений, настроим кластер, проведем нагрузочное тестирование. А после запуска проекта - обеспечим надзор 24/7.
С помощью соблюдения внутренних стандартов нам удается поддерживать высокое качество продуктов.
Именно поэтому мы даем бессрочную гарантию на наш код. Кроме того, наши проекты не были взломаны и не подвергались утечкам данных за все 16 лет нашей работы.
Ниже приведены (частично) регламенты из наших внутренних документов.
Регламент качества кода
1. Установка продукта. Настройка основной площадки перед началом работ
Перед стартом начала работ важно правильно настроить основную площадку (main), чтобы при создании площадок для разработки уже всё было настроено.
1.1. Установка и проверка bitrix перед стартом работ
Сайт устанавливается СТРОГО в кодировке UTF-8. ПРОВЕРКА: при проверке сайта (Инструменты — проверка системы) шестым пунктов проверки должно выводиться «Параметры настройки UTF». Сайт ни в коем случае не ставится на демо-ключе. Ключ в обязательном порядке запрашивается у менеджера проекта, в случае непредставления проект останавливается. ПРОВЕРКА: Marketplace — обновление платформы — посмотреть ключ. Сразу после установки необходимо зайти в обновления и установить все обновления системы. ПРОВЕРКА: зайти и поставить самому. После разворачивания сайта необходимо пройти проверку системы и проверку тестирования конфигурации /bitrix/admin/site_checker.php?lang=ru. Ошибок и предупреждений не должно быть. По умолчанию агенты на тестовых площадках Extyl должны выполняться на хитах, а на бою переведены на cron (тимлид проекта решает когда на тесте надо перевести агента на cron). Запрет отправки почтовых сообщений на тестовой площадке. Если на странице задана константа ONLY_EMAIL и email из настроек почтового шаблона с ее значением не совпадает, то письмо не отсылать. Если мы хотим запретить отсылать сообщения на всем сайте, то необходимо в файле bdconn.php установить константу define("ONLY_EMAIL", "[email protected]").
1.2. Настройка robots.txt после разворачивания сайта. SEO. Первейшие вещи
Сразу после установки необходимо в robots.txt прописать правило:
User-Agent: *
Disallow: /
#Все другие правила удалить – запрещена индексация сайта; во время запуска сайта файл должен быть изменен (должны быть запрещены к индексации только системные папки, такие как bitrix, upload, auth и т.п.).
1.3. Установка модуля миграций сущностей БД
Для переноса изменения из БД теста на бой или наоборот, надо сразу установить модуль миграции для разработчиков. . Перенос изменений руками или отдельным файлом является грубой ошибкой. При создании любого инфоблока, формы и т.д, даже если нет боя, необходимо создавать миграцию.
1.4. Установка и настройка GIT на проекте
В современных реалиях без GIT не может существовать не один проект, даже очень маленький. Все аргументы разработчиков не использовать GIT говорят лишь о незнаниях данной системы и о низкой квалификации данного разработчика. GIT — это не только правило хорошего тона, но и суровая необходимость современного подхода к разработке. Сразу после установки надо установить GIT на проект и настроить правильно .gitignore. Пример настройки .gitignore:
Если в .gitignore положили всю папку /bitrix, но нам нужно работать с каким-то шаблоном, то его можно вернуть в git при помощи:
!/bitrix/templates/learning_10_0_0/ .
.gitignore может быть изменен и дополнен в зависимости от потребностей проекта.
robots.txt, как и sitemap*.xml, .htaccess должен быть в .gitignore на бою и всех тестовых площадках.
На предпроде должна быть включена ветка stage, а на бою master. В ветках stage и master мы не работаем.
Все ненужные страницы и разделы необходимо удалить перед первым коммитом.
В GIT не должны попадать отладочные скрипты, логи, медиафайлы регистрируемые в БД и др.
Очень важно первично правильно настроить GIT и сделать площадку main (stage) чистой без не закоммиченных файлов. Далее эта площадка будет копироваться на тестовые хосты и если не выполнить эти предписания, то будет куча проблем.
1.5. Установка и настройка PHP Linter на проекте
На каждом проекте в обязательном порядке устанавливается — Linter: Code Sniffer.
2. Правила разработки продукта
2.1. Требования к юзабилити разрабатываемых продуктов
При разработке нового или доработке существующего функционала не должна теряться функциональность и удобство использования штатного функционала. При разработке нового или доработке существующего функционала обязательно думаем о удобстве администрирования (редактирования, добавления) контента на сайте. С готовым продуктом будет работать обычный человек, а не программист. Источники данных должны быть максимально информативно называться в административной части портала. Везде в публичке сайта должны работать визуальные редакторы для наполнения и редактирования контента, включаемых областей и др. Все должно быть предельно просто для заказчика.
2.2. Правила написания PHP-кода на проекте.
В общем случае обязательно использование API Bitrix (вместо PHP-кода). Если у bitrix есть функционал заменяющий чистый PHP, то надо использовать именно первое. Пример: $_GET, $_POST, $_REQUEST - использовать запрещено! Прямые запросы к БД - использовать запрещено! При разработке использовать ядро D7, т.к. старое ядро устарело и битрикс настаивает на использовании именно его. Названия переменных должны быть осмысленные, переменных типа «a», «tempconst» и т.п. быть не должно. ПРОВЕРКА: достаточно посмотреть /local/php_interface/ - и файлы php внутри. В компонентах недопустимо использовать ID-инфоблоков и ID-свойств. Необходимо динамически через хелпер получать по коду инфоблока или по коду свойства ID инфоблока или свойства (про свойство если такое надо) Необходимо придерживаться строгому регламенту стиля написания кода - Регламент по стилю написания кода (ТО) Придерживание MVC-подхода, если такой не противоречит общим правилам разработки Bitrix.
2.3. Инфоблоки их создание и настройка
В настройках инфоблока необходимо выбирать хранение свойств в отдельной таблице. Все инфоблоки – каталог, новости и т.п., должны быть изначально настроены с ЧПУ (автоматическая транслитерация русских слов), используя штатные средства Битрикс. ПРОВЕРКА: Контент – инфоблоки – типы инфоблоков. Смотрим поле «URL страницы детального просмотра» и URL раздела – адреса должны быть ЧПУ-вида (без знаков вида «?ID=#ID#» - вот этот знак вопроса показывает, что это параметр, такого быть не должно). При создании нового инфоблока необходимо также настроить административную панель, а именно: отображение только тех свойств, которые реально применяются на сайте (например, если анонсовое описание не используется – скрываем его), сами же свойства нужно сгруппировать, если это применимо. А сами актуальные свойства необходимо назвать так, чтобы было понятно, зачем они нужны, пример: «описание товара в карточке товара» вместо «детальное описание». Созданные инфоблоки должны быть разбиты по типам с корректным названием. Например инфоблок «Баннеры» не должен иметь тип «Новости». В каждом инфоблоке нужно вдумчиво пометить те свойства, которые должны участвовать в поиске. Например, для каталога товаров это артикул и большая часть свойств и т.д.
2.4. Шаблоны сайта и интеграция верстки
Вся разработка на сайте с ноля ведется в папке /local. Папка /bitrix должна быть в .gitignore . Все ненужные страницы и разделы необходимо удалить перед началом работы включая лишние шаблоны в папке /bitrix/templates/. ПРОВЕРКА: сначала в разделе «Настройки» - «Сайты» посмотреть, какие шаблоны используются. Затем в указанной выше папке посмотреть и описать, что лишнее (НЕ УДАЛЯТЬ). Примечание: .default – шаблон по умолчанию, удалять не надо. При интеграции вёрстки (имеется ввиду разработка сайта с нуля) файлы стилей, скриптов, картинок необходимо разместить в папке шаблона (css, js, images). ПРОВЕРКА: папка шаблона – это /local/templates/ИМЯ_ШАБЛОНА/ Не допускается вносить изменения в файлы css предоставленные верстальщиком. Если нужно поправить вёрстку необходимо прописать новые стили в другом файле (например style.css). ПРОВЕРКА: сравнить файлы по размеру и количеству строк. Как правило, этого достаточно. Блоки типа телефона, рекламного текста и т.д. необходимо сделать включаемой областью, причем она должна редактироваться как html только если там нет дивов, спанов и т.д. В противном случае она должна редактироваться как PHP. ПРОВЕРКА: зайти под админом на сайт, включить режим редактирования – посмотреть, как и что редактируется. Проверить, что все редактируется и ничего не ломается. У всех изображений должен быть прописан атрибут alt. Всегда! Это нужно для SEO. Например, для превью новости alt должен быть заголовок новости.
2.5. Модули (свои и стандартные – все)
В модулях надо использовать сервисный подход. Кто не знает что это такое, то срочно надо освежить знания.
2.6. Компоненты (свои и стандартные – все)
В компонентах недопустимо использовать ID-инфоблоков и ID-свойств. Необходимо динамически через хелпер получать по коду инфоблока или по коду свойства ID инфоблока или свойства (про свойство если такое надо). При интеграции шаблона компонента на сайт необходимо поддерживать интерфейс «Эрмитаж» (чтобы в режиме редактирования сайта можно было удалять, редактировать и добавлять элементы ИБ прямо на сайте, вне админки). ПРОВЕРКА: в режиме редактирования идем на страницу с инфоблоками – списки элементов, деталки элемента. При наведении мышки кроме штатной «шестеренки» настроек компонента должны появляться кнопки «добавить» «редактировать», «удалить» элемент. Пространство имен должно называться extyl-pro' Нестандартные модули и компоненты должны быть кратко документированы. Пример: Компонент extyl-pro:news.list (/local/components/), отличается от стандартного тем, что собирает данные из двух инфоблоков и внешней RSS-ленты. ПРОВЕРКА: идем в папку /bitrix/components/ - внутри, кроме папок «bitrix» не должно быть иных папок. Исключение – сторонние модули Marketplace. Смотрим их наличие в ТЗ или уточняем у менеджера проекта. Все собственные компоненты создаём в папке /local/components/extyl-pro/* Необходимо избегать кастомизацию компонентов в тех ситуациях, когда есть возможность обойтись без неё. В папке local/components/bitrix/ - не должно быть пространства имён bitrix ПРОВЕРКА: пробежаться по нестандартным компонентам – по названию должно быть понятно, где используются, и сравнить с ТЗ – где действительно они нужны.
2.7. Формы обратной связи и т.п.
Формы обратной связи и т.п. запросов – все – должны работать через модуль «Вебформы». В шаблонах web-форм не должно быть привязки к id-полей форм. ID-ники должны проставляться динамически. При переносе настроек web-форм мигратором id-на площадке разработки и бою будут различаться. Во всех формах нажатие кнопки «Enter» должно приводить к отправке формы, если в конце формы есть одна кнопка отправки (т.е. нет выбора отправить так или эдак). ПРОВЕРКА: зайти в «Сервисы» и далее соответственно в веб-формы или в баннеры. Увидеть там все формы и все баннеры сайта.
2.8. Баннеры
Все баннеры и т.п. сменяющиеся элементы (например, фон экрана) – должны работать через модуль «Баннеры». Исключения оговариваются до реализации, а не после.
2.9. Капча
Если используем кастомную капчу (Google и др.), то необходимо предусмотреть момент, что капча может отвалиться из-за всевозможных блокировок или сбоев у провайдеров. Необходимо на такой момент сделать автоматический перехват ошибок доступности капчи на беке и автоматическое переключение, в такиие моменты, на штатную битриксовую капчу при возникновении ошибок.
2.10. Наиболее частые ошибки
Тестирование осуществлялось под администратором.
Формы регистрации, авторизации, обратной связи и все прочие формы: если что-то введено неверно или НЕ введено обязательное поле – должна высвечиваться ошибка.
В полях форм name, id и других атрибутах, недопустимо жестко прописывать id полей. На предпроде и на бою id будут различаться. В шаблонах надо динамически по коду поля получать id.
Форма восстановления пароля должна работать корректно. Кнопка «Выход» должна быть и должна работать. После авторизации или регистрации мы должны возвращаться на ту же страницу, откуда пришли.
404 страница – должна быть, пусть даже в стандартном виде.
Файл /robots.txt не закрыт на тестовом сайте или имеет не правильные ссылки на бою.
Файл /sitemap.xml имеет ссылки на тестовую площадку, битые ссылки или ссылки, которые не должны находиться там.
3. Оценки на проектах
Перед стартом работ Тимлид в обязательном порядке оценивает (в часах) предстоящие работы.
4. Код-ревью на проектах
Код-ревью на проектах закреплен отдельным регламентом, который не противоречит общепринятыми правилами разработки.
5. Промежуточные тестирования и тестирования перед сдачей проекта
5.1. Перед проведением тестирования на сайте проверка критически важных настроек bitrix
В настройках главного модуля включены все галки /bitrix/admin/settings.php?lang=ru&mid=main:
Объединять CSS файлы (включено).
Объединять JS файлы (включено).
Подключать минифицированные версии CSS и JS файлов (включено).
Переместить весь Javascript в конец страницы (включено).
Создавать сжатую копию объединенных CSS и JS файлов (включено).
В настройках кеширования должно быть включено /bitrix/admin/cache.php?lang=ru:
Автокеширование компонентов (включено).
Управляемый кеш компонентов (включено).
5.2. Тестирование общих настроек системы
Ускорение сайта CDN – выключено (это в зависимости от проекта).
Включен и настроен веб-антивирус (ВАЖНО! В качестве действия включать только оповещение, НЕ вырезание кода и не замену на безопасный код!).
Отключаем модуль «Веб-Антивирус» — выключено (если это не противоречит ТЗ).
Отключаем модуль «Веб-аналитика» (если он не используется на сайте согласно ТЗ).
Проведен аудит сканером безопасности: /bitrix/admin/security_scanner.php при этом если ошибки в хостинге – необходимо оповестить об этом менеджера проекта через интранет (настройки хостинга не входят в задачи программирования).
Настроены корректные e-mail адреса (администратора сайта и для уведомлений) — эти данные необходимо запросить у менеджера проекта.
Шаблоны сайтов названы корректно и по ним (названию + описанию) понятно, зачем каждый шаблон. Не должно быть одинаково названных шаблонов. То же относится и к компонентам и к шаблонам компонентов.
Модули «Документооборот» и «Веб-аналитика» - удалены, если не используются.
Все иные модули, типа «Списки» — также удалены, если не используются.
/robots.txt - правильно настроен.
/sitemap.xml - имеет правильные ссылки.
5.3. Использование обезличенных данных при тестировании
Если в процессе тестирования делается заказ или регистрируется пользователь или заполняется формочка – обязательно в заказе/ФИО/форме писать «Тест», «Тестовый» и т.д. При создании страниц и разделов необходимо указывать их заголовки. Например, если создаётся раздел сайта «Новости», то в свойствах раздела и страницы следует указать название «Новости». ПРОВЕРКА: проверяем заголовки страниц сайта, чтобы не было ерунды и они не были пустыми.
5.4. Настройки пользователей пользователей для проведения тестирования
Пароль у главного администратора не должен быть простым. ПРОВЕРКА: простой пароль – это «123123», пароль, равный адресу почты и т.д. При необходимости – сменить пароль самостоятельно, отписать в задачу. Для синхронизации с 1С создается ОТДЕЛЬНЫЙ пользователь, по имени которого ясно, зачем он существует. ПРОВЕРКА: запросить менеджера, какой аккаунт используется для синхронизации с 1С. Лишние пользователи к моменту сдачи проекта должны быть удалены. ПРОВЕРКА: посмотреть, что по каждой группе, кроме «обычных» юзеров, есть не более 1 пользователя (учитывая, разумеется, пункт выше про 1С-пользователя). Группы пользователей должны соответствовать ТЗ — лишние должны быть удалены.
5.5. Тестирование скорости работы сайта
При сдаче проекта должны быть включены критические настройки сайта - 3.1. Перед проведением тестирования на сайте проверка критически важных настроек bitrix. Если ТЗ предусмотрен композит, то необходимо удостоверится, что он работает. ПРОВЕРКА: в настройках – автокэширование. Композит – внизу любого композитного сайта должен висеть шильдик («Быстро с 1С-Битрикс»). Если он не висит, то композит не работает. Работу композита нужно проверить установкой в браузер Chrome расширения "Bitrix Composite Notifier".
5.6. Проверка оптимизации запросов к БД
При сдаче проекта необходимо запустить отладку количества запросов к БД и объем используемого кеша. В интернет-магазине на главной странице под кешем, если больше 20 запросов к БД, то нужно оптимизировать кеширование и сами запросы. Без кеша более 200 запросов считается уже много. Избыточный кеш у компонента может так же тормозить проект, т.к. перед выводом система его парсит. У каждого показатели запросов и использования кода могут разнится в зависимости от ситуации. На картинке ниже мы видим, что можно отследить как общую статистику, так и статистику по каждому отдельному компоненту.
5.7. Проверка оптимизации изображений на сайте
На скорость работы сайта влияют не оптимизированные изображения. Разрешение изображения всегда должно быть не больше размера отведенного под него. Если это слайдер, то превьюшка также должна быть соответствующего разрешения.
5.7.1. Проверка общего размера страницы на сайте
Вес страницы может зависеть от размера изображений, видео, js и css файлов. Пример проверки скорости загрузки и веса страницы. Если общий вес страницы превышает 2 мегабайта (усредненное значение), в редких случаях за 5 и более, то изображения и скрипты не оптимизированы.
5.8. Проверка общей производительности разделов и скорости работы сайта штатными средствами bitrix и использовании JMeter. Обязательный минимум
5.8.1. Установка и настройка JMeter
Инструкция по установке — https://loadtestweb.info/2017/10/17/install-apache-jmeter/ . В офисе уже есть заряженный компьютер для нагрузочного тестирования. Если есть проблемы с установкой JMeter, то можно воспользоваться им (в том числе удаленно).
5.8.2. Подготовка сценария тестирования для JMeter
Пример запросов (для интернет-магазинов запросы должны содержать в том числе значения умного фильтра):
/bitrix/admin/perfmon_panel.php – в котором тестировать сайт в течение 5 и более минут, пройдясь за это время по всем основным страницам сайта по несколько раз. При обнаружении факта загрузки страницы более 2 секунд (в ТЗ будет указано более точное значение) необходимо внести изменения в код и оптимизировать такой код, либо обосновать время загрузки. После того, как в битриксе нажали тестирование, необходимо в JMeter нажать старт.
5.8.4. Анализ данных производительности
/bitrix/admin/perfmon_panel.php .
5.9. Прохождение стандартных тестов bitrix мастера проверки системы
При сдаче проекта необходимо пройти и настроить все пункты из мастера: /bitrix/admin/storeassist.php ПРОВЕРКА: все пункты должны соответствовать ТЗ. Если что-то не указано в ТЗ – писать в протоколе тестирования.
5.10. Монитор качества: прохождение дополнительных тестов
Проходим следующие тесты:
Интеграция дизайна и разработка.
Интеграция дизайна.
Цепочка навигации. Общие элементы.
Интеграция стандартных компонентов и модулей:
Настроены стандартные модули.
Интеграция собственных компонентов и модулей:
Компоненты используют кэширование.
Шаблоны компонентов – формируют верстку.
Объемный PHP-код оформлен в виде модуля.
Не используются вставки PHP-кода.
Безопасность:
Группам пользователей предоставлены минимально необходимые права.
5.11. Общие нюансы проверки всех сайтов
Главная страница должна иметь вменяемый Title (содержащий как минимум слова «Главная» и название компании; если применимо – скопировать его со старого сайта компании). То же относится к внутренним тестовым страницам ПРОВЕРКА: при необходимости уточнить адрес старого сайта у менеджера. У инфоблоков title должен быть равен названию инфоблока (для главной страницы – например, «Все новости»), либо названию раздела (для раздела каталога), либо названию товара (для карточки товара).
5.12. Нюансы проверки работы интернет-магазина
Список товаров: должны быть предусмотрены ситуации, когда товара нет в наличии, или когда нет цены – или товар не показывается, или отображается иконка/заглушка. Также в тестовых целях должны быть представлены (если есть в ТЗ): товар со старой ценой, акционной ценой, спецпредложение (шильдик в углу фотки товара или что-то подобное) – то есть все виды «спец» товаров. Карточка товара: должны быть предусмотрены ситуации, когда какое-либо из полей не заполнено. Также не должно быть пустых вкладок (если в карточке товара есть вкладки).
6. Проверка работы системы после переноса сайта на бой
6.1. Проверка работы системы после переноса сайта на бой всех сайтов
После переноса сайта на бой необходимо пройти проверку системы и проверку тестирования конфигурации /bitrix/admin/site_checker.php?lang=ru. Ошибок и предупреждений не должно быть. Не забываем, что агенты должны выполняться на cron (в том числе периодические если уместно). Для корректного переноса важно знать:
Не переносить папку .git средствами bitrix.
Не трогать папку .git.
Если происходят какие-то переносы площадок, после переноса проверить работоспособность git.
Нужно уточнять по возможности у клиента, что за изменения на бою.
Соблюдены все правила — 3.1. Перед проведением тестирования на сайте проверка критически важных настроек bitrix.
6.2. Проверка правильности настройки robots.txt и sitemap.xml на бою
Необходимо, что бы на бою был корректно настроен robots.txt и sitemap.xml сразу как заказчик даст отмашку открыть сайт для индексации поисковыми роботами. Можно уточнить у менеджера.
Стандарты Frontend
Правило оценки задач
Обязательно ставьте оценки к задачам
Если у задачи уже есть оценка другого разработчика, то переоцениваем, если не согласны с ней
Если вы выполняете задачу с чужой оценкой, то вы согласны с ней.
Правила разработки проектов
Разработка ведется в нашем gitlab
Результаты работы за день коммитим и отправляем в репозиторий каждый день. Не должно быть ситуаций, когда вы потеряли наработки за несколько дней по причинам: "сломался компьютер", "я переезжал и забыл скопировать" и другое.
Реквесты на слияние отдавайте вашему тимлиду или старшему фронту проекта на ревью.
Требования к качеству проектов
Общие требования
Браузеры
Chrome, Firefox, Safari, Edge
Точные версии браузеров, а также дополнительные версии, запрашивать у менеджера перед выполнением задачи, если они не указаны в ТЗ.
По умолчанию должна быть обеспечена поддержка двух последних версий браузеров.
Адаптивность
Сайт должен быть адаптивный
Изображения
Логотипы должны быть в SVG
На бою и тестовых площадках: У обычных изображений должны быть webp версии и их размер должен быть подходящим контейнеру (тег picture)
Юзабилити
Все ссылки должны реагировать на :hover, :active и :focus
При верстке статичных страниц(Детальная новостей) должна быть стилизована большая часть статичных элементов. Пример: ссылки, ul/ol списки, таблицы, заголовки.
При верстке статичных страниц изображения не нужно насильно растягивать во всю ширину. Добавляем к img стили: max-width: 100%, display: block, margin: 0 auto, padding: 10px, чтобы изображения имели естественный размер, но не могли превысить размер контейнера статичной страницы.
Ресайз textarea не должен ломать вёрстку
Футер должен быть «прибит» к низу браузера при отсутствии/малом количестве контента
Пагинация слайдеров не должна ломаться при большом количестве слайдов. Она должна переноситься или уходить вбок. Спрашивайте менеджера и дизайнера, как должно быть на текущем проекте
Должна работать валидация форм
Поле телефона должно использовать маску
Кнопка «отправить» формы должна блокироваться при первом нажатии для избежания множественной отправки. После получения ответа от сервера она должна разблокироваться.
Вывод сообщения об успешной/провальной отправке форм
Все элементы интерфейса, которые обновляют свои данные без перезагрузки страницы должны иметь прелоудер
У всех списков (Заявок, пользователей и тд) должна быть пагинация. Если это СПА, то в апи должно выдавать инфу с учетом пагинации
При создании живого фильтра (Фильтр работающий без нажатия на кнопку применить) использовать прерывание запроса
Информацию по сборке проекта и сложном функционале необходимо описывать в README.md файле проекта
Обязательно делаем всплывающее окно на сайте, если у клиента выключены cookies в браузере. Проверить можно JS'ом через navigator.cookieEnabled. Сообщение во всплывающем окне должно быть такое - "Для корректной работы сайта требуется включить cookies в браузере"
JS
Код должен быть написан согласно конфигурации ESLint проекта
Код должен быть разделен на модули. Название модулей должно отражать смысл содержимого
Библиотеки устанавливаются через yarn
Для создания слайдеров используем swiper
Если проект работает с api, то доменные адреса должны выноситься в переменные среды проекта. Файл .env.
Файл .env не должен быть под гитом
Создавайте файл .env.example с перечисленными обязательными переменными среды. У переменных должно быть описание
Отправка форм должна работать через FormData
CSS
БЭМ
Код должен быть разделен на модули. Название модулей должно отражать смысл содержимого
Дополнительные требования для SPA проектов
Юзабилити
Настройки фильтра каталога товаров должны отображаться в URL гет параметрами
Дополнительные требования для Статичной верстки
HTML
Верстка должна проходить W3C валидатор
Семантическая верстка. Как минимум title, description h1 заголовки.
К изображениям обязательно должны прописываться alt атрибуты
Названия и значения атрибутов (class="detail-page", id="news-list" и тд) должны быть именованы в стиле kebab-case
Контроль версий проекта: регламент работы с GIT
1. Перед началом работы
Мы работаем строго с GIT. Без GIT работа не производится.
2. Требования по настройке git
На общем хосте (main) должна быть включена ветка stage. Ветка master используется только для боевого хоста. Использовать только \n для перехода на новую строку. Проверьте, чтобы .gitignore был правильно настроен. Пример настройки .gitignore:
Если в .gitignore положили всю папку /bitrix, но нам нужно работать с каким-то шаблоном, то его можно вернуть в git при помощи: !/bitrix/templates/learning_10_0_0/ .gitignore может быть изменен и дополнен в зависимости от потребностей проекта. В GIT не должны попадать отладочные скрипты, логи, медиафайлы регистрируемые в БД и др. Все наработки проверяет тимлид / старший программист проекта. Уточнять главного программиста у менеджера. Разработчик не меняет в обход тимлида ветки master, stage, layout-master, layout-stage и ветки, созданные другими разработчиками. 1 разработчик - 1 хост. Если на проекте должно одновременно работать несколько разработчиков, то количество хостов на проекте должно быть равно количеству разработчиков + 1 (общий хост на который сливаются все изменения). За этим следит менеджер проекта, и ему надо сообщать, если требование не соблюдается. Все наработки разработчика сначала вливаются в stage, затем в master. Ничего не вливается сразу в master. Все новые ветки для выполнения новых задач начинаются от текущего stage. Доставкой изменений на бой занимается тимлид на проекте или его старший программист проекта.
3. Про перенос наработок и деплоев
3.1. Обязательный слив всех наработок в репозиторий во ВТ и ЧТ
Во вторник и четверг обязательный слив всех наработок в удаленный репозиторий. Наработки сливаются по мере готовности и в обязательном порядке во ВТ и ЧТ, даже если не закончен блок. Ответственный за контроль - Тимлид. Исполнитель данного мероприятия - разработчик. Разработчик до 19:00 во вторник и четверг должен отправить все наработки в репозиторий. Тимлид, в зависимости от потребности проекта, может изменить частоту обязательных сливов в репозиторий. Сделать чаще. Реже нельзя. Если нет дополнительных требований от тимлида, то обязательные сливы в репозиторий во вторник и четверг. За нарушение данного требования будет произведено депремирование. Если между дедлайнами сливов был непрерывный простой, то данное требование не работает.
3.2. Деплои на бой
Дни для деплоя - Пн, Вт, Ср, Чт с 10:00 до 16:00. Пт с 10:00 - 15:00. Исключения возможны только при выполнении срочных задач и по согласованию с менеджером проекта.
4. Создание и актуализация новой ветки перед выполнения новой задачи
Правила именования веток описаны в пункте 6. Актуализируем локальную ветку stage из удаленного репозитория. Cоздаем локальную ветку для разработки от stage.
5. Отчет о проделанной работе и подготовка к переносу наработок на предпрод для проверки
После выполнения наработок необходимо сделать git pull ... в текущую ветку из ветки stage удаленного основного репозитория и тем самым предотвратить появление конфликтов. Пушим ветку с наработками git push ... в свою же ветку удаленного репозитория. В удаленном репозитории создаем мерж реквест в stage на тимлида или старшему на проекте, если он отвечает за сливания. Прикладываем в пункт чек-листа или в комментарии к задаче, если его нет, ссылку на merge request с наработкой и комментарием, что это за наработка. Отписываемся тимлиду или старшему на проекте, если он отвечает за сливания, чтобы проверил работу и принял merge request, либо отправил на доработку. Если всё ок, то смотрим работу на тестовой площадке. Проверка наработок осуществляется только на тестовой площадке main! Примечание: по усмотрению тимлида проекта актуализация ветки может производиться от ветки master, а не stage.
6. Правила переноса наработок на бой
Если выполненную задачу нужно переносить на бой: Необходимо сделать git pull ... из ветки master удаленного основного репозитория и тем самым предотвратить появление конфликтов. Создаём новый merge request, только вливаем уже в master. Прикладываем в пункт чек-листа или в комментарии к задаче, если его нет, ссылку на merge request с наработкой и комментарием, что это за наработка. Также отписываемся тимлиду или старшему на проекте, если он отвечает за сливания, который всё это ещё раз проверяет, принимает изменения (тимлид и менеджер) и вытягивает изменения на бою. Проверяем функционал на бою. Для корректного переноса важно знать:
Не переносить папку .git средставими bitrix.
Не трогать папку .git.
Если происходят какие-то переносы площадок, после переноса проверить работоспособность git.
Нужно уточнять по возможности у клиента, что за изменения на бою.
7. Правила именования веток
7.1. Правильное название ветки
7.1.1. Если чек-листы большие
Название веток должны содержать номер задачи и чек-лист, в рамках которой выполняется работа и пункт чек-листа. То есть при выполнении задачи, ветка будет выглядеть следующим образом: ih/номерЗадачи-ЧекЛист/краткоеОписаниеЗадачи
Ih - значит inhouse, т.е. штатный сотрудник.
os - outstaff - подрядчик.
номерЗадачи - обязательно указываем номер задачи.
ЧекЛист - обязательно указываем номер чек-листа.
краткоеОписаниеЗадачи — это 2 - 4 слова.
Пример правильно названной ветки: ih/54361-3/updateCatalogStyles В ветках важно в коммитах писать номера задач и чек-листов: git commit -m "task-22333, buglist-1,2"
7.1.2. Если чек-листы маленькие и эти чек-листы не надо по отдельности переносить
Название веток должны содержать номер задачи. То есть при выполнении задачи, ветка будет выглядеть следующим образом: ih/номерЗадачи/краткоеОписаниеЗадачи
Ih - значит inhouse, т.е. штатный сотрудник.
os - outstaff - подрядчик.
номерЗадачи - обязательно указываем номер задачи.
краткоеОписаниеЗадачи — это 2 - 4 слова.
Пример правильно названной ветки: ih/54361/updateCatalogStyles В ветках важно в коммитах писать номера задач и чек-листов git commit -m "task-22333, buglist-1,2"
7.2. Название ветки с багами
7.2.1. Название ветки с багами одного пункта чек-листа
ih/54361-3/bugFix
7.2.2. Название ветки с багами всей задачи
#Данная ветка используется при массовой починке багов ih/54361/bugFix
7.3. Предельная ситуация при названии ветки
В случае, если работа по какой-то причине не привязана к конкретной задаче, именование следующее: ih/годмесяц/краткоеОписаниеЗадачи Пример альтернативно названной ветки если нет задачи под неё: ih/2107/checkoutRefactoring
8. Правила именования коммитов
Именование коммита должно отражать суть проделанной работы. В именовании коммита должен присутствовать номер задачи и номер пункта данной задачи. Пример: "54361-1 import elements to offers iblock" Где 54361-1 номер задачи и через тире номер пункта.
9. Если редактируемый файл не правильно отформатирован (PSR, переносы)
Если вам приходится работать с существующим кодом в файле и данный код не правильно отформатирован, то если мы сделаем доработку и отформатируем весь код файла, в коммите будет непонятно, что именно изменилось. Для того, что бы предотвратить данную проблему, необходимо:
Перед выполнением работ отформатировать данный файл, согласно регламенту написания кода (в PHPStorm можно комбинацией клавиш [CTRL] + [ALT] + L) и закоммитить, при этом в настройках PHPStorm должны стоять верные настройки PSR и версия PHP. В коммите указать, что это форматирование.
Начать выполнять работу только после коммита с форматированием.
10. Работа с версткой и стилями
Бэкендер не правит прямо в back-end ветке стили или вёрстку. Для работы с версткой используется отдельный репозиторий. Соблюдение правил работы со сборщиками.
11. Уточнения к правилам переноса правок на бой (частный случай к пункту 5)
Новая ветка должна актуализироваться каждый раз пред выполнением и в нее из ветки предпрода может подтянуться то, что еще нельзя переносить. Т.к. в данном проекте ожидается большая очередь переноса правок на бой и продолжительное время приемки нового функционала из разных блоков, необходимо:
В выполненном пункте задачи должны быть перечислены все коммиты (хеши), которые к нему относятся.
Осуществлять перенос целыми блоками на бой (логически завершенными блоками), а не отдельными его частями, чтобы предотвратить появление конфликтов и багов из-за пересечений в коммитах.
Перенос надо осуществлять релизными ветками вида: release/20210408 где 20210408 — сегодняшняя дата.
В релизную ветку наработки надо переносить командой: git cherry-pick коммит.
Надо находиться в ветке, в которую хотите перенести коммит командой git cherry-pick коммит. Если переносимого коммита нет в вашем локальном git, то надо сперва подтянуть изменения из других веток к себе в гит (команда в вашу ветку из других веток ни чего не вольёт) git fetch origin git fetch - забирает данные в ваш локальный репозиторий, но не сливает их с какими-либо вашими наработками и не модифицирует то, над чем вы работаете в данный момент. Вам необходимо вручную слить эти данные с вашими, когда вы будете готовы.
12. Команды, полезные тимлиду
12.1 Команда, что бы добавить новые изменения в последний коммит
Команда полезная, но не простая. После этого не получится push изменения в репозиторой. Сперва придется сделать pull и решить конфликты в добавленном файле
git add file
git commit --amend --no-edit
13. Иное
Во всех непонятных ситуациях необходимо обратиться за помощью к документации на первоисточника GIT. Если решение не нашлось, необходимо обратится за помощью к коллегам (программистам, тимлиду).
Безопасность
Общие требования
Проверка (экспертиза) эксплуатационной документации от вендора, сообщества на наличие информации о поддержке и обновлениях, включая устранение уязвимостей.
Идентификация и аутентификация
Для идентификации пользователей при доступе каждому пользователю должен быть назначен уникальный персональный идентификатор.
Доступ пользователей должен осуществляться посредством парольной аутентификации.
Должна обеспечиваться защита обратной связи при вводе аутентификационной информации.
Локальная парольная политика должна удовлетворять требованиям:
политика сложности пароля;
хранение истории паролей;
установка срока действия пароля;
возможность смены пароля при первом входе;
возможность самостоятельной смены пароля
Возможность интеграции с системой управления идентификационными данными.
Авторизация пользователей на доступ должна производиться только после прохождения процедур идентификации и аутентификации.
Поддержка механизмов многофакторной аутентификации.
Управление доступом.
Управление доступом
Должна использоваться система ролевого управления доступом для управления правами доступа пользователей Поддержка возможности наследования прав доступа.
Подсистема разграничения доступа должна позволять предоставлять права доступа в минимально необходимом объеме.
Должен быть ограничен доступ к интерфейсу администрирования, конфигурационным и временным файлам.
Должен обеспечиваться запрет действий пользователей до прохождения процедуры идентификации и аутентификации (анонимное подключение должно быть запрещено).
Должно обеспечиваться разграничение доступа между компонентами.
Должно обеспечиваться ограничение неуспешных попыток входа.
Должна обеспечиваться автоматическая блокировка сессии после установленного периода неактивности (бездействия), восстановление сессии должно осуществляться только после повторной аутентификации пользователя.
Регистрация и учет событий ИБ
Наличие механизмов регистрации и учета событий ИБ.
Должен быть предусмотрен централизованный интерфейс для работы с журналами событий безопасности.
Подсистема регистрации и учета событий ИБ должна обеспечивать:
регистрацию даты и времени входа/выхода, попытки входа пользователя;
регистрацию даты и времени запуска/остановки компонент;
регистрацию изменения полномочий пользователей;
регистрацию изменения настроек;
регистрацию действий администраторов;
регистрацию действий пользователей
Должен использоваться уникальный идентификатор для каждого типа событий.
Журналы регистрации и учета событий ИБ должны храниться в течение заданного периода времени.
При превышении установленного периода, выделенного для хранения журналов регистрации событий ИБ, должна производиться перезапись событий.
Журналы событий ИБ должны быть защищены от несанкционированного просмотра и внесения изменений.
Защита программного обеспечения
Должна поддерживаться совместная работа с антивирусным программным обеспечением.
Эксплуатационная документация должна включать информацию о необходимых для функционирования сетевых параметрах (порт, протокол).
Все пароли по умолчанию для встроенных учетных записей должны иметь возможность замены.
Все встроенные учетные записи должны иметь возможность блокировки.
Настройки по умолчанию, которые могут быть использованы для несанкционированного доступа, должны иметь возможность замены.
Должна обеспечиваться возможность установки пакетов обновлений, по мере их публикации разработчиками.
Обеспечение целостности
Обеспечение контроля целостности на уровне программных компонент и файлов конфигураций.
Должна иметься возможность реализации в отказоустойчивом исполнении.
Эксплуатационной документацией должны быть определены параметры резервного копирования.
Сетевая безопасность
Должно обеспечиваться безопасное сетевое взаимодействие (возможность фильтрации) между компонентами.
Должно обеспечиваться безопасное сетевое взаимодействие (возможность фильтрации) с внешними системами.
Криптографическая защита
Пароли (ключи) от УЗ должны храниться и передаваться в зашифрованном/хешированном виде.
Возможность хранения паролей (ключей) в технических реквизитах (конфигурационных файлах) в зашифрованном/хешированном виде.
Должно обеспечиваться шифрование канала связи на уровне доступа пользователя.
Должно обеспечиваться шифрование канала связи при внутрисистемном взаимодействии компонент.
Возможность интеграции с существующей инфраструктурой открытых ключей.
Поддержка средств криптографической защиты информации, реализованных на основе алгоритмов, соответствующих национальным стандартами, и имеющих документальное подтверждение соответствия установленным требованиям.
Контроль НДВ
Отсутствие НДВ, выявляемых методами анализа исходного кода (применимо при наличии исходного кода).
Отсутствие НДВ, выявляемых методами статического и динамического анализа ПО.
Чем мы выделяемся
Стандарты качества
В 2018 мы подтвердили стандарты по управлению качеством: мы аттестованы по ISO 9001:2015 и ISO 27001:2005 (управление информационной безопасностью). Наши стандарты разработки.
Полный контроль
Клиенты видят всю команду в системе Интранет: все задачи, чеклисты, отчеты и обсуждение. Договоренности фиксируются в задачах, информация не теряется (в отличие от почты или телефона).
Бессрочная гарантия
Мы предоставляем бессрочную гарантию на весь написанный нами код.
Без взломов и утечек данных
В 2022 получили лицензии ФСБ и ФСТЭК (деятельность по технической защите конфиденциальной информации) и готовы строить защищенные системы или провести аудит вашей. За 16 лет работы компании у нас не было ни одного случая взлома или утечки информации.
В каких случаях мы наиболее эффективны
сайт интегрирован сразу с несколькими системами, причем не у всех есть документация
на сайте уже сейчас/будут высокие нагрузки (от 10 000 посетителей в сутки) и всё должно работать быстро
для ряда работ вам нужны не только «руки», но и «голова», то есть аналитика и консалтинг
Свяжитесь с нами:
посчитаем смету и дадим рекомендации по архитектуре.
сайт интегрирован сразу с несколькими системами, причем не у всех есть документация 
на сайте уже сейчас/будут высокие нагрузки (от 10 000 посетителей в сутки) и всё должно работать быстро 
для ряда работ вам нужны не только «руки», но и «голова», то есть аналитика и консалтинг 
