Почему «Идеальный код с нуля» - миф
В реальных проектах требования могут меняться уже в процессе разработки: добавились новые поля из 1С, которые не учли на этапе проектирования или клиент внезапно захотел добавить, появляются новые проверки от внешних сервисов, пока обсуждали задачу вышло обновление CMS и требуется подстраиваться по его новые условия и т.д. Таких неожиданностей может быть много и будет – факт.
И в данном случае, не стремимся к идеальности, а проектируем и строим архитектуру проекта таким образом, чтобы потом безопасно вносить изменения, а для этого нужно ясно выделять слои (модульность), грамотно оформлять интеграции с внешними сервисами, а критичные места покрывать тестами и логами.
Код – бизнес-инструмент, а не произведение искусства
Заказчик часто искренне верит, что программисту достаточно нажать одну кнопку и будет «все красиво», но такого не бывает. Но это не так. И тут можно начинать душнить на тему наличия паттернов разработки, но для заказчика важны не красивые паттерны, а стабильная работа – обмен данными, работа коммерческого модуля, анимации и т.д.
И, к сожалению, не всегда, даже при наличии паттернов и следования им, все будет идеально. Что важно учесть при проектировании и разработке:
- Рост нагрузки – увеличение каталога, пиковые продажи, массовая синхронизация и т.д.
- Появление новых интеграций – подключение DaData, YaMap, Мой склад и можно много чего еще придумать.
- Изменения в API уже подключенных сервисов – обновление 1С, новая версия API, появление новых параметров запроса и т.д.
Поэтому, условно, для тимлида на первую итерацию любой разработки это полноценный MVP (Минимально жизнеспособный продукт), который может быть будет и не красивым, но в который можно будет оперативно внести изменения в процессе эксплуатации и выявления возможных болячек. А болячки будут, даже у самых крутых команд разработки.
Как мы делаем?
Когда я веду проект как тимлид, первостепенной целью сделать основательный и стабильный проект, который будет легко и просто развивать и дорабатывать. Типовое решение у нас:
- Разделение на слои: контроллеры, домены, отдельные интеграции с внешними системами, отдельные интеграции с БД, когда требуется.
- Вся интеграция реализуется через создание отдельных модулей, чтобы следовать принципу инкапсуляции, что дает нам независимость от других частей проекта.
- Используем явные DTO (объект передачи данных) и мапперы (программный инструмент или компонент, предназначенный для преобразования одних данных в другие), когда входящие данные из внешних систем (например 1С) приводятся к строгим внутренним структурам, что снизит риск и количество ошибок, а следовательно упрощает отладку.
- Логи и мониторинг: фиксируем каждую синхронизацию, ошибки интеграции, таймауты, повторные попытки, чтобы увидеть большинство проблем по логам, а не жалобам клиента.
С какой командой работать?
В роли тимлида мне удалось поработать на большом количестве проектов, как и в нашей студии, так и как привлеченный специалист в других студиях. И могу сказать так, что команда, которая обещает «идеальный код сразу», обычно недооценивает реальность: изменчивость бизнеса, живых пользователей, внешние ограничения, изменения в законодательстве.
Думаю, гораздо ценнее та команда, которая соответствует следующим параметрам:
- Говорит честно, что не пишет «идеальный» код, а выстраивает устойчивую систему, которую легко доработать;
- Старается заранее учесть различные нюансы системы, с которой работает, а если пишет что-то свое, то делает это в виде отдельного модуля, который не ломает основную систему;
- Вкладывает в архитектуру, логику, менеджмент, мониторинг и документацию, чтобы каждый следующий этап был предсказуемым, а не превращался в переписывание всего проекта;
- Умеет признавать ошибки проектирования, а самое главное умеет своевременно и без паники исправлять их.
В результате, если посмотреть на данные требования, то нужна зрелая команда, которая умеет управлять сложностями и не боится их, именно такая команда поможет проекту стабильно развиваться и расти. Так, например, один клиент со мной уже более 12 лет, когда я сменил за это время две студии.
Может ли помочь ИИ?
В каких-то случаях, использование искусственного интеллекта в разработке может несколько снизить нагрузку на команду разработки, но, к сожалению, до «серебряной пули» ему очень далеко. Да, в какой-то мере ИИ уже может использоваться как прикладной инструмент:
- Как быстрый черновик кода: генерация типовых оберток для API, DTO, мапперов, конфигов и примеров запросов;
- Как ассистент по рефакторингу, поиску дубликатов логики и избыточности;
- Созданию базовой документации и инструкций.
Но все это требует доработки напильником. Да, мы позволяем нашим сотрудникам использовать ассистентов и генеративные модели, но заставляем перепроверять, потому что он порой такого понапишет, что остается только хвататься за голову.
С точки зрения тимлида, здоровый подход к ИИ и разработке такой:
- Использовать ИИ как ускоритель: снимать рутину, создавать черновики, получать подсказки;
- Не делегировать ему принятие решений, за это должна отвечать команда;
- Код-ревью, тестирование, деплой и мониторинг все же лучше отдавать команде, а ИИ в данном случае должен быть встроен в данный процесс, а не заменить собой человека.
Иными словами, ИИ – это сильный помощник, но он не заменяет зрелую команду и тимлида, который понимает бизнес, отвечает за архитектуру и управляет рисками проекта.
Как тимлид, я отвечаю не за идеальные строки кода, а за предсказуемый результат для бизнеса и спокойную работу команды на всем жизненном цикле проекта.