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

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

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

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

Какие проблемы у этого подхода:

1.Дороговизна «гибкости».

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

2.Отсутствие раннего обнаружения проблем.

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

3.Создание новых багов. 

Все допускают ошибки и это в целом нормально. Но когда приходятся переписывать свеженаписанный код, очень большая вероятность упустить какие-то тонкости или мелочи. Это влечет за собой создание багов, для выявления, поиска и исправления приходится тратить дополнительное время (да, да, всё ещё деньги).

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

1.Не считаешь деньги, ты обречен. 

Зачем мне считать деньги компании если я программист/менеджер. Все просто, если ты наёмный сотрудник, то считая деньги компании ты как минимум продлеваешь свою необходимость в поиске новой работы, как максимум это один из важных зеленых флагов для твоего работодателя, ты выделяешься из общей массы сотрудников. Если это твой бизнес, кажется и нет смысла объяснять.

2.Перед тем как что-то строить, нужно подумать. 

В классических инженерных школах, схемы и чертежи давно себя зарекомендовали. Даже в начале моего обучения я помню как нас учили рисовать блок-схемы и «дебажить» на бумаге, но уже в реальной работе в действующих компаниях, схемы остались только у аналитиков и архитекторов (в маленьких компаниях этих ребят не найти). Получается странная система, где тебе нужно строить системы, но вместо того чтоб сначала сесть, подумать и нарисовать схему, ты делаешь всё на глаз, а после того как построил показать коллегам, которые скажут что ты не правильно все сделал и нужно переделать.

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

Под хорошей проработкой я подразумеваю поэтапную осмысленную работу над задачей. Сначала она формируется в голове у заказчика, потом она прорабатывается аналитиком, дизайнером, архитектором (если он есть в команде) и потом попадает разработчику. На всех этих этапах что-то может быть не обработано или забыто, но для выявлениях этих проблем нужно составить схему и в случае выявления проблемы точно донести в каких местах.

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

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

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

1. Найм большего количества сотрудников. Решение поверхностное и временное. К нему часто прибегают, компании, в любой непонятной ситуации. Как правило это приводит к большому лейоффу. Мы это видели недавно, после огромного найма во ковид и последующего сокращения кадров.
2. Создание ещё одной гибкой системы для текущей гибкой системы. Тут запускается механизм наслоения, начинается путаница, которую пытаются исправить бюрократией, которая забирает ещё больше времени и сил.
3. Закрывают глаза на проблемы. Принцип как у решения из пункта 1, но имеющее более губительное действие. С ростом сложности продукта, вырастает количество «слепых» мест. Найти информацию как работает тот или иной функционал, становится невозможным, стоимость разработки растет, и рост этот не линейный.

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

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

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

В чем плюсы:

1. Создание структуры решения задачи до начала реализации. Разработчик сначала думает над задачей, создаёт схему и опирается на составленный план при реализации.
2. Возможность безболезненно вносить изменения. После заполнения технического дизайна, команда проводит его ревью. Технический дизайн легко читается, поскольку там указаны только основные моменты. В случае выявления проблем, легко исправляется. 
3. Создание артефакт в виде документации. После ревью и реализации, разработчик может актуализировать документ и использовать его как документацию к фиче, поскольку там описаны все методы, логика и контракты.
4. Возможность паралелить разработку. На этапе составления технического дизайна, разработчики из команды могут сразу согласовать примерную структуру данных, которую они будут использовать. Эта структура называется контракт. Она позволяет асинхронно запускать разработку. Фронтенд разработчик не будет ждать бэкенд разработчика и наоборот. 

Сам шаблон данного документа достаточно гибок, поскольку составляется под конктретные требования команды и проекта. Но я выделю ключевые пункты которые должны присутствовать в нём на примере технического дизайна для Flutter:

1. Описание - должно содержать цель создания функционала, основные ограничения. Всего не более 2-3 предложений
2. Требования - описания функциональных и нефункциональных требований к задаче
3. UI/UX - ссылка на макет, описание ui компонентов
4. Архитектура - описание основных компонентов, виджеты, State Management, Сервисы, Роутинги
5. Взаимодействие компонентов - диаграмма или список связи виждетов и сервисов
6. API - используемые эндпоинты и структуры ответов
7. Риски - описание потенциальных проблем и обходных путей
8. Реализация - описание шагов релизации
9. Эстимация - дать оценку на реализацию
10. Ревью - там указываются комментарии от коллег

При использовании технического дизайна вы получаете 

1. снижения числа ошибок 

2. экономите время 

3. Уменьшаете архитектурные ошибки 

4. облегчаете тестирование 

5. увеличиваете покрытие документами

Выглядит впечатляюще, но если и этих аргументов вам мало, то как насчет AI?

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