Очень часто мы говорим о качестве кода, о необходимости писать код правильно, использовать инженерные практики и шаблоны проектирования (design patterns) . Но как качество кода отражается на бизнесе? Какими последствиями чреват низкокачественный код? Давайте разберем эти вопросы на примере одного проекта.

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

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

Почему же команда не уделяет внимания проблемам с кодом? Все дело в том, что у команды не хватает на это времени (часто также не хватает опыта и знаний) – ведь нужно разрабатывать новую функциональность. Накопление проблем в коде называется техническим долгом (technical dept). Чем больше долг, тем тяжелее жить с ним. Если же продуктивность команды падает в результате возросшего технического долга, то команда начинает не успевать завершить новый функционал и начинает торопиться еще больше. Образовывается замкнутый цикл. Чем больше команда торопится, тем меньше времени уделяется качеству кода. Чем меньше времени уделяется качеству кода, тем больше технический долг. А чем больше технический долг, тем меньше продуктивность и тем меньше успевает команда выполнить в срок. И, как следствие, начинает еще больше торопиться.

Через определенное время сторона бизнеса начинает понимать, что команда не успевает все выполнить в запланированный срок. Если используется Agile подход, то это станет видно гораздо раньше, чем при применении классических подходов. И тут необходимо что-то предпринять. Очень часто принимается решение расширить команду разработки (конечно, если хватает бюджета). Чем больше становится разработчиков, работающих над тем же кодом по тем же принципам, тем хуже его качество. Кое-как система доживает до успешного релиза и ее начинают использовать.

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

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

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

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

• Использовать инженерные практики (Continuous Integration, Code Review, TDD, парное программирование и так далее).
• Постоянно анализировать качество кода с использованием статических анализаторов кода и специализированных инструментов.
• Используя метрики качества кода, уделять время его улучшению, платить технический долг.
• Проводить организованные встречи членов команды с целью обсуждения и изучения кода системы.
• Использовать правило бойскаутов в процессе работы с кодом – оставляйте код в лучшем состоянии, чем он был до начала работы с ним. Применяйте это правило при работе над новой функциональностью, исправлении ошибок, внесении изменений.

Следите за своим кодом и вы сможете избежать многих проблем!