Контроль качества кода в перспективе развития проекта
Это достаточно стандартный и, во многом, привычный ход событий. С опытом, мы пытаемся делать разрозненные попытки улучшать ситуацию, и не допускать ошибок прошлого. Но часто, собрать все в кучу для организации какой-то вменяемой системы времени не хватает. И, какое-либо универсальное решение, до настоящего времени, найти было достаточно непросто.
Мы разработали автоматизацию по контролю качества кода, которая уже работает в нашей компании и в некоторых других. Данная реализация создана для языка PHP. Ранее она была только для Java и C#. Однако принципы и подходы применимы ко всем современным языкам, поэтому приглашаем к обсуждению этой важной темы.
Так вот, проанализировав множество различных проектов специалисты компании Software Improvement Group (SIG) разработали набор простейших принципов и правил, следуя которым, можно в значительной степени улучшить такое состояние вещей. Эти принципы были изложены в книге-руководстве Building Maintainable Software, Java Edition: Ten Guidelines for Future-Proof Code (ISBN print: 978–1–4919–5352–5, ISBN eBook: 978–1–4919–5348–8).
Все элементы, необходимые для построения стабильной в поддержке системы на удивление просты и понятны. Они с лёгкостью могут применяться для приложений любой сложности. Наибольшего эффекта от такого подхода можно достичь, если использовать его с самого начала разработки, особенно сложных программных систем. Однако, использовав это руководство уже на более поздних этапах, можно добиться заметного улучшения показателей для новых модулей и стойкого снижения темпов усложнения создаваемой системы в целом.
Возьму на себя смелость тезисно изложить основные моменты из этого руководства.
Важность более простой поддержки для бизнеса
- Сроки внедрения новых функций существенно меньше. Продукт на шаг впереди конкурентов.
- Время исправления багов значительно сокращается. Заказчик и клиенты в выигрыше.
- Простота введения в проект новых разработчиков. Диверсификация рисков.
- Оптимизация по любому другому параметру системы требует изменений в коде проекта.
- Хорошо поддерживаемый код, как правило, работает на порядок стабильнее. Изменения в нем имеют меньше побочных эффектов.
Особенности внедрения
- Поддерживаемость кодовой базы обеспечивается выполнением простых руководств.
- Выполнять эти руководства нужно с самого старта проекта, важен вклад каждого разработчика.
- Некоторые нарушения гораздо хуже остальных.
Перечень рекомендаций
- Пишите короткие методы
- Пишите простые методы
- Пишите код только один раз
- Старайтесь создавать маленькие интерфейсы для методов и конструкторов
- Распределяйте задачи по модулям
- Создавайте компоненты со слабой связанностью
- Соблюдайте баланс между компонентами
- Старайтесь писать меньше кода
- Автоматизируйте тестирование и деплой
- Пишите чистый код
Некоторые из этих принципов можно легко контролировать в автоматическом режиме, для этого были созданы специальные программные средства для таких языков как Java и C#. Мы предлагаем простейшую реализацию автоматического контроля для PHP разработки в виде сниффера кода (Code Sniffer). Нами был реализован контроль следующих базовых принципов:
- Длина функций не должна превышать 15 строк кода;
- Цикломатическая сложность функции не должна быть более 5;
- Функции не должны принимать более 4 входных аргументов;
- Класс не должен содержать более 15 методов;
После внедрения подобного контроля в нашей компании, качество разработки значительно улучшилось. Код стал гораздо более простым для понимания и поддержки.
Предлагаем вам базовый вариант решения для автоматического контроля. Стандарт легко встраивается в систему контроля версий. Рекомендуем использовать его в связке с другими стилистическими стандартами, принятыми в вашей компании.
Вполне осознаю тот факт, что внедрение даже этих нескольких правил, встроенных нами в систему контроля, особенно на первых этапах вызовет затруднения у программистов. Эти трудности гораздо легче будет преодолеть человеку, знакомому с содержанием книги Роберта Мартина «Чистый код: создание, анализ и рефакторинг». Так же в этой книге достаточно подробно описаны теоретические основания вышеизложенных принципов. Скорее всего, для многих книга хорошо знакома, она отлично дополнит руководство «Building Maintainable Software».
Очень важно, на мой взгляд, особенно в начале, тщательно контролировать качество кода на выходе. Необходимо избежать механического дробления кода на, удовлетворяющие правилам, куски. Разделение функций и классов должно происходить по всем правилам ООП с применением шаблонов проектирования, там, где это необходимо. Одним из важнейших принципов в данном аспекте можно считать «Принцип единственной ответственности». Особо хочу отметить значимость правильного выбора имён, чётко характеризующих назначение функций и классов. Такой подход, как мы заметили, довольно быстро и эффективно позволяет повысить уровень программистов и качество их кода.
Полное описание мы выложили на GitHub и будем его улучшать в дальнейшем, реализовывая все больше принципов.
Как пользоваться сниффером?
Вариант 1.
Самый простой вариант установить стандарт через компоузер:
$ php composer.phar require --dev secl-group/phpcs-secl-standard:~1.0.0После установки можно начинать проверку кода. Предположим, проверяемые файлы находятся в папке src:
$ bin/phpcs --standard=vendor/secl-group/phpcs-secl-standard/secl-group/phpcs/Secl --extensions=php src/Вариант 2.
Можно установить сниффер глобально вместе со стандартными php снифферами. В среде Linux это можно сделать через PEAR. В начале устанавливаем основные стандарты, если они ещё не были установлены:
# pear install PHP_CodeSniffer
Находим дирректорию с установленными расширениями (/path/to/pear):
# pear config-show | grep php_dir
Переходим в папку стандартов:
# cd /path/to/pear/PHP/CodeSniffer/Standards
Клонируем стандарт:
# git clone https://github.com/SECL-Group/phpcs-secl-standard Secl
Можно установить его как дефолтный:
# phpcs --config-set default_standard Secl
Теперь та же проверка, что и в варианте 1 будет выглядеть так:
$ phpcs --standard=Secl --extensions=php src/
Такую проверку из командной строки легко использовать на стороне любой системы непрерывной интеграции.
При использовании на стороне программиста, для контроля качества собственного кода достаточно удобно дополнить сниффер другим стандартом, принятым на проекте. Для этого нужно внести изменения в файл ruleset.xml, находящийся в папке стандарта. В этом файле имеется закомментированная строка:
Её можно раскомментировать и вставить свой стандарт, вместо PEAR, например:
В таком случае, будут проверяться оба стандарта и Secl и Symfony2. В интегрированных средах разработки (IDE) с поддержкой PHP_Sniffer, типа PHPStorm, можно настроить автоматическую проверку в визуальном режиме с подчёркиванием нестандартных методов и классов, и выводом сообщений об ошибках.
После такой настройки не соответствующий стандарту код будет подчёркиваться.
А при наведении курсора мыши на подчёркнутую строку будет появляться сообщение о нарушенном правиле.
После исправления ситуации подчёркивание пропадёт.
При желании, можно изменить политику ошибок на политику предупреждений для всех, или части правил. Это делается достаточно просто, если покопаться в коде сниффера. В таком случае можно оценивать код более мягко, опираясь на допустимое количество предупреждений. Возможно, такой подход и будет реализован в дальнейшем, но пока мы не видим необходимости в подобном решении.
Данная реализация довольно простая, но тем не менее несет хорошую полезность для дальнейшего развития проекта. Мы её разработали под себя, знаем, что в некоторых компаниях есть подобные системы контроля качества кода, но не публичные.
Пользуйтесь на здоровье и пишите правильный код!
