Автоматизированная классификация изменений программного кода

1. Автоматизированная классификация изменений программного кода для повышения эффективности задач его обзора и анализа Князев Е.Г. Старший разработчик ЗАО «Транзас Технологии»; Аспирант СПбГУ ИТМО

2. Обзор программного кода (Code Review) • Повышает качество кода • Помогает найти ошибки на ранних стадиях • Помогает узнать код • Помогает курировать работу новичков

3. Система контроля версий и обзор изменений кода • Система контроля версий хранит всю историю разработки • Позволяет просматривать только изменившийся код Система контроля версий кода Запрос изменения Обзор Разработчик

4. Трудоемкость просмотра изменений • В крупных проектах необходим просмотр большого количества изменений

5. Метод решения проблемы • Автоматизация классификации изменений Система контроля версий кода Автоматизированный классификатор изменений Изменение Класс изменения Класс изменения интересен? Разработчик Просмотр Да

6. Классы изменений • Новая функциональность • Рефакторинг • Удаление кода • Косметическое изменение • Исправление ошибки

7. Известные методы классификации изменений • Метод классификации комментариев к изменениям • “bug”, “fixed” – исправление ошибки • “implement”, “feature” – новая функциональность • Метод поиска рефактоингов по метрикам изменений • Выделение предка класса (DIT>0 и NOM<0, …) • Перенос в другой класс (DIT=0 и NOM<0, …) • Разделение метода (NOM < T, ...) • Метод поиска разности в семантических графах • Строится граф кода до изменения, после изменения • Генерируется скрипт перехода • Происходит поиск шаблонов рефакторингов

8. Обучение метода

9. Классификация изменений

10. Метрики изменений • Рассчитываются как разность метрик ревизий • ∆M = Mr–Mr-1 • CC – цикломатическая сложность (количество независимых путей в графе исполнения) • CS– количество классов/структур • eLOC– эффективное число строк кода (без учета комментариев и пустых строк)

11. Алгоритм нечеткойкластеризации метрик изменений

12. Расчет метрик и кластеризация множества изменений Navi-Manager

13. Таблица принадлежности изменений нечетким кластерам

14. Пример обучения метода • Проект: Navi-Manager • Размер обучающего множества: 29 изменений • Количество кластеров: 4

15. Пример классификации

16. Нечеткость классификации • Изменение r16833 «Удалена лишняя команда (коммит)»классифицировано как: • на 2% рефакторинг • на 79% удаление кода • на 0% новая функциональность • на 20% исправление ошибки

17. Результаты • Применение метода в Navi-Managerпоказало его эффективность • От 50% экономии времени на обзоре кода • Выявлены проблемы разработки • Слишком большое число исправлений ошибок по сравнению среализацией новой функциональности

18. Инструмент автоматизированной классификации изменений • Работает с Subversion • Слабо зависит от языка программирования • Рассчитывает метрики CC, CS, eLOC • Выделяет следующие классы изменений • новая функциональность • удаление функциональности • рефакторинг • косметическое изменение • исправление ошибки*

19. Будущие исследования • Улучшение метода • Кластеризация по Гюстафсону-Кесселю • Объектные и другие метрики • Расширение внедрения • Использование в процессе разработки на постоянной основе • Оценивание применимости для различных типов проектов

20. Спасибо за внимание! Вопросы?