Привет. В этом году один из самых известных 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:
image: golang:1.11 before_script: - go version - pwd - cd $GOPATH/src - mkdir -p gitlab.com/$CI_PROJECT_NAMESPACE - cd gitlab.com/$CI_PROJECT_NAMESPACE - ln -s $CI_PROJECT_DIR - cd $CI_PROJECT_NAME stages: - test Code lint: stage: test except: - /^[0-9]+\./ script: - "go get -u github.com/alecthomas/gometalinter" - "gometalinter --install --update" - "gometalinter --disable-all --deadline=300s --vendor --enable=vet --enable=vetshadow --enable=golint --enable=staticcheck --enable=ineffassign --enable=errcheck --enable=unconvert --enable=deadcode --enable=gosimple --exclude=test --exclude=mock --exclude=vendor ./..."
Список Линтеров был взят в проекте бесплатного чата — https://github.com/umputun/remark.
Надеюсь, теперь и в ваших проектах появится статический анализ. Ведь это та вещь, которая практически за бесплатно позволит вам снизить количество багов, а также позволит иметь более чистный код.
Категории: Программирование