В разработке проекта зачастую принимают участие разработчики разного уровня. Это приводит к тому, что нет строгого формата написания кода. За качеством кода на проекте приходится постоянно следить старшим разработчикам и это отнимает у них кучу времени.
Для того чтобы наказать говнокодеров облегчить страдания тех, кто делает ревью кода, можно использовать автоматические средства проверки кода, которые всем давно известны. Это PEAR и PHP Code Sniffer.
Большинство проектов компании где я работаю, сделаны на Drupal, поэтому будет рассмотрен пример проверки соблюдения стандартов кодирования Drupal, хотя все описанные ниже средства можно применить и для других стандартов, например Zend.
Сравнительно недавно появился набор правил для проверки стандартов кодирования Drupal через PHP Code Sniffer. Установить и настроить его очень просто, самое сложное начинается дальше. Как же заставить всех проверять свой код? Сказывается влияние человеческого фактора, первый забыл, второй не захотел, а третий просто считает, что его код не может содержать ошибок и вообще все это лишняя трата времени.
Решением может стать насильное добровольно-принудительное внедрение проверки кода в процесс разработки. Для того чтобы нам не пришлось стоять с палкой над каждым программистом, воспользуемся системой контроля версий git. Благодаря хукам git можно легко добавить свои скрипты, которые будут выполняться при определенных операциях git, например commit.
Первым шагом будет добавление скрипта проверки кода в хук pre-commit. Когда разработчик коммитит свой код, измененные файлы автоматически будут проверяться. В случае, если будут найдены ошибки, операция коммита прерывается и на экран выводится список ошибок:
Код можно будет закоммитить только тогда, когда все ошибки будут исправлены. Отлично, теперь мы не позволяем добавлять «плохой» код в репозиторий проекта! Но по прежнему остается человеческий фактор. Снова кто-то забывает добавить скрипт проверки в папку .git/hooks своего проекта, кому-то сейчас лень исправлять ошибки и он откладывает на потом и т.д., а «самые умные» просто используют git commit --no-verify, потому что сейчас им не до ошибок. В последнем случае git не вызовет хук pre-commit и измененные файлы попадут в репозиторий без проверки.
Для того чтобы бороться с этим воспользуемся хуком post-receive. Этот хук срабатывает после добавления кода в удаленный репозиторий. Скрипт, который будет вызываться в хуке post-receive, проверяет измененные файлы на наличие ошибок и отправляет отчет на почтовый ящик одного или нескольких старших разработчиков, которые отвечают за качество кода на проекте.
Отчет отправляемый по почте выглядит так:
Таким образом легко автоматизировать процесс контроля за качеством кода на проекте.
Сильные стороны этого способа:
- Централизованный контроль;
- Нельзя полностью избежать проверки кода;
- Скрипты проверки кода не изменяют исходные файлы и не блокируют добавление кода в случае хотфикса;
- Скрипты легко установить и настроить;
- Помимо ошибок стандартов кодирования Drupal, отображаются функциональные ошибки. Например о том, что вы забыли использовать функцию t или check_plain (а это уже дыра в безопасности) при выводе данных на страницу.
Недостатки:
- Если добавить это средство в середине разработки, все старые ошибки проявятся и поначалу сложно будет их разгрести.
Ресурсы:
- Drupal Code Sniffer
- Набор скриптов для автоматической проверки кода через git
- Проект на GitHub
- Инструкция по установке и настройке скриптов на русском языке
Жду ваших пожеланий и замечаний по этому небольшому проекту.
Автор: IlyinEugene
