Download as PDF, PPTX
Uploaded byScrumTrek
Алексей Лустин. Непрерывная проверка качества кода.
Документ описывает непрерывную инспекцию кода в мультиязычной разработке микросервисов, акцентируя внимание на автоматическом анализе кода с помощью SonarQube и интеграции CI/CD. Автор подчеркивает важность высокого качества кода и автоматизации процессов для уменьшения затрат на ручное ревью. Основная цель заключается в том, чтобы команда больше не использовала недостаток знаний в языке программирования как оправдание ошибок в коде.
More Related Content
Similar to Алексей Лустин. Непрерывная проверка качества кода.
Алексей Лустин. Непрерывная проверка качества кода.
- 1. Непрерывная инспекция кода В режимахмультиязычной разработки микросервисов и микропродуктов
- 2.
- 3. Это история Про бейджики Ипро автоботов И не совсем про статический анализ кода
- 4. Обычно говорят опроблемах Code Review это очень дорого
- 5. В деньгах 4 часав неделю на ревью изменений 8 часов в неделю на чтение патернов и книг «Бесконечное количество» обсуждений
- 6. В итоге 12 *52 = ? 50$ в час = ???
- 7. Почему так Языков десятки Требований к кодутысячи Ресурсы всегда ограничены Люди любят один (максимум) два языка
- 8. А еще вселюбят поговорить
- 9. А заказчик хочет«странного» Микросервис на PHP (YII) Приложение на TypeScript Требования могут формироваться на Gherkin Интеграционные адаптеры – на Java Дополнительные компоненты – на C#/Mono
- 11. В 2014 годумы решили Чтобы кодировать будем командой Нам в целом не важно на каком языке кодировать Главное чтобы был один лидер по языку Проверять код будем автоматически
- 12. 7 смертных греховпрограммиста Я не буду переводить стандартную статью от SonarQube.com
- 13. SonarQube как «платформа» Инструментдля имплементации инженерной практики под называнием @ContiniousInspection Содержит • Сервис анализа Кода с большой буквы К • Сервис хранения и расчета метрик • Сервис отображения метрик Через плагины • Поддерживает автоматический CodeReview • Поддерживает более 20 языков программирования • Автоматическое назначение задачи на исправление
- 14. 4 новых понятия «Путьархитектора» (дорога цветов) Порог качества продукта Технический долг продукта Правила кодирования
- 15. Даже на DEVELOPветке
- 17. Pipeline Разрабатывать в режимемножества парралельных проектов и сервисов невозможно без CI-CD Автоматическое тестирование и сборка обязательна Автоматическое развертывание (хотя бы на UAT) контуре предпочтительна
- 19. Pipeline Стандартный pipeline позволяет •Dev – Test – Uat Мы добавляем • Dev – Lint – Test - UAT При старте любого проекта • GIT – SonarQube • Еще раньше CI-CD На любую ветку • И на каждый commit
- 20.
- 21.
- 22. Каждый коммит ? Даименно каждый commit Сборка считается упавшей • Если в master или develop порог качества превышен Остальное подключается через SonarLint • Чтобы исключить проблемы раньше master и develop
- 23. «Linters» как возможность показатьсебя ведущим программистом Hooks
- 24. «Linters» как возможность показатьсебя ведущим программистом Hooks
- 25. Правила Если в developоказались • Баги выше красного, включая безопасность Это означается что мы • Слишком быстро кодим • Даже не проверяем свой код после написания
- 26. Не согласен ?Отключи Срабатывание, но не правило Правило отключает • Архитектор
- 27. Автоботы «На тебе !!!Чтобы ты подавился !!!» • Commit to open merge request Не забудьте отключить SMTP в большом проекте
- 28. В итоге нашстандарт 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
- 29.
- 30. Результаты Я забыл когдаревьюил код вручную • По моему раз в месяц Большую часть времени у меня уходит • На проектирование архитектуры, которую пока автоматически ревьюить можно, но дорого ;-) Команда • Забыла когда допускала базовые ошибки или были серьезные баги в продуктиве, в основном сложные «плавающие» проблемы связанные с производительностью – но это уже другая история Continuous Performance Load.
- 31. Моя цель Чтобы членыкоманды больше не использовали отговорку в виде «Я не очень умею на <LangName>» • Подключи Sonar – он проверит Донести до вас, что SonarQube должен быть встроен в процесс создания продукта раньше Jenkins Tests ;-) • Потом не будет времени
- 32.
- 33.