В разработке проекта зачастую принимают участие разработчики разного уровня. Это приводит к тому, что нет строгого формата написания кода. За качеством кода на проекте приходится постоянно следить старшим разработчикам и это отнимает у них кучу времени.
Для того чтобынаказать говнокодеров облегчить страдания тех, кто делает ревью кода, можно использовать автоматические средства проверки кода, которые всем давно известны. Это 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, проверяет измененные файлы на наличие ошибок и отправляет отчет на почтовый ящик одного или нескольких старших разработчиков, которые отвечают за качество кода на проекте.
Отчет отправляемый по почте выглядит так:
Таким образом легко автоматизировать процесс контроля за качеством кода на проекте.
Сильные стороны этого способа:
Недостатки:
Ресурсы:
UPD 19.05.2012:
Добавлена возможность игнорирования проверки файлов с использованием файла конфигурации.
Для того чтобы не проверять некоторые файлы и директории, вам нужно создать в корне проекта файл .hooks_ignore. Затем поместить в нем пути к файлам и директориям, которые вы не хотите проверять. Это может быть ядро движка или модули сторонних разработчиков.
Пример содержимого файла .hooks_ignore
Первые две строки позволяют исключать из проверки полностью директорию со всеми файлами внутри, а третья исключает конкретный файл.
Для большего удобства файл .hooks_ignore следует внести под контроль версий, чтобы он тоже хранился в репозитории и был общим для всех разработчиков на проекте. А также чтобы хук post-receive мог использовать его при проверке в удаленном репозитории.
Исходные коды на Drupal.org и GitHub были обновлены.
Жду ваших пожеланий и замечаний по этому небольшому проекту.
Для того чтобы
Большинство проектов компании где я работаю, сделаны на Drupal, поэтому будет рассмотрен пример проверки соблюдения стандартов кодирования Drupal, хотя все описанные ниже средства можно применить и для других стандартов, например Zend.
Сравнительно недавно появился набор правил для проверки стандартов кодирования Drupal через PHP Code Sniffer. Установить и настроить его очень просто, самое сложное начинается дальше. Как же заставить всех проверять свой код? Сказывается влияние человеческого фактора, первый забыл, второй не захотел, а третий просто считает, что его код не может содержать ошибок и вообще все это лишняя трата времени.
Решением может стать
Первым шагом будет добавление скрипта проверки кода в хук pre-commit. Когда разработчик коммитит свой код, измененные файлы автоматически будут проверяться. В случае, если будут найдены ошибки, операция коммита прерывается и на экран выводится список ошибок:
Код можно будет закоммитить только тогда, когда все ошибки будут исправлены. Отлично, теперь мы не позволяем добавлять «плохой» код в репозиторий проекта! Но по прежнему остается человеческий фактор. Снова кто-то забывает добавить скрипт проверки в папку .git/hooks своего проекта, кому-то сейчас лень исправлять ошибки и он откладывает на потом и т.д., а «самые умные» просто используют git commit --no-verify, потому что сейчас им не до ошибок. В последнем случае git не вызовет хук pre-commit и измененные файлы попадут в репозиторий без проверки.
Для того чтобы бороться с этим воспользуемся хуком post-receive. Этот хук срабатывает после добавления кода в удаленный репозиторий. Скрипт, который будет вызываться в хуке post-receive, проверяет измененные файлы на наличие ошибок и отправляет отчет на почтовый ящик одного или нескольких старших разработчиков, которые отвечают за качество кода на проекте.
Отчет отправляемый по почте выглядит так:
Таким образом легко автоматизировать процесс контроля за качеством кода на проекте.
Сильные стороны этого способа:
- Централизованный контроль;
- Нельзя полностью избежать проверки кода;
- Скрипты проверки кода не изменяют исходные файлы и не блокируют добавление кода в случае хотфикса;
- Скрипты легко установить и настроить;
- Помимо ошибок стандартов кодирования Drupal, отображаются функциональные ошибки. Например о том, что вы забыли использовать функцию t или check_plain (а это уже дыра в безопасности) при выводе данных на страницу.
Недостатки:
- Если добавить это средство в середине разработки, все старые ошибки проявятся и поначалу сложно будет их разгрести.
Ресурсы:
- Drupal Code Sniffer
- Набор скриптов для автоматической проверки кода через git
- Инструкция по установке и настройке скриптов на русском языке
UPD 19.05.2012:
Добавлена возможность игнорирования проверки файлов с использованием файла конфигурации.
Для того чтобы не проверять некоторые файлы и директории, вам нужно создать в корне проекта файл .hooks_ignore. Затем поместить в нем пути к файлам и директориям, которые вы не хотите проверять. Это может быть ядро движка или модули сторонних разработчиков.
Пример содержимого файла .hooks_ignore
includes
sites/all/modules/contrib
sites/all/themes/garland/template.php
Первые две строки позволяют исключать из проверки полностью директорию со всеми файлами внутри, а третья исключает конкретный файл.
Для большего удобства файл .hooks_ignore следует внести под контроль версий, чтобы он тоже хранился в репозитории и был общим для всех разработчиков на проекте. А также чтобы хук post-receive мог использовать его при проверке в удаленном репозитории.
Исходные коды на Drupal.org и GitHub были обновлены.
Жду ваших пожеланий и замечаний по этому небольшому проекту.
