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