Контроль качества кода в перспективе развития проекта

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

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

Мы разработали автоматизацию по контролю качества кода, которая уже работает в нашей компании и в некоторых других. Данная реализация создана для языка 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).

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

Возьму на себя смелость тезисно изложить основные моменты из этого руководства.

Важность более простой поддержки для бизнеса


  • Сроки внедрения новых функций существенно меньше. Продукт на шаг впереди конкурентов.
  • Время исправления багов значительно сокращается. Заказчик и клиенты в выигрыше.
  • Простота введения в проект новых разработчиков. Диверсификация рисков.
  • Оптимизация по любому другому параметру системы требует изменений в коде проекта.
  • Хорошо поддерживаемый код, как правило, работает на порядок стабильнее. Изменения в нем имеют меньше побочных эффектов.

Особенности внедрения


  • Поддерживаемость кодовой базы обеспечивается выполнением простых руководств.
  • Выполнять эти руководства нужно с самого старта проекта, важен вклад каждого разработчика.
  • Некоторые нарушения гораздо хуже остальных.

Перечень рекомендаций


  1. Пишите короткие методы
  2. Пишите простые методы
  3. Пишите код только один раз
  4. Старайтесь создавать маленькие интерфейсы для методов и конструкторов
  5. Распределяйте задачи по модулям
  6. Создавайте компоненты со слабой связанностью
  7. Соблюдайте баланс между компонентами
  8. Старайтесь писать меньше кода
  9. Автоматизируйте тестирование и деплой
  10. Пишите чистый код

Некоторые из этих принципов можно легко контролировать в автоматическом режиме, для этого были созданы специальные программные средства для таких языков как 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, находящийся в папке стандарта. В этом файле имеется закомментированная строка:

<!--<rule ref="PEAR"/>-->

Её можно раскомментировать и вставить свой стандарт, вместо PEAR, например:

<rule ref="Symfony2"/>

В таком случае, будут проверяться оба стандарта и Secl и Symfony2. В интегрированных средах разработки (IDE) с поддержкой PHP_Sniffer, типа PHPStorm, можно настроить автоматическую проверку в визуальном режиме с подчёркиванием нестандартных методов и классов, и выводом сообщений об ошибках.



После такой настройки не соответствующий стандарту код будет подчёркиваться.



А при наведении курсора мыши на подчёркнутую строку будет появляться сообщение о нарушенном правиле.

После исправления ситуации подчёркивание пропадёт.



При желании, можно изменить политику ошибок на политику предупреждений для всех, или части правил. Это делается достаточно просто, если покопаться в коде сниффера. В таком случае можно оценивать код более мягко, опираясь на допустимое количество предупреждений. Возможно, такой подход и будет реализован в дальнейшем, но пока мы не видим необходимости в подобном решении.

Данная реализация довольно простая, но тем не менее несет хорошую полезность для дальнейшего развития проекта. Мы её разработали под себя, знаем, что в некоторых компаниях есть подобные системы контроля качества кода, но не публичные.

Пользуйтесь на здоровье и пишите правильный код!

P.S.. В нашей школе вот-вот стартует пятимесячный курс обучения от автора статьи «Хочу стать Junior PHP Developer!» и «Symfony 2. Гибкая разработка». Чтобы записаться пишите на info@digitov.com

P.P.S. Чтобы получать наши новые статьи раньше других или просто не пропустить новые публикации — подписывайтесь на нас в Facebook, VK и Twitter.

Авторы:
Сергей Харланчук, Senior PHP Developer, Компания «SECL Group»
Никита Семенов, CEO, Компания «SECL Group»

SECL Group

46,00

Делаем стартапы успешными!

Поделиться публикацией
Комментарии 14
  • НЛО прилетело и опубликовало эту надпись здесь
      0
      Основной критерий качества разработки это сокращение времени на поддержку и добавление новых фич с разрастанием кодовой базы.
        0
        Вопрос был сформулирован прежде всего «как?». «Сокращение времени на поддержку и добавление фич» это не «как», а «что», даже не критерий, а субъективная оценка.

        Критерием (метрикой) оно (сокращение) может стать, если указать как и какие параметры измеряются, как часто и как их интерпритировать.

        Собственно поддержу вопрос — как?
          +1
          Да, вы совершенно правы, это субъективная оценка. Мы в свое время поверили специалистам из SIG, которые опирались, с их слов, на соответствующий объем статистических данных. И, по нашему субъективному мнению, их расчеты оказались верны. Любой стандарт — это правила и ограничения, призванные унифицировать какие-либо положительные тенденции. Вышеописанные принципы находят свое подтверждение и обоснование в трудах многих уважаемых авторов.
          Я уверен, что вы вполне можете предложить свои подходы, описать их в подобной статье со своими критериями. Тогда мы с большим интересом обсудим результаты.
            0
            Мы первые спросили :-)
            • НЛО прилетело и опубликовало эту надпись здесь
                0
                Вы подняли очень важную и интересную тему из области статистики программных продуктов. На мой взгляд, вопросы грамотного учета и сбора статистических данных в рамках работы с кодом — исключительно необходимый и, часто, недооцененный фактор. Особенно это касается молодых и не очень больших компаний, где оценка даже менеджерской информации может вызывать затруднения. Решение может заключаться в целенаправленной унификации сбора данных по различным параметрам работы коллектива. И даже педантичная оценка последствий внедрения новой методики в рамках не очень большого коллектива не даст репрезентативной выборки, элемент субъективности будет оставаться. Я бы с удовольствием почитал о таких исследованиях. Вот, что я имею ввиду.
              0
              даже не критерий, а субъективная оценка.

              Объективно оценить это можно только за счет динамики скорости разработки. Если первый месяц команда пилила задачи в среднем за N времени, то если все хорошо через пол года они будут пилить все примерно с той же скоростью.

          +1
          Нами был реализован контроль следующих базовых принципов:
          • Длина функций не должна превышать 15 строк кода;
          • Цикломатическая сложность функции не должна быть более 5;
          • Функции не должны принимать более 4 входных аргументов;
          • Класс не должен содержать более 15 методов;


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

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


          P.S. Прошу ни в коем случае не считать мой вопрос камнем в огород авторов статьи.

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

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


            Поделитесь опытом, как это контролировать в команде из десятка программистов в стадии активной разработки продукта?

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

                Иногда, если, даже опытный разработчик, постоянно препятствует прогрессу компании в целом, встает вопрос о целесообразности его дальнейшего нахождения в должности.
                  0
                  Все же, в каждом случае необходим индивидуальный подход.

                Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                Самое читаемое