Code Ahead или Линтеры всему голова

Привет. В этом году один из самых известных IT-спикеров — Егор Бугаенко — yegor256 перешёл от разговоров за ООП, к разговорам про качество кода. Если первое мне было абсолютно не интересно, то Code quality действительно важно для меня.

Предлагаю разбить наш с вами разговор на два этапа. В первой части мы посмотрим, что же предлагает нам Егор в книге Code Ahead, а также в докладе (он читался на Joker 2018) — Не думайте о качестве, думайте о скорости, запись которого уже есть на Ютубе:

Во второй части перейдём к практике. Я опишу простой способ, как внедрить linters для проектов на Go, а также о том, какие Линтеры использую я для проектов на Java.

Егор предлагает одну очень понятную историю, которая мне крайне симпотична. Давайте строить такой pipeline разработки, где влить код в master — супер сложная задача. Тут будут миллион статических проверок кода, разнообразные автоматически тесты, Code review. Одинм словом, разработчики должны стродать, пытаясь засунуть свой pull request в Мастер. Однако после того, как программист смог вмёржить код в основную ветку, он больше не отвечает за качество кода. Теперь, если случится баг на продакшене, виновата будет Фирма (компания, сообщество), которые построили pipeline, позволяющий влить некачественный код. Таким образом, у нас будет нормальная, рабочая атмосфера (blame free environment).

Используя вышеописанную философию, мы сразу убиваем несколько зайцев. Во-первых, программисты теперь не боятся писать код в больших системах. У нас не применяется практика Fear Driven Development, когда мы хотим как-нибудь легонько, локально впихнуть свою задачу, не сломав весь код. Мы можем смело рефакторить, зная что у нас хороший Code coverage, и большинство багов поймается тестами.

Другое преимущество использования огромного числа Линтеров — это борьба с Stale Branches — ветками, которые были отведены от мастера много недель назад, и теперь всем страшно вливать их в мастер, ведь тут много изменений, да и времени прошло много — вдруг что-то сломается. Такие ветки — это вообще перевод денег. Сначала мы тратим кучу времени на написание кода, а потом эта ветка никогда не будет вмёржена в основную кодовую базу проекта.

Давайте посмотрим на название доклада Егора — Не думайте о качестве, думайте о скорости. Тут же, на самом деле, спрятана ещё одна концепция Бугаенко. Он предлагает в фирмах платить программистам исключительно за количество выполненных задач. С точки зрения Егора, всё, что должен делать программист — это как можно больше мёржить пул реквестов, не думая про качество. Контролировать качество должны другие средсва — Код Ревью и Линтеры. Именно такая идеология используется в фирме Егора, где можно заказать разработку под ключ — https://www.zerocracy.com/policy.html.

Окей, теперь, когда мы обсудили доклад и книгу, можно перейти к практике. Думаю, что, если с утверждением — «программист не должен думать о качестве» сходу мало кто согласится, то о необходимости linters все понимают.

Подключить к проекту Линтеры, на самом деле, очень просто. Не важно, что там у вас — Jenkins, TeamCity, или Gitlab. Всегда есть декларативно объявленный pipeline, где есть этап Тестирования. Именно там и можно добавить проверки на качество кода.

В случае Java я рекомендую посмотреть вам на следующие продукты — Checkstyle, FindBugs, JaCoCo и SonarQube.

Для Golang, к счатсью, есть Мета-линтер — Go Meta Linter. Вы просто подключаете к проекту данный продукт, и указываете, какие Линтеры вам нужны. Мета-линтер сделает всё остальное для вас.

Например, вот так можно включить проверку кода на языке Go в Gitlab:

Список Линтеров был взят в проекте бесплатного чата — https://github.com/umputun/remark.

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

Категории: Программирование