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

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

Давайте вместе с вами рассмотрим, почему поддержка проекта с плохим кодом, или как его еще принято называть - говнокодом, становится очень дорогой и занимает много времени.

 

Документация

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

Оформление кода

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

Качество кода

Код хорошо оформлен, с комментариями и аккуратными пробелами, но написан не качественно.

База данных

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

Резервные копии

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

Архитектура

Плохая архитектура приложения – все заплетено, непонятно что откуда и куда.

Инфраструктура

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

Контроль версий

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

Система управления задачами

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


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