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

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

Князев Е.Г.

Старший разработчик

ЗАО «Транзас Технологии»;

Аспирант

СПбГУ ИТМО

для повышения эффективности для повышения эффективности задач его обзора и анализазадач его обзора и анализа

Обзор программного кода (Обзор программного кода (Code Code ReviewReview))

2

Повышает качество кодаПомогает найти ошибки на

ранних стадияхПомогает узнать кодПомогает курировать работу

новичков

Система контроля версий и Система контроля версий и обзор изменений кодаобзор изменений кода

Система контроля версий хранит всю историю разработки

Позволяет просматривать только изменившийся код

3

Система контроля

версий кода

Разработчик

Обзор

Запрос изменения

Трудоемкость просмотра Трудоемкость просмотра измененийизмененийВ крупных проектах необходим просмотр

большого количества изменений

Проект Tortoise SVN

Navi-Manager

KDE

Размер, LOC

~ 200 тысяч

~ 250 тысяч

~ 4.7 миллион

а

Период наблюдения ~1 месяц

22.09.2007-22.10.2007

17.09.2007-

14.10.2007

Число изменений

215 72 11841 (!)4

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

5

Система контроля

версий кода

Изменение

Класс измененияинтересен?

Автоматизированныйклассификатор

изменений

Класс изменения

Да

Разработчик

Просмотр

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

6

Известные методы Известные методы классификации измененийклассификации изменений Метод классификации комментариев к

изменениям◦ “bug”, “fixed” – исправление ошибки◦ “implement”, “feature” – новая функциональность

Метод поиска рефактоингов по метрикам изменений◦ Выделение предка класса (DIT>0 и NOM<0, …)◦ Перенос в другой класс (DIT=0 и NOM<0, …)◦ Разделение метода (NOM < T, ...)

Метод поиска разности в семантических графах◦ Строится граф кода до изменения, после изменения◦ Генерируется скрипт перехода◦ Происходит поиск шаблонов рефакторингов

7

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

8

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

9

Метрики измененийМетрики измененийРассчитываются как разность

метрик ревизий◦ ∆M = Mr – Mr-1

CC – цикломатическая сложность (количество независимых путей в графе исполнения)

CS – количество классов/структурeLOC – эффективное число строк

кода (без учета комментариев и пустых строк)

10

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

11

Расчет метрик и кластеризация Расчет метрик и кластеризация множества изменений множества изменений Navi-Navi-ManagerManagerРеви-зия CC IC eLOC

Ближ. кластер

Комментарий к изменению

16820 -2 +1 -5 1

Процесс объединения кораблей в рамках одной транзакции.

16833 0 0 -1 2

Удалена лишняя команда (коммит).

17026 +4 +4 +18 3

Вывод широты, долготы в полном формате при поллинге.

17029 0 0 +1 4

Обновление MessageSource. UpdateTime после обработки каждого сообщения.

17038 0 0 -1 2

Откат изменений из r17029. Не нужно обновлять поле после обработки каждого сообщения.

17107 +4

+12 +89 3

Первая версия механизма загрузки треков с MonServer.

12

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

13

Ревизия / Кластер 1 2 3 4

16820 0,78 0,14 0,00 0,08

16833 0,02 0,79 0,00 0,20

17026 0,21 0,32 0,11 0,36

17029 0,03 0,30 0,00 0,67

17038 0,02 0,79 0,00 0,20

17107 0,1 0,11 0,68 0,11

Пример обучения методаПример обучения метода

Кластер Экспертный класс

1 Рефакторинг

2 Удаление кода

3Новая

функциональность

4 Исправление ошибки

14

Проект: Navi-ManagerРазмер обучающего множества: 29

измененийКоличество кластеров: 4

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

Ревизия

Ближ. класс

Ближ. кластер

Комментарий к изменению

16820 Рефакт. 1

Процесс объединения кораблей в рамках одной транзакции.

16833Удал.фун

. 2Удалена лишняя команда (коммит).

17026 Нов.фун. 3

Вывод широты, долготы в полном формате при поллинге.

17029Исправ. ошибки 4

Обновление MessageSource. UpdateTime после обработки каждого сообщения.

17038Удал.фун

. 2

Откат изменений из r17029. Не нужно обновлять поле после обработки каждого сообщения.

17107 Нов.фун. 3Первая версия механизма загрузки треков с MonServer.

15

Нечеткость Нечеткость классификацииклассификацииИзменение r16833 «Удалена

лишняя команда (коммит)» классифицировано как:◦на 2% рефакторинг◦на 79% удаление кода◦на 0% новая функциональность◦на 20% исправление ошибки

16

РезультатыРезультатыПрименение метода в Navi-Manager

показало его эффективность◦ От 50% экономии времени на обзоре

кодаВыявлены проблемы разработки

◦ Слишком большое число исправлений ошибок по сравнению с реализацией новой функциональности

17

Инструмент Инструмент автоматизированной автоматизированной классификации измененийклассификации измененийРаботает с SubversionСлабо зависит от языка

программированияРассчитывает метрики CC, CS, eLOCВыделяет следующие классы

изменений◦ новая функциональность◦ удаление функциональности◦ рефакторинг◦ косметическое изменение◦ исправление ошибки*

18

Будущие исследованияБудущие исследованияУлучшение метода

◦Кластеризация по Гюстафсону-Кесселю

◦Объектные и другие метрикиРасширение внедрения

◦Использование в процессе разработки на постоянной основе

◦Оценивание применимости для различных типов проектов

19

Спасибо за внимание!Спасибо за внимание!

Вопросы?

20