[articles] refactoring detection

[stacymiller]

[articles] refactoring detection

[stacymiller]

Брыксин, Шпильман что-то недавно писали про рефакторинги

[kilomeow]

Критерии, по которым можно охарактеризовать прочитанные статьи:

• Summary концептов, изложенных в этой статье. Если идеи уже похожи на изложенные в других статьях, то указать это.
• Применимость изложенного подхода к нашей задаче. Если да, то как.
• Ключевые референсы, возможности развития этого подхода.
• Мой вывод, картинка, которая складывается в голове

[kilomeow]

Начну со статьи On Automatically Generating Commit Messages via
Summarization of Source Code Changes:

• Подход: проанализировать изменения в ast, выявить стереотипные, по шаблону сгенерировать для них commit message
• Их подход можно буквально имплементировать используя вывод gumtree, но это будет излишне. Можно использовать часть предложенных ими шаблонов, для того, чтобы отработать большие изменения, которые нельзя будет скормить модельке -- это Class rename, Method rename и Object state rename. Среди их шаблонов отсутствует случай перемещения блока кода/метода из одной части кода в другую (и из одного файла в другой, но это вообще отдельная история).
• мне показались важными ссылки на вот эти две статьи:
  N. Dragan, M. Collard, M. Hammad, and J. Maletic. Using stereotypes to help characterize commits. In ICSM’11, pages 520–523, 2011.
  [7] N. Dragan, M. Collard, and J. Maletic. Reverse engineering method stereotypes. In ICSM’06, pages 24–34, 2006.
  Мне кажется что их подход близок к границам своей применимости -- можно пытаться придумывать еще шаблоны, но не уверен, что сообщения комитов станут от этого на порядок более читаемыми.
• Шаблоны это неплохо, и мы от них никуда не денемся, по крайней мере в случае больших изменений кода. Но для конкретных изменений в небольших кусках кода они дают довольно слабые и не совсем human-readable описания. Итог -- можно следовать их подходу для обработки всех изменений на уровне деклараций классов/методов/файлов, заодно добавив туда возможность отслеживать перемещения больших кусков кода, которую предоставляет gumtree. После этого надо еще научится работать с изменениями внутри методов/добавлением новых методов (было бы хорошо, если бы это было не просто сообщение add method <method_name>, а краткое описание той функциональности, для которой он был введен, возможно нам поможет здесь code2seq).

[kilomeow]

Automated Refactoring of Object-Oriented Code Using Clustering Ensembles

• Ввести метрики набор метрик для специальных вершин ast -- классов и методов, каждой такой вершине теперь соответствует вектор со значениями этих метрик, можно кластеризовать. На основе перемещений из кластера в кластер можно выявить рефакторинги: Move Method, Extract Class, Inline Class, Move Field
• Идея довольно интересная, однако gumtree уже детектит перемещения кусков кода, поэтому полученные рефакторинги не очень актуальны в контексте нашей работы (разве что могут помочь проверить, что gumtree корректно работает). Однако, метрики могут быть полезны. Можно сравнивать эти метрики до и после, а также показания code2seq, и на основе этого пытаться провести кластеризацию рефакторингов (= обучить модель которая будет выдавать категории).
• Вот эти две статьи явно очень интересные
  Marian, Z.-E. 2014. Machine learning based software de- velopment. Ph.D. Dissertation, Faculty of Mathematics and Computer Science, Babes-Bolyai University.
  Pan, W.; Jiang, B.; and Xu, Y. 2013. Refactoring packages of object-oriented software using genetic algorithm based com- munity detection technique. Int. J. Comput. Appl. Technol. 48(3):185–194.
  Развитий этого подхода я вижу два -- усложнять кластеризацию или добавлять метрики. Первое, пожалуй, совсем нам не в тему -- нам все таки нужны не кластеры, которые характеризуют код, а кластеры, характеризующие изменения в коде. А вот дополнительные метрики могут быть очень кстати, так что имеет смысл над ними подумать.
• Метрики это круто. Пусть их идея буквально и не состыкуется с нашей задачей, мне нравится оригинальность их подхода, и я надеюсь, что его можно будет использовать для оценки изменений внутри методов.