Технический дизайн

Эта статья будет полезна как разработчикам, так и менеджерам. Если вы представляете большую компанию с неограниченным бюджетом, возможно, она вам не пригодится.

В погоне за продуктивностью часто создаются «гибкие» системы, гибкость которых на деле оказывается иллюзорной. В результате возникают простои, необходимость переделывать свеженаписанный код, а также искать и исправлять баги. При этом такие системы не освобождают нас от необходимости оставлять после себя структурированные артефакты в виде верхнеуровневой документации.

Что можно предпринять, чтобы ускорить разработку и при этом обеспечить проект документацией?

Как известно, минимальные действия приносят максимальный результат. Это применимо ко всем сферам деятельности человека, включая разработку программного обеспечения. В этой статье я расскажу об одном небольшом, но крайне эффективном действии, которое способно изменить ваш процесс разработки.

Типичная картина

Разработчик получает задачу, читает требования, приступает к реализации, сталкивается с рядом вопросов, уточняет детали, переписывает код, передаёт его на ревью, деплоит.

Проблемы этого подхода:

1. Дороговизна «гибкости».
   С точки зрения ^[1] общепринятых принципов разработки может показаться, что такая система достаточно гибкая. Но если перевести затраченное время в деньги, становится очевидно, что подход выходит весьма затратным. Кроме того, такой процесс затрудняет параллельную работу — если вы в функциональной команде, кто-то обязательно будет кого-то ждать. Это делает процесс ещё дороже.

2. Отсутствие раннего выявления проблем.
   Код проверяется только на этапе ревью, когда он уже написан и затрачено время. Если в нём обнаружатся архитектурные или логические ошибки ^[2], потребуется дополнительное время (и, соответственно, деньги) на переработку. К тому же читать огромный pull request неудобно и долго.

3. Создание новых багов.
   Переписывая свеженаписанный код, легко упустить важные детали, что приводит к багам. Их поиск и устранение также требуют времени и ресурсов.

Почему важно обращать внимание на эти проблемы?

1. Если не считаешь деньги — ты обречён

   Зачем считать деньги компании, если ты программист или менеджер? Всё просто: если ты наёмный сотрудник, это помогает сохранить своё рабочее место. Если у тебя бизнес — это вопрос выживания.

2. Перед тем как строить — нужно думать

   В классических инженерных школах схемы и чертежи — норма. Нас учили рисовать блок-схемы и «дебажить» на бумаге. В реальной работе схемы остались лишь у аналитиков и архитекторов — и то не всегда. В итоге мы строим «на глаз», и только потом узнаём, что всё надо переделать.

3. Хорошая система требует хорошей проработки

   От идеи до реализации задача проходит множество этапов: заказчик → аналитик → дизайнер → архитектор → разработчик. На любом этапе что-то может быть упущено. Схема помогает это вовремя обнаружить.

4. Конфликты в команде

   Мотивация ^[3] падает, когда твою работу заставляют переделывать. Это можно (и нужно) предотвращать. Для этого стоит внедрять процессы, которые заранее выявляют проблемы.

Как обычно решают эти проблемы?

1. Нанимают больше людей

   Это временное и поверхностное решение. Мы уже видели, к чему это привело после COVID — к массовым сокращениям после волны найма.

2. Создают ещё одну гибкую систему для старой гибкой системы

   Это запускает цепочку усложнений. Возникает путаница, которую пытаются компенсировать бюрократией. Она отнимает ещё больше времени и сил.

3. Просто закрывают глаза на проблемы

   Это худшее из возможных решений. С ростом сложности продукта растёт и количество «слепых зон». Найти, где и как работает функционал, становится невозможно, а стоимость разработки растёт экспоненциально.

Критикуешь — предлагай

Как я упоминал в начале, минимальные действия приносят максимальный эффект. Такое действие — технический дизайн.

Технический дизайн — это шаблонный документ, в котором разработчик описывает своё решение задачи на верхнем уровне. В течении более 3х лет я внедрял и обкатывал его на разных командах и вот какие преимущества я выявил.

Преимущества технического дизайна:

1. Формирование структуры до начала работы

   Разработчик сначала продумывает решение, создаёт схему и придерживается её при реализации.

2. Безболезненное внесение изменений

   Документ проходит ревью в команде. Он легко читается, так как содержит только ключевые моменты. Ошибки можно оперативно исправить.

3. Создание документации как артефакта

   После реализации технический дизайн можно актуализировать и использовать как документацию к фиче: там уже описаны методы, логика ^[4] и контракты.

4. Параллельная разработка

   На этапе технического дизайна команда может договориться о структурах данных — контрактах. Это позволяет фронтенду и бэкенду работать асинхронно.

Пример структуры технического дизайна (на примере Flutter)

1. Описание — цель задачи, ключевые ограничения (2–3 предложения).

2. Требования — функциональные и нефункциональные.

3. UI/UX — ссылка на макет, описание компонентов.

4. Архитектура — основные компоненты: виджеты, state management, сервисы, роутинг.

5. Взаимодействие компонентов — диаграмма или список связей.

6. API — используемые эндпоинты и структура ответов.

7. Риски — потенциальные проблемы и способы их обхода.

8. Реализация — пошаговый план действий.

9. Оценка — примерная эстимация.

10. Ревью — комментарии коллег.

Внедрение технического дизайна позволяет:

• снизить количество ошибок;

• сэкономить время;

• уменьшить архитектурные недочёты;

• упростить тестирование;

• повысить покрытие документацией.

Звучит впечатляюще. Но если вам всё ещё мало аргументов — подумайте об AI.

Причём тут искусственный интеллект?

AI развивается стремительно, и всё чаще слышно мнение, что он заменит разработчиков. Я считаю это маловероятным. Скорее всего, мы просто перейдём на новый уровень абстракции — как это уже происходило раньше: от перфокарт до высокоуровневых языков. Но одно остаётся неизменным — плохо структурированное решение будет неэффективным, независимо от того, пишет ли код человек или ИИ.

Спасибо, что уделили время. Удачи в проектах!

Мой тг-канал: https://t.me/setstateordie ^[5]