Доклад Дмитрия Химиона освещает концепцию технического долга, его виды и влияние на проекты, а также важность его учета в тестировании программного обеспечения. Рассматриваются методы измерения и контроля технического долга, а также роль стандартов качества, таких как ISO 9126. В заключение подчеркивается необходимость инструментов анализа и управления техническим долгом для повышения качества программных продуктов.

1. Технический долг:
взгляд и действия со стороны
QA / QC&AT
Дмитрий
Химион
Руководитель направления
автоматизации тестирования

2. Дмитрий Химион
руководитель направления
автоматизации тестирования
Performance Lab
Докладчик на конференциях:
SQA Days 13
ITSM Forum
SQA Days 14
SQA Days 15
SQA Days 16
Представлюсь

3. 1. Что такое технический долг?
2. Примеры влияния на проекты
3. Как относится к тестированию?
4. Как измерить и контролировать?
5. Внедрение
План доклада

4. Говард Каннингем – автор термина «технический долг»
Технический долг - это разница между идеальным
техническим решением и тем решением, которое
принимается сейчас (англ.яз - tech.debt).
Что такое технический долг?

5. • Осознанный (умышленный) – программист отказывается от гибкости кода или от
покрытия кода тестами, выигрывая время.
• Не осознанный – неопытность программиста в использовании конструкций языка
программирования или применении Framework-ов или платформ.
• Технологический – затягивание с обновлением версии платформы и framework
• Архитектурный – необходимость переработки архитектуры под новые требования
Разновидности технического долга

6. • Осознанный (умышленный) – программист отказывается от гибкости кода или от
покрытия кода тестами, выигрывая время.
• Не осознанный – неопытность программиста в использовании конструкций языка
программирования или применении Framework-ов или платформ.
• Технологический – затягивание с обновлением версии платформы и framework
• Архитектурный – необходимость переработки архитектуры под новые требования
Разновидности технического долга

7. Проект:
• Публичный гос.проект
• Целевая аудитория – жители РФ
Проблема:
• При нагрузке избыточная утилизация
аппаратных ресурсов
• Оптимизация критичных по производительности
компонент не помогает.
Примеры технического долга

8. Примеры технического долга
Причина проблемы - ошибка уровня normal-major
в использовании конструкции кода

9. DDT на функцию кода:
• mode = ‘debug’
build = ‘debug’
extBuild = ‘-debug’
themeBuild = ‘-debug’
• mode = ‘review’
build = ‘review’
extBuild = ‘-debug’
themeBuild = ‘-debug’
• mode = ‘anyOtherKey’
build = ‘review’
extBuild = ‘-debug’
themeBuild = ‘-debug’
Примеры технического долга

10. Примеры технического долга
break;
Не осознанный технический долг

11. Примеры технического долга

12. Примеры технического долга
Не осознанный технический долг

13. • Размер технического долга – показатель качества проекта.
• Качество программного обеспечения
Тестирование и Tech.debt

14. • Размер технического долга – показатель качества проекта.
• Качество программного обеспечения
Тестирование и Tech.debt
Стандарт - ISO 9126

15. • Размер технического долга – показатель качества проекта.
• Качество программного обеспечения
Тестирование и Tech.debt
ISO 9126 (ISO 25010) аспекты:
• Функциональность
• Надежность
• Практичность
• Эффективность
• Сопровождаемость
• Переносимость
Стандарт - ISO 9126

16. • Размер технического долга – показатель качества проекта.
• Качество программного обеспечения
Тестирование и Tech.debt
ISO 9126 (ISO 25010) аспекты:
• Функциональность
• Надежность
• Практичность
• Эффективность
• Сопровождаемость
• Переносимость
Стандарт - ISO 9126

17. • Размер технического долга – показатель качества проекта.
• Качество программного обеспечения
Тестирование и Tech.debt
ISO 9126 (ISO 25010) аспекты:
• Функциональность
• Надежность
• Практичность
• Эффективность
• Сопровождаемость
• Переносимость
Стандарт - ISO 9126
Аспект «Сопровождаемость»:
• Analyzability
• Changeability
• Testability
• Stability

18. • Размер технического долга – показатель качества проекта.
• Качество программного обеспечения
Тестирование и Tech.debt
ISO 9126 (ISO 25010) аспекты:
• Функциональность
• Надежность
• Практичность
• Эффективность
• Сопровождаемость
• Переносимость
Стандарт - ISO 9126
Аспект «Сопровождаемость»:
• Analyzability
• Changeability
• Testability
• Stability

19. Инструменты измерения tech.debt
Analyzability
SCA* Code review
Changeability
SCA Code review
Testability
Test coverage Mutation testing
* – статический анализ кода (static code analysis)

20. Инструменты измерения tech.debt
Analyzability
SCA Code review
Changeability
SCA Code review
Testability
Test coverage Mutation testing
Инструменты:
• SCA
• Code review
• Test coverage
• Mutation testing
• …
Инфраструктура разработки

