Опыт внедрения инструментов статического анализа кода в Проект Э

Detekt

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

Но вопрос всё равно то и дело всплывал, и нам в команду ожидается новый разработчик без опыта работы на Котлине и мои дипломники начали отдавать код на ревью…​ В общем я решил всё-таки попробовать.

Прикрутил его без проблем. Включил все чеки, которые мне показались разумными. После этого он думал 6 секунд на моей машине (i7-8700, 32GB Ram, SSD) (больше 10% процентов времени сборки) и выдал 1500 "проблем". При ближайшем рассмотрении, выяснилось что настоящие проблемы можно буквально по пальцам одной руки пересчитать, а всё остальное - белый шум.

Белый шум я "забейзлайнил" и вмёржил. После чего упёрлись в то, что у него правила форматирования не совпадают с правилами форматирования в идеи. А ревью проходить быстрее так и не стали. И пока что это всё, что можно рассказать про детект - я подкрепил свой скепсис по отношению к тулам статического анализа.

Сейчас попробую оставить только те проверки, которые выявили настоящие проблемы - если время сборки вернётся к нормальному оставлю. Если не вернётся - вынесу в отдельный пайплайн, не блокирующий сборку и деплой и посмотрю сколько будет генерять ошибок - если мало и по делу - оставлю, если нет - выкашу нафиг.

Вердикт: ожидается, возможно будет полезен молодым разработчикам и новичкам в Котлине.

Kover

Ковер тоже появился с подачи условного РП - возник вопрос о проценте покрытия кода тестами, я сказал что хз и не заморачиваюсь этим. Но стало интересно.

Прикрутил без проблем, порадовался - 100% покрытие эндпоинтов (наша явно озвученная цель), 85-90% покрытия строк (побочный эффект эргономичного подхода). Из плохих новостей - покрытие веток ~65%. Но это вызвано тем, что сроки у нас довольно жёсткие и мы осознанно покрываем тестами только хэппи пасы и баги.

Потом без особых проблем на всякий случай прикрутил верификацию покрытия по этим правилам - 100% строк в классах *Controller и >85% строк всего.

А потом я посмотрел на время сборки и ужаснулся. 15 секунд, ~30% времени сборки. Пока живём с этим, но в ближайшее время планирую вынести верификацию покрытия в отдельный пайплайн, не блокирующий мёрж и деплой.

Вердикт: с эргономичным подходом - найс ту хэв.

ArchUnit

Поигравшись с детектом и ковером я вошёл в раж и прикрутил ArchUnit. Он нашёл (и вынудил пофиксать) все уже известные мажорные проблемы и пару минорных. Но сожрал ещё 6 секунд. Его я тоже собираюсь вынести из основного пайплайна сборки, но оставить в качестве информации.

Вердикт: рекомендую, но вне основного процесса разработки

Итоги

Ничего фатального статические тулы не нашли, но увеличили время сборки больше, чем на 50%. Детект у меня пока под вопросом, ковер и арчюнит оставлю в качестве доп. источника информации о состоянии кода.