Причины неудач внедрений. Место статического анализа в DevOps-процессе. Статический анализ – друг или враг. Рассылка результатов анализа. Что делать с 10 000 сообщений от анализатора при первом запуске? Сколько времени нужно для правки всех ошибок? Q&A, или что дальше?

1. Что DevOps
должен знать про
статический
анализ кода?
Евгений Рыжков, PVS-Studio

2. Кто я?
• Евгений Рыжков – руководитель и
сооснователь PVS-Studio;
• Год основания компании: 2008;
• Офис - г. Тула (200 км от Москвы),
штат 30 человек;
• PVS-Studio – статический
анализатор кода для C, C++, C# и
Java на Windows, Linux и macOS
• «CEO? А давно ли CEO
программировал?»

3. Ни слова про PVS-Studio больше…

4. Содержание
• Причины неудач внедрений.
• Место статического анализа в DevOps-процессе.
• Статический анализ – друг или враг.
• Рассылка результатов анализа.
• Что делать с 10 000 сообщений от анализатора при первом запуске?
• Сколько времени нужно для правки всех ошибок?
• Q&A, или что дальше?

5. Что такое статический анализ кода?
.. и как про него рассказывают на конференциях.

6. Причины неудач внедрений
• Технические.
• Технические.
• Технические.
• Организационные.

7. Место статического анализа в
DevOps-процессе
• Егор Бугаенко. Главное не качество, а количество!
• Automated Build
• Unit Tests
• Test Coverage
• Mutation Coverage
• Static Analysis
• Code Reviews
• Read-Only Master
Видео доклада на DevOpsConf Moscow 2018:
https://devopsconf.io/moscow/2018/abstracts/3723

8. Статический анализ – друг или
враг (когда, как и почему)
• Как избежать позора?
• В зависимости от того, где и как внедрен инструмент люди к нему
относятся по-разному. И это не зависит от языка разработки.
• Ошибка найдена по месту и тут же исправлена? Отлично, я молодец!
• Ошибка найдена на билд-сервере? Все видят мой фейл, давайте
вырубим этот анализатор!

9. Рассылка результатов статического
анализа (всем или не всем)
• Очевидные плюсы и неочевидные минусы.
• У программиста завтра есть более важные дела, чем правка
сегодняшней ошибки. И они действительно более важные в какой-то
момент, а потом забывается.

10. Кого еще добавлять в рассылку
• Бывает нужно ставить в копию письма начальника (так себе конечно);
• Неплохая идея добавлять в копию коллег для обучения;
• Тим-лида в копию, чтобы был в курсе о правке багов – нормально.

11. Что делать с 10 000 сообщений от
анализатора при первом запуске?
•НИ-ЧЕ-ГО!

12. Сколько времени нужно
для правки всех ошибок?
• Ожидания • Реальность
0
5
10
15
20
25
1 2 3 4 5
Warnings
0
5
10
15
20
25
1 2 3 4 5
Warnings

13. Так сколько нужно времени?
• Проект 10 млн строк кода
• 5 тысяч срабатываний анализатора
• Команда: 3-4 человека
• Время правки 3-4 месяца
• Общие трудозатраты: 10-15 человеко-месяцев
• Почему нельзя использовать эти данные для оценки :-)

14. Заключение
• Статический анализ – это процесс не только технический, но и прежде
всего организационный.
• Эффективность внедрения и использования статического анализа
зависит от правильного выстраивания процессов.
• Ответственным за правильный процесс должен быть менеджер (тим-
лид, PM, CTO), но DevOps должен понимать суть процесса и
подсказывать менеджеру, если тот не понимает что-то.
• Хорошо себя зарекомендовала практика найти в компании энтузиаста
этой технологии, который будет ее продвигать.

15. Q&A, или что дальше
• Скачайте анализатор, поиграйтесь с ним.
• Обучите коллег, внедрите в своей проект.
• Получите повышение и бонус за внедрение современных практик. :-)
Главная мысль, которую вы должны вынести из доклада:
• Статический анализ в ближайшие несколько лет будет как юнит-тесты
или системы контроля версий. Раньше жили и без них, но «так жить
нельзя».