Устойчивая привязка к синтаксическим конструкциям в изменяющемся коде
•Download as PPTX, PDF•
0 likes•291 views
Михаил Малеванный, ДГТУ
Recommended
More Related Content
Viewers also liked
Viewers also liked (8)
Similar to Устойчивая привязка к синтаксическим конструкциям в изменяющемся коде
Similar to Устойчивая привязка к синтаксическим конструкциям в изменяющемся коде (20)
More from CEE-SEC(R)
More from CEE-SEC(R) (20)
Устойчивая привязка к синтаксическим конструкциям в изменяющемся коде
- 1. XII международная конференция CEE-SECR / РАЗРАБОТКА ПО 28 - 29 октября, Москва Михаил Малеванный Устойчивая привязка к синтаксическим конструкциям в изменяющемся коде Академия Строительства и Архитектуры Донской Государственный Технический Университет
- 2. Введение Предыдущий доклад (SECR-2015): «Аспектная разметка кода для быстрой навигации по проекту» Реализация: https://github.com/MikhailoMMX/AspectMarkup 2
- 4. Рабочее множество... ...его: Трудно найти Легко потерять Невозможно забыть вспомнить 4
- 5. Chris Parnin and Spencer Rugaber. Resumption strategies for interrupted programming tasks. Software Quality Journal 19, 1 (March 2011), 5-34. DOI=http://dx.doi.org/10.1007/s11219-010-9104-9 «Только в 7% случаев перед редактированием не выполняется навигация по коду» «Только в 10% случаев активная деятельность начинается в пределах минуты после возврата к задаче» 5
- 6. 6
- 8. 8 560 полей и методов 206 методов visit
- 9. 9
- 10. Задача 1 Рабочее множество 1 Задача 2 Рабочее множество 2 10
- 11. Навигационные ссылки в 1C:Предприятие 11
- 12. Навигационная ссылка в IDE 12 • Почта • Баг-трекер • …
- 13. Модель привязки • Сохраняемая информация 13
- 14. Синтаксическое дерево Строится легковесным парсером по исходному коду Общее для разных языков Не зависит от среды разработки A B2B1 C1 C2 C3 D1 D2 E 14
- 15. Сохраняемая информация Имя + заголовок Тип Контекст Родительские узлы Соседние узлы Дочерние узлы A B2B1 C1 C2 C3 D1 D2 E 15
- 16. Сохраняемая информация Имя + заголовок Тип Контекст: Родительские узлы A B2B1 C1 C2 C3 D1 D2 E 16
- 17. Сохраняемая информация Имя + заголовок Тип Контекст: Родительские узлы Соседние узлы * Подузлы * A B2B1 C1 C2 C3 D1 D2 E 17
- 18. Имя и заголовок (Java) public Component addChild(Component child) { repository.connectComponents(this, child, EdgeKind.CONTAINS); return child; } private int id; Заголовок Имя 18
- 19. Типы узлов (Java) public Component addChild(Component child) { repository.connectComponents(this, child, EdgeKind.CONTAINS); return child; } private int id; Тип: Method Тип: Field 19
- 20. Внешний контекст (С#) • namespace N • class C1 : IVisitor • namespace N • class C2 : IVisitor namespace N { class C1 : IVisitor { public void visit(IVisitor v) { } } class C2 : IVisitor { public void visit(IVisitor v) { } } } 20
- 21. Горизонтальный контекст (yacc) selection_statement : IF '(' expression ')' statement ELSE statement IF '(' expression '(' ELSE statement ... IF '(' expression '(' statement ELSE ... 21
- 22. Внутренний контекст (Pascal) var X, Y : Double; var Name, Address : string; Age : integer; • X, Y : Double • Name, Address: String • Age : Integer 22
- 23. Модель привязки • Алгоритм поиска в изменяющемся коде 23
- 24. T – исходный узел Ti – узлы в новом файле Для всех Ti вычисляем величину «похожести»: Si = Similarity(T, Ti) Si ∈ [0, 1]; 0 = ничего общего, 1 = точное совпадение Величина похожести 24
- 25. Редакционное расстояние Минимальное количество правок, необходимых для преобразования одной строки в другую Выше Редакционное расстояние – ниже Похожесть 3 версии: Имена (String) Заголовки (Lists<String>) Внешние контексты (List<Headers>) 25
- 26. Примеры метрики «похожести» Строка 1 Строка 2 Похожесть String String 1 load_file loadFile 0.77 nextInt nextDouble 0.4 String Object 0 26
- 27. Примеры метрики «похожести» private static uint GetManagedResourceOffset( ManagedResource resource, BlobWriter resourceWriter) private static uint GetManagedResourceOffset( ManagedResource resource, BlobBuilder resourceWriter) public string GetLine(int LineIndex) public bool IsDocumentOpen(string FileName) = 0.95 27 = 0.33
- 28. Аналогия с помехоустойчивыми кодами 28
- 29. Аналогия с помехоустойчивыми кодами 29 Сущности
- 30. Аналогия с помехоустойчивыми кодами 30 int GetHashCode() void WithAttributes() event EventHandler(…) void visit(statement) void visit(expression)int Count() async Task TestElseIf()
- 31. Аналогия с помехоустойчивыми кодами 31 Изменения
- 32. Аналогия с помехоустойчивыми кодами 32 Изменения
- 33. Аналогия с помехоустойчивыми кодами 33
- 34. Аналогия с помехоустойчивыми кодами 34 Изменения
- 35. Аналогия с помехоустойчивыми кодами 35
- 36. Пример неоднозначности поиска Первая версия: class expr : Node { public void Visit(Visitor _vis) { /* */ } } Вторая версия: class Expression : Node { public void Visit(Visitor _vis) { /* */ } } class Statement : Node { public void Visit(Visitor _vis) { /* */ } }Исходный фрагмент Переименован Добавлен 36
- 38. Разрешение неоднозначности поиска 38 Исходный узел из _expr из Expression из Statement
- 40. Методика Ревизия 1 (начало анализа) Ревизия 2 (конец анализа) Initial commit Исследуемый период Ревизии: Привязка ко всем сущностям в ревизии 1 Проверка привязки в ревизии 2 40
- 41. Изменено файлов 95 из 2 668 Изменено сущностей 406 из 83 082 (0,5%) #326 Начало анализа #653 Конец анализа #1 Initial commit 9 месяцев разработки Ревизии: 41
- 42. Предварительный результат поиска узлов 246160 Выдан список узлов Узел найден 42
- 43. Предварительный результат поиска узлов 246160 Выдан список узлов Узел найден 43
- 44. Удаленные узлы 211 35 160 Выдан список узлов Узел удален Узел найден 44
- 45. Удаленные узлы 211 35 160 Выдан список узлов Узел удален Узел найден 45
- 46. Без удаленных узлов 211160 Выдан список узлов Узел найден 46
- 47. Без удаленных узлов 211160 Выдан список узлов Узел найден 47
- 48. Перемещенные узлы 100 111 160 Выдан список узлов Узел перемещен Узел найден 48
- 49. Перемещенные узлы 100 111 160 Выдан список узлов Узел перемещен Узел найден 49
- 50. Анализ перемещенных узлов 100 98 13 160 Выдан список узлов Выдан список узлов (перемещенные) Узел найден (перемещенные) Узел найден 50
- 51. После учета перемещенных узлов 198173 Выдан список узлов Узел найден 51
- 52. Результат поиска узлов 198173 Первый результат в списке Узел найден 52
- 53. Окончательный результат поиска узлов 371 Найдено безошибочно 53
- 54. Окончательный результат поиска узлов 371 Найдено безошибочно 100% 54
- 55. Roslyn 55
- 57. Roslyn Изменено файлов 2 584 из 4 995 Изменено сущностей 20 534 из 152 271 (13,5%) Начало анализа Конец анализа Initial commit 1 год разработки 10 340 ревизий 57
- 58. Roslyn Изменено сущностей: 20 534 (...много) 58
- 59. Roslyn Изменено сущностей: 20 534 (...много) Взята выборка из 500 случайных* сущностей * RandomShuffle(), SubList(0, 500). 59
- 60. Предварительный результат поиска узлов 132 368 Выдан список узлов Узел найден 60
- 61. Предварительный результат поиска узлов 132 368 Выдан список узлов Узел найден 61
- 62. Удаленные узлы 83 49 368 Выдан список узлов Узел удален Узел найден 62
- 63. Удаленные узлы 83 49 368 Выдан список узлов Узел удален Узел найден 63
- 64. После учета удаленных узлов 83 368 Выдан список узлов Узел найден 64
- 65. После учета удаленных узлов 83 368 Выдан список узлов Узел найден 65
- 66. Перемещенные узлы 78 5 368 Выдан список узлов Узел перемещен Узел найден 66
- 67. Перемещенные узлы 78 5 368 Выдан список узлов Узел перемещен Узел найден 67
- 68. Анализ перемещенных узлов 78 1 4 368 Выдан список узлов Выдан список узлов (перемещенные) Узел найден (перемещенные) Узел найден 68
- 69. После учета перемещенных узлов 79 372 Выдан список узлов Узел найден 69
- 70. После учета перемещенных узлов 79 372 Выдан список узлов Узел найден 70
- 71. Анализ неавтоматически найденных узлов 75 4 372 Первый результат в списке Не первый результат в списке Узел найден 71
- 72. Анализ неавтоматически найденных узлов 75 4 372 Первый результат в списке Не первый результат в списке Узел найден 72
- 73. Анализ автоматически найденных узлов 75 4 2 370 Первый результат в списке Не первый результат в списке Ошибочный результат Узел найден 73
- 74. Окончательный результат поиска узлов 445 6 Узел найден безошибочно Ошибочный результат 74
- 75. Окончательный результат поиска узлов 445 6 Найдено безошибочно Ошибочный результат 98.7% 75
- 76. Результат PascalABC.NET 326 ревизий 9 месяцев Roslyn 10340 ревизий 1 год 371 445 6 76
Editor's Notes
- На прошлогодней конференции была представлена разметка кода и инструмент. Сейчас я вкратце напомню цели и основные возможности разметки кода, после чего рассмотрим, как достигается устойчивость привязки к коду.
- Одна из проблем, с которыми ежедневно сталкиваются разработчики – это сквозная функциональность. Код, относящийся к решаемой задаче оказывается разбросан по всему проекту, и разработчику требуется держать в голове набор фрагментов, с которыми ему приходится работать. Будем называть его рабочим множеством.
- При этом на формирование такого множества тратится время, и при переходе к каждой задаче этот процесс нужно повторять. Если приходится отвлечься на другую задачу или по другим причинам, то потом приходится это рабочее множество восстанавливать заново.
- Исследование показывает, что после возврата к задаче разработчику почти всегда требуется просмотреть несколько мест в проекте, прежде чем он сможет продолжить работу и на это требуется время
- Которое может достигать от нескольких минут до часа и более.
- Разметка кода позволяет сохранить рабочее множество, сгруппировав фрагменты кода по задачам и подзадачам в произвольном виде.
- Разметка кода упрощает навигацию по текущему рабочему множеству. В больших проектах нужно еще постараться найти, а потом не потерять нужное место. И к нему нужно регулярно переходить.
- С использованием разметки жить становится проще. Множество фрагментов кода на виду, оно небольшое, в нем легко найти нужный фрагмент. И, в отличие от закладок, разметка к фрагменту привязывается более надежно.
- Разметка позволяет быстрее переключаться между задачами. Вот мы поработали пару недель над чем-то и нам нужно вернуться к предыдущей задаче, и что-то исправить. Вот оно, наше рабочее множество, заботливо собрано и сохранено.
- В 1С:Предприятии есть навигационные ссылки, это ссылки на документы в базе данных. Их можно отправить, например, по почте другому сотруднику. Это удобно. Правда, с объектами в базе данных проще, у них есть первичный ключ, по которому его можно найти, даже если он изменился. А с кодом это не так.
- Можно экспортировать кусочек разметки, передать другому разработчику или прикрепить к задаче или к баг-репорту где-нибудь в системе управления проектами. Особенно важно, что привязка – устойчива к изменению, ведь в это время разработчик может редактировать код. Сохраняется не номер строки, который может «поехать», а некоторая другая информация. Ее и рассмотрим.
- Мы привязываемся не к номерам строк, а к синтаксическим конструкциям в исходном коде на разных языках
- В сохраняемая информация берется из дерева разбора исходного кода. Оно строится легковесными парсерами. В составе инструмента есть несколько легковесных парсеров для нескольких языков, а при необходимости их не очень сложно дописать самостоятельно. Привязываться можно к любым узлам этого дерева. Мы не зависим от инфраструктуры конкретных сред разработки, что дает нам возможность встраивать инструмент в разные среды разработки и работать с разными языками, лишь бы для них был парсер.
- После этого если нам надо привязаться к некоторому узлу, то мы сохраняем следующий набор данных
- Имя и заголовок узла, а также его тип. Родительские узлы. Этой информации хватает во многих случаях, но не во всех.
- Кроме этого, дополнительно могут храниться соседние узлы и подузлы. В некоторых языках без этого не обойтись, кроме того это повышает устойчивость привязки.
- В заголовок может входить несколько лексем, среди которых отдельно может выделяться одна – это имя. Оно наиболее важно.
- Кроме того, хранение типа позволяют ускорить поиск и отсечь ненужные сущности в коде.
- Вот типичный пример, когда нужно хранить родительские узлы. У нас есть несколько одинаковых методов, но они входят в разные классы или пространства имен. Методы в классе уникальны, классы – тоже.
- Но так бывает не всегда. Фрагмент из грамматики ANSI C, в нем два раза встречается нетерминал statement. Хранение соседей позволяет их различить и найти нужный. Ключевое слово ELSE находится слева от одного из них и справа от другого.
- А в некоторых случаях узлы дерева могут не иметь собственного имени, как секции объявления переменных в языке Pascal, но различить их можно по вложенным узлам. Хранение даже небольшого подмножества узлов позволяет привязаться к конкретной секции.
- Но самое главное – по этой информации найти нужное место в коде, после того как код поменялся.
- У нас есть информация о старом узле T, и набор узлов Ti из нового файла. Вычисляется степень похожести искомого узла и всех узлов в дереве. При вычислении величины похожести используется вся сохраняемая информация, но с разными весами.
- Для этого используется редакционное расстояние или расстояние Левенштейна. Вычисляется оно для имен, заголовков (список строк) и внешних контекстов (списков имен – списков списков строк), при каждой следующей версии используется предыдущая.
- Пример похожести для отдельных лексем. Для похожих лексем она ближе к единице, для разных – близка к нулю.
- Если изменился только тип одного параметра – похожесть близка к единице. Если это два разных метода – то и похожесть будет ближе к нулю.
- В алгоритме поиска прослеживается аналогия с помехоустойчивыми кодами и тем, как они восстанавливают переданные сообщения после воздействия на них помех.
- Пусть в некотором файле есть несколько сущностей
- В некотором смысле, расстояние между ними тем меньше, чем более похожи эти сущности.
- Если какой-то узел
- изменился несильно, то он по-прежнему будет самым похожим на исходный с большим отрывом от остальных узлов.
- И он будет успешно и с высокой уверенностью найден. Здесь показаны, своего рода, области, в которых изменения безопасны. Они зависят от наличия поблизости других узлов.
- Но если изначально есть много других, очень похожих сущностей в коде,
- То даже небольшое изменение может привести к потере привязки.
- В некоторых случаях изменения могут быть досаточно сильными. Здесь привязка осуществлялась к методу класса. Класс был переименован и добавлен другой класс с таким же методом. Возникает неоднозначность.
- В этом случае выдается список узлов, отсортированных по величине похожести.
- В заголовке отображается исходный узел, а чуть ниже видны два метода visit, один из класса expression, другой из класса statement. Первый имеет более высокую степень похожести за счет того, что исходное имя класса expr больше похоже на Expression, чем на statement.
- А теперь рассмотрим, насколько же устойчивой получилась такая привязка.
- Берем две ревизии одного проекта и в первой из них привязываемся вообще ко всему, тотально и параноидально. То есть ко всем узлам, к которым в принципе возможна привязка. А во второй ревизии ищем все сохраненные узлы.
- В качестве первого проекта был взят PascalABC.NET За половину истории проекта в нем изменилось 406 сущностей. Считаются только изменения классов, заголовков методов и т.д., но не кода внутри методов. 406 - это немного, но как раз в процессе работы и нужна разметка, поэтому продолжаем.
- Получается не очень красивый результат. Примерно одна треть узлов находится автоматически, для остальных требуется участие разработчика. Давайте разбираться, почему так.
- Часть фрагментов кода была удалена за это время. Были поля и методы, которые уже не использовались, а затем они были подчищены. Инструмент всегда пытается найти сущность или помочь с ее поиском, даже если она была удалена. А если она была на самом деле удалена (это может понять разработчик), то он удалит и разметку. Мы такие случаи не рассматриваем.
- Выбрасываем их из рассмотрения.
- Уже чуть лучше. Дальше, среди оставшихся случаев есть…
- 111 фрагментов кода, перемещенных в другие файлы. Проводился рефакторинг. Пока в нашем инструменте файл сохраняется как есть, поэтому привязка ищется в исходном файле. Можно будет доделать и глобальный поиск, но пока есть возможность указать другой файл и поискать в нем. Что и было сделано.
- В результате эти случаи были переанализированы
- Часть из них теперь находится полностью автоматически, а часть – по прежнему требует участия разработчика.
- Теперь посмотрим повнимательнее на вот эту категорию «выдан список узлов»
- Так вот оказывается, что все до единого результаты поиска в этой категории попадают на первую строчку в списке наиболее вероятных узлов. Просто отрыв от второго места не двукратный. Это все возникает в случае если есть похожие сущности. Например, визитор, обрабатывающий иерархию узлов дерева (более 200 узлов), когда у нас изначально в одном классе есть сотни методов, отличающихся только типом одного параметра. Сама иерархия узлов. И тому подобные, достаточно сложные места в коде.
- Если немного поправить правило поиска и выдавать первый результат в списке, то получается вот такая картина. Поэтому такой результат можно считать очень хорошим.
- Мы получаем, грубо говоря, 100% точность поиска. С одной оговоркой – среди тех узлов, которые физически остались в коде. Удаленные узлы, как вы помните, мы исключали из рассмотрения.
- Или вот такой проект. Roslyn. Он побольше и развивается поактивнее.
- Для анализа я сразу решил взять интервал в один год разработки…
- …и оказалось, что за это время было сделано более 10 тысяч ревизий. Ну что же, тем интереснее будет посмотреть результаты.
- Изменилось за это время 20 с половиной тысяч сущностей, анализировать их вручную слишком долго
- Поэтому была взята выборка из 500 случайных узлов. Список был перемешан в случайном порядке (RandomShuffle, и взяты первые 500 элементов списка) Эту выборку и посмотрим.
- Здесь соотношение уже сразу лучше, почти три четверти узлов находятся автоматически. Смотрим дальше.
- Так же, как и в прошлом проекте, часть из не найденных узлов была удалена. Или изменена настолько, что найти этот код не удалось. Можно сказать, что некоторые вещи были полностью переписаны. Все-таки год разработки и 10 тысяч ревизий.
- Выбрасываем и их.
- И смотрим дальше
- Всего 5 сущностей было перемещено в другой файл
- Проверяем их
- Из них 4 теперь находятся автоматически и одна – нет.
- Теперь посмотрим на вот этот сектор (выдан список узлов).
- Здесь ситуация чуточку хуже. Почти все узлы оказываются на первом месте в списке, но 4 узла изменились сильнее, но их все же можно быстро найти в списке похожих узлов.
- А вот еще в двух случаях инструмент с полной уверенностью выдает неправильный узел.
- В итоге получается такое соотношение правильных и неправильных результатов поиска
- Тем не менее, в плохих случаях все же можно посмотреть список похожих узлов и быстро найти нужный. К тому же, сюда я отнес один случай, когда один большой метод был разбит на два и оба они занимали первые две строчки, но большая часть полезных действий была все же во втором методе, а значит скорее всего, разработчику потребуется заглядывать в список результатов. Я его отнес к ошибочным результатам, хотя это спорный момент. Привести примеры Успешный и не успешные
- Это и так большой период – год. Образный пример про город спустя 20 лет и старый план города. План это и есть разметка. Но плохая, статическая, не алгоритмическая. (В начало) А если добавить поддержку среды разработки, то будет 100%. За эти 100% мы и боремся.