4/97: Автоматизируйте ваш стандарт кода

Это перевод Automate Your Coding Standard. Автор: Filip van Laenen.

Из "97-ми вещей, которые должен знать каждый программист".

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

Когда же всё пошло не так? Вероятно, ещё в самом начале, на этой самой первой встрече. Некоторые из присутствующих просто пропустили всё мимо ушей. Другие не поняли смысла. Что ещё хуже: некоторые были несогласны, но молча согласились, тайком планируя следовать своим соглашениям и устроить восстание стандартов. Наконец, часть разработчиков и поняла соглашения, и даже согласилась с ними, но когда проект попал под давление сроков, им пришлось от чего-то отказаться. Хорошо форматированный код не приносит вам очков от клиента, который хочет функциональности. Более того, следование стандарту кодирования - это ведь так скучно (если только это не автоматизировано). Просто попробуйте отформатировать хаотический код студента, чтобы понять, как это нудно.

Но если это так сложно, то почему мы хотим, чтобы у нас вообще был стандарт кодирования? Первая причина: единообразное форматирование кода не даёт кому-то "владеть" кодом, просто пометив его форматированием в "своём" стиле. Мы бы хотели не дать разработчикам использовать определённые анти-шаблоны, чтобы предотвратить типичные ошибки. В конечном итоге, стандарт кодирования призван облегчить работу над проектом при сохранении скорости разработки от начала до конца проекта. Откуда следует, что все должны следовать ему — от него будет не много пользы, если один разработчик делает отступы в два пробела, другой - в один, а третий использует табуляцию.

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

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

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

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

Прим.пер.: см. также.