Прототипирование против “чистого кода”

Иногда мы оказываемся переды выбором - качество кода или скорость разработки. Как определиться с решением? 

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

Если нужно проверить гипотезу, посмотреть насколько продукт интересен рынку или продемонстрировать клиенту, как будет работать его сервис, не стоит тратить огромные ресурсы на отладку и доведение до идеала кодовой базы. Можно сделать быстро и “на коленке”. Это и есть Прототип, то есть минимально работающая версия с ограниченной функциональностью для быстрой проверки бизнес-идеи. Плюсом такого подхода является, конечно же, скорость и минимальная стоимость. Не нужно строить огромный мост за несколько миллионов, если в итоге через него будет ездить пара человек в год, и то потому, что заблудились :).
Также данная методология позволяет экспериментировать с использованием новых технологий. И здорово, когда прототип создаваемого продукта уже прошел CustDev, конкуренты изучены, финмодель построена, “клиентские пути” исхожены ;). Тогда и прототипирование будет осмысленным. Но есть и обратная сторона: в погоне за скоростью публикации релиза, можно упустить важные моменты, связанные с  проработкой архитектуры, покрытием тестами, возможностью масштабирования и качеством документации. В результате получаем систему, в которой не заложены принципы, позволяющие ее развивать и поддерживать в дальнейшем. 

А что же такое “чистый код”? 

Это концепция, описанная Робертом К. Мартином в одноименной книге еще в 2008 году (Прим.:  издание на русском "Чистый код. Создание, анализ и рефакторинг."). Но и до ее публикации было много работ, излагающих схожие принципы. Так вот, это подход к разработке, при котором главной целью становится создание устойчивой архитектуры, легко развиваемой и масштабируемой в долгосрочной перспективе. Это уменьшает количество багов, делает внесение изменений более простым, а покрытие тестами и документирование сократит затраты на сопровождение. Как правило, именно “чистый код” применяется в заказной разработке, ведь заказчику на выходе нужно качественное промышленное решение. За качество и масштабируемость приходится платить временем, затраченным на проектирование и разработку, что в свою очередь увеличивает себестоимость ПО. При этом приложение становится менее гибким в плане внесения быстрых изменений, что в некоторых случаях может аффектить компоненты системы, влияя на их качество и функциональность. Поэтому как каждое изменение должно быть проверено и протестировано, испробованы разные варианты и выбран оптимальный, подходящий под текущую архитектуру. Поэтому в отдельных случаях стоит предложить клиенту прототип, чтобы быстро подтвердить или опровергнуть жизнеспособность идеи и двигаться дальше ;).

И что в итоге делать? Как обеспечить возможность быстрых изменений и добавления новой функциональности, но при этом сохранить систему стабильной и поддерживаемой, не превращая разработку в дженгу? 

1. Необходимо выделить ядро системы и основные элементы.
2. Договориться, что, при внесении изменений в ядро, применяется подход только “чистого кода”.
3. Сформировать чек-лист, по которому прототип должен быть доработан и добавлен к основной функциональности.
4. Проводить регулярную ревизию списка всех прототипов
5. Перевести все “вкусное” и полезное в концепцию “чистого кода”.
6. Отслеживать используемые технологии для понимания, что является основным стеком, что сейчас на этапе внедрения, какие технологии  проходят стадию проверки. Для этого прекрасно подойдет такой инструмент как технологический радар
7. Закладывать время и бюджет на рефакторинг прототипов и замену легаси-решений