Эта статья будет полезна как разработчикам, так и менеджерам. Если вы представляете большую компанию с неограниченным бюджетом, возможно, она вам не пригодится.
В погоне за продуктивностью часто создаются «гибкие» системы, гибкость которых на деле оказывается иллюзорной. В результате возникают простои, необходимость переделывать свеженаписанный код, а также искать и исправлять баги. При этом такие системы не освобождают нас от необходимости оставлять после себя структурированные артефакты в виде верхнеуровневой документации.
Что можно предпринять, чтобы ускорить разработку и при этом обеспечить проект документацией?
Как известно, минимальные действия приносят максимальный результат. Это применимо ко всем сферам деятельности человека, включая разработку программного обеспечения. В этой статье я расскажу об одном небольшом, но крайне эффективном действии, которое способно изменить ваш процесс разработки.
Типичная картина
Разработчик получает задачу, читает требования, приступает к реализации, сталкивается с рядом вопросов, уточняет детали, переписывает код, передаёт его на ревью, деплоит.
Проблемы этого подхода:
-
Дороговизна «гибкости».
С точки зрения общепринятых принципов разработки может показаться, что такая система достаточно гибкая. Но если перевести затраченное время в деньги, становится очевидно, что подход выходит весьма затратным. Кроме того, такой процесс затрудняет параллельную работу — если вы в функциональной команде, кто-то обязательно будет кого-то ждать. Это делает процесс ещё дороже. -
Отсутствие раннего выявления проблем.
Код проверяется только на этапе ревью, когда он уже написан и затрачено время. Если в нём обнаружатся архитектурные или логические ошибки, потребуется дополнительное время (и, соответственно, деньги) на переработку. К тому же читать огромный pull request неудобно и долго. -
Создание новых багов.
Переписывая свеженаписанный код, легко упустить важные детали, что приводит к багам. Их поиск и устранение также требуют времени и ресурсов.
Почему важно обращать внимание на эти проблемы?
-
Если не считаешь деньги — ты обречён
Зачем считать деньги компании, если ты программист или менеджер? Всё просто: если ты наёмный сотрудник, это помогает сохранить своё рабочее место. Если у тебя бизнес — это вопрос выживания.
-
Перед тем как строить — нужно думать
В классических инженерных школах схемы и чертежи — норма. Нас учили рисовать блок-схемы и «дебажить» на бумаге. В реальной работе схемы остались лишь у аналитиков и архитекторов — и то не всегда. В итоге мы строим «на глаз», и только потом узнаём, что всё надо переделать.
-
Хорошая система требует хорошей проработки
От идеи до реализации задача проходит множество этапов: заказчик → аналитик → дизайнер → архитектор → разработчик. На любом этапе что-то может быть упущено. Схема помогает это вовремя обнаружить.
-
Конфликты в команде
Мотивация падает, когда твою работу заставляют переделывать. Это можно (и нужно) предотвращать. Для этого стоит внедрять процессы, которые заранее выявляют проблемы.
Как обычно решают эти проблемы?
-
Нанимают больше людей
Это временное и поверхностное решение. Мы уже видели, к чему это привело после COVID — к массовым сокращениям после волны найма.
-
Создают ещё одну гибкую систему для старой гибкой системы
Это запускает цепочку усложнений. Возникает путаница, которую пытаются компенсировать бюрократией. Она отнимает ещё больше времени и сил.
-
Просто закрывают глаза на проблемы
Это худшее из возможных решений. С ростом сложности продукта растёт и количество «слепых зон». Найти, где и как работает функционал, становится невозможно, а стоимость разработки растёт экспоненциально.
Критикуешь — предлагай
Как я упоминал в начале, минимальные действия приносят максимальный эффект. Такое действие — технический дизайн.
Технический дизайн — это шаблонный документ, в котором разработчик описывает своё решение задачи на верхнем уровне. В течении более 3х лет я внедрял и обкатывал его на разных командах и вот какие преимущества я выявил.
Преимущества технического дизайна:
-
Формирование структуры до начала работы
Разработчик сначала продумывает решение, создаёт схему и придерживается её при реализации.
-
Безболезненное внесение изменений
Документ проходит ревью в команде. Он легко читается, так как содержит только ключевые моменты. Ошибки можно оперативно исправить.
-
Создание документации как артефакта
После реализации технический дизайн можно актуализировать и использовать как документацию к фиче: там уже описаны методы, логика и контракты.
-
Параллельная разработка
На этапе технического дизайна команда может договориться о структурах данных — контрактах. Это позволяет фронтенду и бэкенду работать асинхронно.
Пример структуры технического дизайна (на примере Flutter)
-
Описание — цель задачи, ключевые ограничения (2–3 предложения).
-
Требования — функциональные и нефункциональные.
-
UI/UX — ссылка на макет, описание компонентов.
-
Архитектура — основные компоненты: виджеты, state management, сервисы, роутинг.
-
Взаимодействие компонентов — диаграмма или список связей.
-
API — используемые эндпоинты и структура ответов.
-
Риски — потенциальные проблемы и способы их обхода.
-
Реализация — пошаговый план действий.
-
Оценка — примерная эстимация.
-
Ревью — комментарии коллег.
Внедрение технического дизайна позволяет:
-
снизить количество ошибок;
-
сэкономить время;
-
уменьшить архитектурные недочёты;
-
упростить тестирование;
-
повысить покрытие документацией.
Звучит впечатляюще. Но если вам всё ещё мало аргументов — подумайте об AI.
Причём тут искусственный интеллект?
AI развивается стремительно, и всё чаще слышно мнение, что он заменит разработчиков. Я считаю это маловероятным. Скорее всего, мы просто перейдём на новый уровень абстракции — как это уже происходило раньше: от перфокарт до высокоуровневых языков. Но одно остаётся неизменным — плохо структурированное решение будет неэффективным, независимо от того, пишет ли код человек или ИИ.
Спасибо, что уделили время. Удачи в проектах!
Мой тг-канал: https://t.me/setstateordie
Автор: nmelnik
