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

2.
Авторский контекст
CTO SilverBulleters
https://github.com/allustin

3.
Это история
Про бейджики
И про автоботов
И не совсем про статический
анализ кода

4.
Обычно говорят о проблемах
Code
Review
это очень
дорого

5.
В деньгах
4 часа в неделю на ревью
изменений
8 часов в неделю на чтение
патернов и книг
«Бесконечное количество»
обсуждений

6.
В итоге
12 * 52 = ?
50$ в час =
???

7.
Почему так
Языков
десятки
Требований к
коду тысячи
Ресурсы
всегда
ограничены
Люди любят
один
(максимум)
два языка

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

9.
А заказчик хочет «странного»
Микросервис на
PHP (YII)
Приложение на
TypeScript
Требования
могут
формироваться
на Gherkin
Интеграционные
адаптеры – на
Java
Дополнительные
компоненты – на
C#/Mono

10.
В 2014 году мы решили
Чтобы кодировать будем
командой
Нам в целом не важно на
каком языке кодировать
Главное чтобы был один
лидер по языку
Проверять код будем
автоматически

11.
7 смертных грехов программиста
Я не буду
переводить
стандартную
статью от
SonarQube.com

12.
SonarQube как «платформа»
Инструмент для имплементации инженерной практики под называнием
@ContiniousInspection
Содержит
• Сервис анализа Кода с большой буквы К
• Сервис хранения и расчета метрик
• Сервис отображения метрик
Через плагины
• Поддерживает автоматический CodeReview
• Поддерживает более 20 языков программирования
• Автоматическое назначение задачи на исправление

13.
4 новых понятия
«Путь архитектора» (дорога цветов)
Порог качества продукта
Технический долг продукта
Правила кодирования

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

15.
Pipeline
Разрабатывать в режиме множества парралельных
проектов и сервисов невозможно без CI-CD
Автоматическое тестирование и сборка обязательна
Автоматическое развертывание (хотя бы на UAT)
контуре предпочтительна

16.
Pipeline
Стандартный pipeline позволяет
• Dev – Test – Uat
Мы добавляем
• Dev – Lint – Test - UAT
При старте любого проекта
• GIT – SonarQube
• Еще раньше CI-CD
На любую ветку
• И на каждый commit

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

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

19.
Каждый коммит ?
Да именно каждый
commit
Сборка считается
упавшей
• Если в master или develop
порог качества превышен
Остальное подключается
через SonarLint
• Чтобы исключить проблемы
раньше master и develop

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

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

22.
Правила
Если в develop оказались
• Баги выше красного, включая
безопасность
Это означается что мы
• Слишком быстро кодим
• Даже не проверяем свой код после
написания

23.
Не согласен ? Отключи
Срабатывание,
но не правило
Правило
отключает
• Архитектор

24.
Автоботы
«На тебе !!! Чтобы ты
подавился !!!»
• Commit to open merge request
Не забудьте отключить
SMTP в большом
проекте

25.
В итоге наш стандарт
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

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

27.
Результаты
Я забыл когда ревьюил код вручную
• По моему раз в месяц
Большую часть времени у меня уходит
• На проектирование архитектуры, которую пока автоматически ревьюить можно,
но дорого ;-)
Команда
• Забыла когда допускала базовые ошибки или были серьезные баги в
продуктиве, в основном сложные «плавающие» проблемы связанные с
производительностью – но это уже другая история Continuous Performance Load.

28.
Моя цель
Чтобы члены команды больше не использовали
отговорку в виде «Я не очень умею на <LangName>»
• Подключи Sonar – он проверит
Донести до вас, что SonarQube должен быть встроен
в процесс создания продукта раньше Jenkins Tests ;-)
• Потом не будет времени

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

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