Разработка кода. Свод правил

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

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

Кодер не должен сам собирать информацию, заниматься ненужными коммуникациями. Например, если предстоит создание шлюза в другую систему (реализация API) то не кодер должен доставать документацию на API, URL подключения и необходимые имена, явки, пароли. Эту информацию нужно собрать и предоставить кодеру.

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

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

Соблюдение режима работы и отдыха – залог эффективности. Придумывать решение и создавать красивый код лучше на свежую голову. С каждым новым концентрированным часом когнитивные способности снижаются, мозг устает. После двух-трех концентрированных часов работы нужен перерыв. Бывает, что код быстро и легко пишется, «идет сам». В таком случае можно и нужно работать дольше, до «чекпойнта». Но после этого важно не забыть отдохнуть. Например, 60-70 концентрированных часов за 10 дней потребуют несколько дней полноценного отдыха.

Режим работы и отдыха часто вступает в противоречие с чьим-то желанием торопиться, «авралить и дедлайнить». Тем не менее, нарушать режим нельзя, так как это ведет к негативным последствиям: к снижению качества решений, увеличения объема legacy и технологического долга, накоплению усталости. Как в известном фильме: «…всегда есть космический крейсер, кореллийские лучи смерти, галактическая чума, угрожающая погубить всю планету…», и это не повод нарушать режим.

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

Лучше неделю подумать, и за пару дней сделать, чем пару дней делать, а потом все долго переделывать. Известно, что ошибки на этапе проектирования - самые дорогостоящие. Если провести аналогию со строительством здания, то ошибки в общей архитектуре и/или фундаменте многоэтажного здания легко приводят к тому, что придется их исправлять, сначала разобрав и выкинув уже построенные этажи. Такой способ «строительства», мягко говоря, неэффективен и очень дорог.

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

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

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

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

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