​​Стремитесь не к качеству, а к скорости
#статьи #мысли #комментарии

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

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

Идея состоит в том, что между программистами и проектом должен быть постоянный конфликт:
1) Проект сконфигурирован так, чтобы отбраковать все, что понижает качество этого проекта.
2) Разработчики заинтересованы в том, чтобы делать изменения в  проекте.

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

Вот некоторые из возможных мер, которые сделают невозможным ухудшение качества проекта:
• автоматические билды при merge;
• ветка master в read-only;
• высокий уровень покрытия тестами;
• обязательный статический анализатор.

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

А что вы думаете об этом подходе?
Есть ли у кого-то в компании такой подход?
Хочу попробовать новую для этого канала возможность - оставлять комментарии. Делитесь размышлениями ниже.