Автоматизируйте стандарт кодирования

(В оригинале - Automate Your Coding Standard)

Наверняка с вами это тоже случалось. В самом начале проекта у всех присутствует множество позитивных намерений. Часто эти намерения даже фиксируются в документах. Вещи, касающиеся кода, формируют стандарт кодирования. В ходе kick-off митинга технический лидер проходит стандарт кодирования по пунктам, и в лучшем случае каждый соглашается следовать этому стандарту. Однако по ходу проекта намерения потихоньку исчезают одно за другим. И когда проект завершаетсся, код выглядит совершенно беспорядочно, и при этом никто не может понять, как же оно так получилось.

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

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

Существует множество инструментов для генерации отчетов о качестве кода и для документировании стандарта кодирования, но это еще не все. Автоматизировать нужно все, что касается стандарта кодирования и поддается автоматизации. Вот несколько примеров.

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

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

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

Автор оригинала - Filip van Laenen