Алексей Лустин. Непрерывная проверка качества кода
TRANSCRIPT
Непрерывная инспекция кода
В режимах мультиязычной разработки микросервисов и микропродуктов
Это история
Про бейджики
И про автоботов
И не совсем про статический анализ кода
Обычно говорят о проблемах
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
ВОПРОСЫ ???Спасибо за внимание