21. Инструменты измерения tech.debt
Analyzability
SCA Code review
Changeability
SCA Code review
Testability
Test coverage Mutation testing
Инфраструктура разработки
Разработка
Тестирование
Инструменты:
• SCA
• Code review
• Test coverage
• Mutation testing
• …

22. Инструменты измерения tech.debt
Analyzability
SCA Code review
Changeability
SCA Code review
Testability
Test coverage Mutation testing
Инструменты:
• SCA
• Code review
• Test coverage
• Mutation testing
• …
Инфраструктура разработки
Разработка
Тестирование

23. Инструменты измерения tech.debt
SCA инструменты:
• Cppcheck
• PVS-studio
• Coverity
• Pylint
• Sonarqube
• FindBugs
• Resharper

24. Встраивание в инфраструктуру
quality gates – методология обеспечения качества

25. Измерение:
1. Анализа кода проекта
Измерение технического долга
Исходные
коды
• Получить
SCA
• Развернуть
• Настроить
Результат

26. Измерение:
1. Анализа кода проекта
Исходные
коды
• Получить
SCA
• Развернуть
• Настроить
Результат
Доступа к сорцам
может не быть
• Настроить GUI
• Установить плагины
• Интеграция с VCS
• Виртуалка или железка
• Установить ПО
Измерение технического долга

27. Измерение:
1. Анализа кода проекта
2. Принятие релевантных метрик*
* – проводится совместно с программистами
** – строк кода (Line Of Code)
Дублирование кода
Bugs per 1000 LOC*
Документирование кода
Комплексность кода
Составные метрики
Измерение технического долга

28. Измерение:
1. Анализа кода проекта
2. Принятие релевантных метрик*
* – проводится совместно с программистами
** – строк кода (Line Of Code)
Дублирование кода
Bugs per 1000 LOC*
Документирование кода
Комплексность кода
Составные метрики
Измерение технического долга
70% и более
Не больше 5%

29. Измерение:
1. Анализа кода проекта
2. Принятие релевантных метрик*
3. Устранение «шума» в измерениях*
* – проводится совместно с программистами
Измерение технического долга

30. Измерение:
1. Анализа кода проекта
2. Принятие релевантных метрик*
3. Устранение «шума» в измерениях*
* – проводится совместно с программистами
Измерение технического долга

31. Измерение:
1. Анализа кода проекта
2. Принятие релевантных метрик*
3. Устранение «шума» в измерениях*
* – проводится совместно с программистами
Измерение технического долга
151000 срабатываний на
сторонние библиотеки

32. Измерение:
1. Анализа кода проекта
2. Принятие релевантных метрик*
3. Устранение «шума» в измерениях*
* – проводится совместно с программистами
Измерение технического долга
150000 срабатываний на
сторонние библиотеки
92% ложных срабатываний

33. Измерение:
1. Анализа кода проекта
2. Принятие релевантных метрик*
3. Устранение «шума» в измерениях*
* – проводится совместно с программистами
• Positive false
• Не актуальные инспекции
• Ложный приоритет инспекций
• Проблемы с кодировками
• …
Измерение технического долга

34. Измерение:
1. Анализа кода проекта
2. Принятие релевантных метрик*
3. Устранение «шума» в измерениях*
4. Задать приемлемый уровень метрик*
* – проводится совместно с программистами
Измерение технического долга

35. Измерение:
1. Анализа кода проекта
2. Принятие релевантных метрик*
3. Устранение «шума» в измерениях*
4. Задать приемлемый уровень метрик*
* – проводится совместно с программистами
Измерение технического долга
Единая стилистика кода

36. 1. Инспектирование кода на периодической основе
2. Включение обсуждения «долгов» в планирование проекта
3. Прецедентная работы над приоритетами инспекций
Контроль tech.debt

37. 1. Слежение за трендами и метриками
2. Регулярный критический просмотр результатов
3. Работа по прецедентам*
Контроль tech.debt
* – проводится совместно с программистами

38. Не стоит внедрять, если ваш проект:
• Выводится из эксплуатации;
• Не планируется поддерживать после разработки;
• Прототип;
• Личный проект.
Внедрение в рабочий процесс

39. Внедрение в рабочий процесс
Обсудить выгоды от котроля tech.debt с руководством проекта:
1. Исправление дефектов на ранней стадии разработки;
2. Прогнозирование рефакторинга;
3. Исключение нелепых ошибок.

40. • Нет инструмента всеобъемлюще измеряющего tech.debt
• Измерение и контроль tech.debt – процесс итеративный
• Мониторинг tech.debt задача отдела контроля качества
• Измерение проблем проекта - «Осведомлён – значит вооружён»
Итоги
Предсказуемость влияния изменений на программу
Зрелость процессов
Прозрачность разработки и внесения изменений

41. Picasso-key
Дмитрий Химион Руководитель
направления АТ
Вопросы?
d.khimion@pflb.ru