Алексей Лустин. Непрерывная проверка качества кода.

Непрерывная инспекция кода

В режимах мультиязычной разработки микросервисов и микропродуктов

Авторский контекст

CTO SilverBulleters

https://github.com/allustin

Это история

Про бейджики

И про автоботов

И не совсем про статический анализ кода

Обычно говорят о проблемах

Code Review это очень дорого

В деньгах

4 часа в неделю на ревью изменений

8 часов в неделю на чтение патернов и книг

«Бесконечное количество» обсуждений

В итоге

12 * 52 = ?

50$ в час = ???

Почему так

Языков десятки

Требований к коду тысячи

Ресурсы всегда

ограничены

Люди любят один

(максимум) два языка

А еще все любят поговорить

А заказчик хочет «странного»

Микросервис на PHP (YII)

Приложение на TypeScript

Требования могут

формироваться на Gherkin

Интеграционные адаптеры – на

Java

Дополнительные компоненты – на

C#/Mono

В 2014 году мы решили

Чтобы кодировать будем командой

Нам в целом не важно на каком языке кодировать

Главное чтобы был один лидер по языку

Проверять код будем автоматически

7 смертных грехов программиста

Я не буду переводить стандартную статью от SonarQube.com

SonarQube как «платформа»

Инструмент для имплементации инженерной практики под называнием @ContiniousInspection

Содержит

• Сервис анализа Кода с большой буквы К

• Сервис хранения и расчета метрик

• Сервис отображения метрик

Через плагины

• Поддерживает автоматический CodeReview

• Поддерживает более 20 языков программирования

• Автоматическое назначение задачи на исправление

4 новых понятия

«Путь архитектора» (дорога цветов)

Порог качества продукта

Технический долг продукта

Правила кодирования

Даже на DEVELOP ветке

Pipeline

Разрабатывать в режиме множества парралельных проектов и сервисов невозможно без CI-CD

Автоматическое тестирование и сборка обязательна

Автоматическое развертывание (хотя бы на UAT) контуре предпочтительна

Pipeline

Стандартный pipeline позволяет

• Dev – Test – Uat

Мы добавляем

• Dev – Lint – Test - UAT

При старте любого проекта

• GIT – SonarQube

• Еще раньше CI-CD

На любую ветку

• И на каждый commit

Даже внутри команды !!!

Бот подключается всегда

Каждый коммит ?

Да именно каждый commit

Сборка считается упавшей

• Если в master или develop порог качества превышен

Остальное подключается через SonarLint

• Чтобы исключить проблемы раньше master и develop

«Linters» как возможностьпоказать себя ведущим программистом

Hooks

«Linters» как возможностьпоказать себя ведущим программистом

Hooks

Правила

Если в develop оказались

• Баги выше красного, включая безопасность

Это означается что мы

• Слишком быстро кодим

• Даже не проверяем свой код после написания

Не согласен ? Отключи

Срабатывание, но не правило

Правило отключает

• Архитектор

Автоботы

«На тебе !!! Чтобы ты подавился !!!»

• Commit to open merge request

Не забудьте отключить SMTP в большом проекте

В итоге наш стандарт

IDE + SonarLint

• VStudio, Eclipse, IDEA+, VSCode

DCVS (git)

CI server (Jenkins + VSTS + travis + AppVeyor + etc)

SonarQube

• SCM

• PHP, TypeScript, JS, CSS, HTML, Gherkin, Java, C#

• Russian

Как исследовали и включали

Результаты

Я забыл когда ревьюил код вручную

• По моему раз в месяц

Большую часть времени у меня уходит

• На проектирование архитектуры, которую пока автоматически ревьюить можно, но дорого ;-)

Команда

• Забыла когда допускала базовые ошибки или были серьезные баги в продуктиве, в основном сложные «плавающие» проблемы связанные с производительностью – но это уже другая история Continuous Performance Load.

Моя цель

Чтобы члены команды больше не использовали отговорку в виде «Я не очень умею на <LangName>»

• Подключи Sonar – он проверит

Донести до вас, что SonarQube должен быть встроен в процесс создания продукта раньше Jenkins Tests ;-)

• Потом не будет времени

Архитектура SB

ВОПРОСЫ ???Спасибо за внимание