Почему разработчики не пишут качественный код при создании ПО и кто в этом виноват

При создании программного обеспечения (ПО) скорость важнее качества, поэтому разработчикам нет смысла и невыгодно создавать качественный код, несмотря на то, что это медленно убивает проект. По мнению Solution Architect под ником The Hosk это связано с тем, что создание программного обеспечения понимается и ведется неправильно. Почему так происходит и что с этим делать он написал в своем блоге.

Почему разработчики пишут некачественный код

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

Почему качество не в приоритете

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

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

Акцент на качестве тормозит создание продукта

• лучшие практики → код-ревью;
• статистический анализ → автоматические механизмы проверки кода;
• DevOps/ALM → автоматическое развертывание;
• модульные тесты → тестовое покрытие;
• документация → документация для разработчиков/wiki.

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

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

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

Почему разработчики должны заботиться о долгосрочном качестве программного обеспечения, если этого не делает руководство, и это не приносит им никакого вознаграждения? 

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

Программные проекты побуждают разработчиков быстро писать некачественный код, чтобы создать иллюзию прогресса. Это работает только с маленькими проектами и вызовет массу проблем с большими. 

Что делать

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

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

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

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