В начале проекта было не совсем понятно что это такое, и зачем оно нам нужно... да и нужно ли вообще. Но по прошествии некоторого времени стало ясно, что: а) совершенно точно это нужно и б)
потратив немного времени вначале мы добиваемся 3 важных целей:
1. Ограждаем себя и других от элементарных (иногда и не очень) граблей.
2. Во время код ревью тратим больше времени на понимание "что здесь происходит" и меньше на "как это написано"
3. Автоматическое поддерживаем дисциплину и порядок на проекте. Хмм... есть более "народная" версия этой цели, но об этом чуть позже:)
Как это было:
Этап 0 - предпосылки
Вначале у нас были были довольно пространные намеки от QA инженеров о том, что SCA должен быть, и что .. ну ХЗ что это тако и как оно выглядит, но оно должно быть (наверное умных книжек начитались). В добавок выяснилось, что заказчик требует придерживаться довольно специфического (для Java) code style.
Вообщем начали вспоминать.
Вспомнили про Checkstyle и PMD, и в интернетах нашли "восторженные ахи" по поводу некой тулзы, под названием 'FindBugs'. Ну и попутно наткнулись на JavaNCSS и JDepends.
Этап 1 - подготовка.
Некий опыт работы с Checkstyle и PMD уже был, поэтому подготовку начали с создания наборов правил. Изначально в наборы включили все, что только под руки попало. Т.е., по сути, сделали достаточно жесткие ограничения для всего. Также начали с интересом вертеть в руках FindBugs, JavaNCSS и JDepends.
Этап 2 - внедрение.
Чуть позже, выяснилось 2 момента:
1. Наши "друзья из QA" обладают бинарной логикой. Для них либо ошибка есть, либо ее нет. Третьего не дано. Промежуточные уровни важности (warning, info и прочие) у ни в головах не помещались... А у нас не было ни желания, ни "технической возможности" расширить их мировосприятие.
2. Выяснилось, что "сознательность" и "стремление к совершенству" явления ну очень далекие от нашей реальности. Поэтому полу обязательного правила "запускать иногда проверки" стало как то не хватать. Поэтому, дабы не "загадится по уши" начали политику под девизом "колхоз - дело добровольное".
Вначале выяснили, что плагины для Eclipse можно настроить так, чтобы Checkstyle и PMD проверки производились непрерывно (а не "время от времени"). В этом случае "нарушения правил" выскакивают сразу, например как при нарушении синтаксиса.
Потом выяснилось, что сам Eclipse обладает довольно неслабыми механизмами проверки кода и JavaDoc-ов. Все это + изменение стандартной цветовой схемы дало неплохие результаты. Замена бледно желтых warnings на более выразительный цвет, ну например красный и оранжевый, сильно снижает шанс "случайно пройти мимо" или забыть про коменты или некорректную разметку.
Далее вычитали, что maven плагины могут не только строить отчеты, но и "нагло" и "упрямо" валить сборки при несоблюдении codestyle или обнаружении копипасты. Идея показалась "не плохой", поэтому все эти проверки повесили на фазу package.
И потом началось самое интерестное....
Этап 3 - обкатка.
Так получилось, что к моменту внедрения всего этого счастья у нас уже был небольшой объем рабочего кода и было с чем экспериментировать. Поэтому мы пошли не по пути "хорошо подумать и выбрать то что нам надо", а по пути "включить все, посмотреть что получилось и отключить лишнее". И это очень здорово!
Первым делом начали доводить Chekstyle и PMD. Выяснилось 2 интересных момента:
1. Надо вовремя остановиться. Точнее найти тонкую грань между "это правило нам не нужно и мешает" и "отключить его - так будет проще". Такой процесс "притирки" требует от команды "немного" терпения и понимания, а от тимлида "немного" упрямства и.... и не поддаваться на провокации :)
2. Есть зоны, для которых требования немного отличаются. Например для тестов допускается более вольный стиль именования, магические числа в коде и т.д. Для кода связанного с UI надо повысить максимально допустимые размеры классов и методов. А для классов с бизнес логикой выставить довольно небольшое пороговое значение циклической сложности.
В добавок у нас остались только проверки с приоритетом error, warn и info пришлось либо "повысить" либо вовсе отключить ("спасибо" QA). Но в таком подходе есть своя специфическая привлекательность...
Далее мы отказались от использования FindBugs из за его "тяжелонастраиваемости" и невозможности отключать проверки для определенных участков кода (например тестов).
Также мы отказались от JavaNCSS и JDepends. Первую получилось заменить Checkstyl-ом, а вторая оказалась довольно бесполезной во время сборки (однако мы их включили на CI сервере).
Также мы пришли к тому, что "все жесткие" проверки перенесли на фазу install. При таком подходе проект можно быстро собрать и запустить (mvn package), а если надо полная проверка - то mvn install.
Комментариев нет:
Отправить комментарий