Привет! Я Иван, Битрикс-разработчик e-commerce агентства KISLOROD.
Мы в компании запускали много проектов электронной коммерции, внедряли на них различные интересные решения, порой очень сложные. И, как любая команда разработчиков, не раз задумывались о том, чтобы повысить скорость и эффективность работы.
Рассказываю о том, как мы агрегировали личный опыт и нашли подход, который, возможно, будет полезен и командам разработки, и заказчикам.
Требования рынка к качеству и скорости разработки
Доля электронных продаж в общей массе розничной торговли в России увеличивается уже несколько лет подряд — в 2023 году на E-com пришлось 19% всех продаж в рознице.
Из-за высокой конкуренции требования пользователей постоянно растут, причем им важны как скорость, так и удобство работы интернет-магазинов.
И теперь при выпуске программного продукта уже недостаточно ориентироваться на MVP — Минимально Жизнеспособный Продукт, необходимо запускать Minimum Delightful Product — Минимально Восхитительный Продукт. То есть такое ПО, которое по качеству не уступает лидерам рынка.
И делать это надо достаточно быстро, потому что если разработка затянется, то к моменту запуска продукта он может устареть. У заказчиков нет пары лет в запасе, и поэтому ключевой проблемой E-com становится время выхода на рынок — Time to Market.
Получается, что при сравнимом качестве ПО торговые площадки соревнуются в первую очередь в скорости запуска проекта.
Кто быстрее запускает качественный продукт, тот и получает значительную долю рынка. |
Мы постоянно ищем возможности, чтобы:
поддерживать высокое качество проектов в программной и функциональной части;
предлагать рынку доступное решение, которое укладывается в бюджеты заказчиков;
выпускать проект максимально быстро, но без ущерба качеству.
При решении данной задачи, перед нами встало несколько вопросов:
Как улучшить процесс разработки новых проектов?
Как не тратить время на придумывание «велосипедов»?
Как быстрее включать новых сотрудников в процесс разработки?
Как упростить и улучшить распространение знаний внутри компании?
Как не ловить 100500 багов при реализации схожего функционала на разных проектах?
Как максимально эффективно систематизировать опыт и успешные решения, чтобы переносить их на другие проекты?
Самое очевидное решение здесь — использовать уже готовые собственные наработки, а не начинать работу каждый раз заново. Но делать это можно по-разному, и у каждого подхода есть минусы.
Делюсь опытом за несколько лет.
Предыстория: пишем документацию для разработчиков по проектам
Изначально мы вели лишь пользовательскую документацию, но затем начали вести документацию для разработчиков. Это было нужно для того, чтобы быстрее и проще ввести в проект нового разработчика, а также чтобы в будущем проект было легче поддерживать, зная, как и что там реализовано.
Гипотеза: наличие внутренней документации для разработчиков по проекту позволит им проще погружаться в проекты и быстрее переключаться между ними. В будущем это принесет пользу на других проектах, где будет востребован похожий функционал.
Как реализовали:
Создали внутреннюю энциклопедию — Wiki, где для каждого проекта есть отдельное место с документацией по проекту.
Также стандартизировали процесс написания документации с помощью шаблона и регламента его написания.
Преимущества: у каждого проекта есть стандартизированная документация как для заказчика, так и для разработчика.
Недостатки:
Необходимо постоянно поддерживать актуальность документации.
Знания не распространяются: разработчик с соседнего проекта понятия не имеет, что происходит на другом, пока не погрузится в него и не прочтет документацию.
Документация разработчиков недостаточно подробна: она по умолчанию стандартизирована и не содержит всех деталей и нюансов технической реализации. Поэтому, чтобы использовать решения на других проектах, необходима адаптация.
Каждый разработчик описывает разработанный им функционал так, как считает нужным, поскольку нет четких правил. То есть каждый специалист описывает решение настолько подробно, насколько считает нужным. Кроме того, не все разработчики могут быть хорошими техническими писателями, поэтому уровень детализации будет отличаться.
Разработчик должен делать это в свободное от основной работы время, хоть и в рамках рабочего времени, что также накладывает дополнительные ограничения.
Вывод: документация разработчика имеет малую пользу в плане повторного использования, поскольку содержит лишь общее описание реализации функций на конкретном проекте.
В итоге ведение документации для разработчиков влияет на ускорение других проектов лишь опосредованно и не в той мере, какой хотелось бы.
Кейсы внутренней базы знаний
Следующим этапом было создание внутренней базы данных с описанием кейсов. В той же Wiki каждый разработчик мог оставить описание собственного примера реализации полезных фич и решений.
В отличие от документации, кейсы в базе имеют примеры кода и детальное описание, то есть их уже можно использовать повторно другими разработчиками, хотя бы в качестве примера.
Использование кейсов включено в наш регламент разработки как инструмент для решения задач, с которыми разработчик раньше не сталкивался.
Гипотеза: если запустить базу знаний по успешно запущенным, неординарным и полезным фичам на разных проектах, то все разработчики смогут использовать эти решения в своих проектах.
Как реализовали: создали раздел кейсов во внутренней Wiki, сделали шаблон кейса, внедрили регламенты по написанию и использованию кейсов.
Преимущества:
Можно искать решения в данных энциклопедии.
Есть стандартизированные кейсы с примерами кода.
Разработчики получают уведомления о выходе новых кейсов.
Возможно использовать код из кейса в качестве основы на собственном проекте.
Можно расшаривать кейсы не только внутри команды, но и показывать другим компаниям, делиться наработками с сообществом.
Недостатки:
Здесь код уже можно скопировать из кейса, но по-прежнему необходима адаптация под конкретный проект.
Качество содержимого кейса также зависит от разработчика: по регламенту в кейсах обязательны примеры кода, но они копируются прямо из проектов, при этом качество описания по-прежнему зависит от навыков технического писательства.
Количество кейсов растет, а значит, со временем они начинают дублироваться, а часть решений устаревает — это усложняет поиск нужных решений в базе.
Вывод: кейсы разработчиков полезны для передачи непосредственного опыта, достаточно подробно описывают реализацию решений, но не могут быть применены в чистом виде на других проектах.
Кейс разработчика может лишь указать путь, которым было внедрено то или иное решение. Но на новом проекте другому разработчику неизбежно придется адаптировать и дорабатывать это решение.
Системный подход для процессов разработки
Поскольку было очевидно, что высокая производительность невозможна без оптимизации ресурсов и автоматизации рутинных задач, то стали искать примеры крупных игроков и конкурентов — как они решают вопросы производительности и качества.
Изучили работу крупных команд разработки других агентств. Выяснили, что для ускорения процессов разработки, некоторые ведущие компании в этой сфере используют свои наработки для создания «внутренних фреймворков» — шаблоны процессов и стандарты разработки.
Они с одной стороны ставят разработчиков в определенные рамки, а с другой облегчают разработку.
Такие «стандарты разработки» могут содержать как подготовленный к использованию функционал: готовые сервисы, настроенные библиотеки и т. д., так и различный вспомогательный функционал — интерфейсы, шаблоны сервисов, утилиты и т. д.
Часто такой подход решает и задачу стандартизации структуры проекта, являясь неким «скелетом», который используется для последующего «наращивания» функционала.
При этом платформа Битрикс сама по себе уже содержит «внутренний скелет» — Bitrix Framework, который имеет «модульную» структуру, то есть состоит из модулей.
Модуль в Битрикс — это блок кода, который может содержать API всех уровней, пользовательские интерфейсы, компоненты, административные страницы и т. д. (Здесь можно прочитать подробнее, что такое модуль в Битрикс).
Часть из них, такие как: «главный модуль», «модуль инфоблоков» и множество других, включены в состав продукта и доступны сразу после установки платформы Битрикс.
Большое количество сторонних модулей, которые не являются частью платформы, можно установить из маркетплейса Битрикс — таким образом организована система, аналогичная системе «плагинов» некоторых других популярных CMS.
Также Битрикс позволяет разработать собственные пользовательские модули (не для маркетплейса) с произвольным функционалом, который затем можно использовать для расширения функционала платформы.
Минимальная структура каждого модуля в Битрикс универсальна и описана в документации, процессы установки и удаления модуля не нужно реализовывать с нуля.
В админке для установки/удаления модулей предусмотрена отдельная страница, так же как и страница для настроек модуля и установки прав пользователей на использование модуля. В процесс установки модуля можно включить любые действия, которые разработчик сочтет нужными для работы функционала модуля: скопировать файлы, создать таблицы в БД, зарегистрировать обработчики событий и т. д.
Вероятно, разработка «своих» модулей — это самый логичный способ для решения наших задач, поскольку позволит собрать внутри них полезный функционал и использовать универсально на любых проектах.
Сама по себе эта идея не нова, думаю, что многие веб-студии, занимающиеся разработкой на Битрикс, со временем приходят к тому же решению. Но, вероятно, различие в том, как при проектировании и дальнейшей разработке таких модулей решаются следующие вопросы:
Как определить, какой функционал включать в модуль?
Создавать ли один большой общий модуль или несколько специализированных модулей, которые будут решать задачи в конкретной предметной области?
Где будет храниться кодовая база, как реализовать процесс установки модуля, установку «зависимостей» и т. д.?
Как лучше организовать документирование модуля?
Как построить процесс дальнейшей поддержки и развития функционала модуля?
Вероятно, что ответы на эти и другие вопросы, могут зависеть от задач, которые чаще решают разработчики на разных проектах, от опыта и от подхода к разработке, принятого в разных компаниях.
Что включать в модуль проекта?
Мы решили начать с MVP — реализовать один «модуль проекта» и провести «мозговой штурм» среди разработчиков, чтобы определить минимальный и достаточный набор функционала.
В результате остановились на следующих блоках функционала.
Определение констант, в зависимости от среды выполнения. Константы мы используем практически на всех проектах. В них могут быть заданы значения ID/символьных кодов для инфоблоков, свойств, систем и т. д. — в целом это некритичные для утечки данные, которые используются только в процессе разработки.
Обычно наши разработчики собирают определения для всех констант проекта в одном подключаемом файле.
Проблемы с константами возникают тогда, когда у них должны быть разные значения в зависимости от окружения, например, ID какой-то сущности на площадке для разработки может быть один, а на «боевом» сервере — другой.
Для решения этой проблемы можно было бы использовать «переменные окружения» (и/или .env файлы), но у них есть свои недостатки, поэтому реализовали свой «велосипед» с автоопределением ID сущностей по их символьным кодам или названиям.
Управление настройками (опциями). Различные опции модуля можно использовать в проекте, начиная от установки значений ключей для каких-то сторонних сервисов, заканчивая значениями телефона и email для отображения в блоке контактных данных на сайте.
Для этого реализовали логику добавления в админку отдельного пункта меню и страницы для модуля, на которой можно будет задавать значения опций. Также на странице в админке реализовали логику формирования и вывода полей различного типа: строка, число, список, файл и т. д.
Интерфейсы, абстрактные классы, базовые классы, адаптеры и т. п. Интерфейсы и прочая «обвязка» для реализации типовых логик: сервисов, репозиториев, сущностей и т. д.
Сервисы. Логики ранее реализованных на других проектах сервисов: для работы с заказами, скидками, каталогом, рассылками, отзывами на товары и др.
Интеграции. Логики ранее реализованных на других проектах интеграций со сторонними сервисами: DaData, GeoIP и др.
Контроллеры. Логики часто используемых на различных проектах контроллеров.
Логгеры. Логики логирования данных.
Утилиты. Большое количество различных утилит, начиная от функций работы со строками и заканчивая логиками парсинга и конвертации из/в различные форматы.
Обработчики событий. Битрикс не накладывает строгих ограничений на организацию в кодовой базе функционала регистрации обработчиков на различные события и реализацию этих обработчиков.
Из-за этого на различных проектах приходилось встречаться с огромными «портянками» кода регистрации обработчиков на события в init.php, а также «разбросанными» по разным местам проекта реализациями обработчиков событий.
Некоторые «битриксоиды» хорошей практикой считают вынос всех обработчиков событий в отдельный подключаемый файл (по аналогии с файлом констант).
Но при такой реализации «портянка» кода может просто «переехать» внутрь этого отдельного файла, поэтому мы решили немного оптимизировать и перенести все обработчики событий внутрь модуля, разбив логику обработчиков на отдельные классы, внутри которых можно группировать обработчики на события одной группы, и реализовав автоподгрузку этих классов.
Сторонние библиотеки. Сторонние библиотеки решили использовать как зависимости модуля, которые будут «подтягиваться» через composer при установке модуля и размещаться в директории модуля.
Кодовую базу модуля решили хранить в GIT, а документацию модуля частично реализовали в readme.md модуля, частично в кодовой базе в виде PHPDoc, планируя в будущем автогенерацию документации.
Модуль проекта
Итак, мы определились с тем, что можно создать модуль проекта, который будет содержать набор полезных функций и служить структурой для разработки.
То есть модуль выступает скелетом, на который мы уже впоследствии нарастим «мясо». Такой модуль можно применять на новых проектах, а чтобы облегчить использование разработчиками, написать к нему рабочую документацию.
Гипотеза: если использовать базовый модуль на новых проектах, то это ускорит процесс запуска.
Как реализовали: разработали базовый модуль проекта, собрали в нем набор функций, написали документацию, разместили в гите, используем на проектах.
Когда требуется разработать кастомный функционал на новых проектах, то мы размещаем код внутри структуры модуля проекта. Таким образом, структура модуля становится основой для любого нового функционала.
Преимущества:
Стандартизация: использование структуры модуля при разработке.
Готовый функционал в модуле, который можно сразу использовать.
Готовая страница в админке для установки различных настроек.
Некоторое снижение издержек при запуске проекта: часть базовых функций уже содержится в модуле.
В чем недостатки:
Модулю необходима постоянная техническая поддержка и обновления, в частности, нужно добавлять новый функционал.
На проекте используется не весь функционал из базового модуля, потому что нельзя выбрать, что именно нужно на данном сайте.
Неиспользуемые функции утяжеляют код и усложняют дальнейшую его работу и обслуживание.
Вывод: метод более утилитарен и полезен, чем предыдущие, но по-прежнему недостаточно гибок в настройке: часть функций остается неиспользуемой, а чего-то не хватает. То есть необходима ручная доработка и затраты времени.
Модульная архитектура видится верным направлением, но при использовании единственного базового модуля с универсальным набором функций встает вопрос об избыточных возможностях, что создает лишние нагрузки на сайт.
Готовые решения→
Скрытый текст
Анализ запросов наших клиентов показывает, что есть определенный процент запросов на использование «готовых решений» в качестве основы для нового проекта. Также некоторые клиенты приходят к нам на техническую поддержку с сайтами, собранными на готовом решении.
Основные аргументы при выборе готового решения звучат так: намного более низкие стоимость и сроки реализации по сравнению с заказной разработкой.
Действительно, качественные готовые решения содержат намного больше востребованного функционала, чем коробочные решения Битрикс.
В состав готового решения, как правило, входит некоторое количество настроек, позволяющих администратору сайта довольно гибко настроить сайт, в том числе и визуальную часть. Реализация такого же функционала «с нуля» при заказной разработке может быть на порядок дороже, а сроки реализации несравнимы, учитывая, что готовое решение готово к эксплуатации практически сразу после установки.
К основным недостаткам готовых решений можно отнести:
Относительную сложность их расширения и доработки сторонними разработчиками, поскольку для внесения изменений разработчикам необходимо погрузиться в «чужую» кодовую базу, изучить и понять логику работы — это влечет за собой дополнительные трудозатраты.
Возможные проблемы совместимости с другими сторонними модулями, установленными на проекте.
Возможные ошибки при работе сайта, а также при обновлении, что приводит к общению со службами техподдержки, которая не всегда быстро и качественно помогает решить проблему.
В условиях ограниченных бюджетов и сроков на реализацию проекта, выбор готового решения кажется неплохой альтернативой разработке «с нуля».
Делать свое готовое решение для запуска его на маркетплейс и последующей конкуренции с уже существующими готовыми решениями мы не были готовы.
Но возникла идея взять опыт готовых решений для того, чтобы создать набор готовых компонентов, с возможностью гибко и быстро изменять сайт под требования заказчиков. Пройдя несколько этапов обсуждений и проработки, эта идея через какое-то время вылилась в создание внутреннего проекта под названием «Готовые компоненты».
Основная цель проекта заключалась в том, чтобы удовлетворить запросы клиентов на проекты с ограниченным сроком и бюджетом, но вместо «чужого» готового решения предлагать свои наработки.
Готовые компоненты на базе модуля проекта
Определившись с недостатками универсального подхода, мы решили пойти по пути кастомизации и развивать модуль так, чтобы избавиться от его недостатков.
Использовать модуль проекта в качестве основы для разработки нового функционала на различных проектах.
Периодически собирать наиболее полезный функционал на разных проектах, делать его более «универсальным» и затем включать в состав базового модуля.
Выделять законченные функциональные блоки из общего функционала базового модуля и переносить их в новые отдельные модули, которые можно было бы подключать на проекты опционально, дополнительно к подключению базового модуля.
В перспективе это могло привести к появлению специализированных модулей, каждый из которых отвечал бы за полную реализацию какого-то конкретного блока функционала (например, модуль «Отзывы» или модуль «Избранное»), а базовый модуль был бы более «чистым» и содержал бы только универсальный функционал.
Но дальнейшему развитию модуля способствовало создание нового внутреннего проекта под названием «Готовые компоненты».
Гипотеза: разработка «Готовых компонентов» даст возможность использовать модуль в качестве «готового решения» на других проектах для быстрой реализации типового функционала и запускать проекты с ограниченным сроком и бюджетом.
Как реализовали: запустили внутренний проект на разработку своего решения на базе модуля проекта с возможностью гибкой настройки и быстрого изменения под требования заказчика.
В рамках проекта:
Определили наиболее востребованный функционал, который используется в популярных готовых решениях.
Спроектировали дизайн страниц с учетом этого функционала.
Написали ТЗ на разработку, в котором описали необходимые требования к функционалу.
Реализовали бэкенд в формате «готовых функциональных блоков» с прицелом на то, что сайт можно будет собирать из выбранных блоков.
В модуль проекта добавили конфигуратор и установщик для выбора функциональных блоков при установке.
Реализовали фронтэнд-сборку с заделом на быструю ее адаптацию под разные цветовые схемы и типографику.
Разработали шаблон сайта с конструктором главной страницы.
Разработали компоненты: каталог, корзина, оформление заказа, личный кабинет и другие, которые включили в состав модуля.
Провели тестирование проекта, исправили баги.
Написали документацию для пользователя и разработчика, а также инструкции по установке и настройке решения.
Модуль с собственным установщиком выглядит следующим образом.
Преимущества:
Экономия ресурсов подрядчика и заказчика.
Сокращение времени на разработку типовых функций.
Снижение количества ошибок и упрощение разработки.
Мастер установки модуля позволяет выбирать функциональные блоки для каждого проекта.
Решение легко может использоваться многократно и масштабироваться, подстраиваясь под нужды разработчика.
Недостатки:
Модуль нуждается в поддержке и развитии: необходимо добавлять новые функции.
Часть функциональных блоков зависит от других, что необходимо учитывать при разработке.
Решение не может полностью заменить кастомную разработку и больше всего подходит для типовых интернет-магазинов на Битриксе.
Вывод: на данный момент — это одно из компромиссных решений, которое отлично подходит для интернет-магазинов с типовым функционалом и в несколько раз сокращает сроки и стоимость разработки.
По результатам использования этого решения в нескольких проектах, обозначились планы его дальнейшего развития:
Сделать конструктор главной страницы с возможностью настроить состав и порядок отображения блоков на «Главной».
Добавить новые функциональные блоки в состав решения: «Личный кабинет для B2B-пользователей», «Программа лояльности» и др.
Добавить дополнительные темы и шаблоны для разных типов сайтов: интернет-магазин, корпоративный портал, B2B-платформа и др.
Заключение
Организация процессов накопления, распространения и использования знаний внутри команд разработки помогает ускорить запуск проектов.
Как организовать эти процессы — каждая компания решает самостоятельно.
Для себя мы выделили несколько основных способов:
фиксирование знаний в документации к проектам — документация для разработчиков;
использование Базы знаний — Wiki, с описанием кейсов реализации полезного функционала;
использование накопленных знаний для реализации внутренних систем — модулей, как основу для разработки проектов.
А какие подходы к накоплению и использованию знаний с целью ускорения разработки проектов приняты у вас? Поделитесь в комментариях.
