Как стать автором
Обновить

Комментарии 15

А можно примеры автоматически сгенерированных комментариев? По BLEU не особо-то оценишь, получилось ли что-то осмысленное. Комменты к коммитам — только в мире розовых пони — лучший образец «перевода» изменений на человеческий язык.

Согласна, примеров в посте не хватает. Можно посмотреть примеры лучшей из наших моделей для всей тестовой выборки в табличке в проекте Weights & Biases. Хотела привести конкретные хорошие и плохие примеры, но тут может быть немного субъективно :) В целом качества недостаточно, чтобы использовать такой метод на практике для генерации полноценных сообщений.

Извиняюсь за долгий ответ!

Задача составления сообщений на основе содержания коммита - это генерация бесполезного для читателя текста.

Причина довольно простая: качественное сообщение коммита должно отвечать на вопрос "зачем этот коммит был сделан".

На вопрос "что этим коммитом было изменено" в общем-то, отвечает само содержание.

Зря вы так...
Да, ситуация, когда автор коммита описывает его намерение сам - идеальна. Но, раз мы уже говорим о том, что

"что этим коммитом было изменено" в общем-то, отвечает само содержание.

то надо понимать, что содержание коммита представлено намного более низкоуровневым языком, чем тот, который оптимален для задачи мануальной оценки/поиска коммитов или их обсуждения.

Поэтому, компромиссная ситуация, когда читатель не получает комментарий автора о намерении, но получает трансляцию исходного кода в некий сверхвысокоуровневый человекочитаемый DSL, вполне сносна для человека.

Ну и да, не надо думать, что железяка совсем уж тупая и с этой задачей не справится. Уже были эксперименты с GPT3, где компьютер генерировал фрагменты программ по человекочитаемому ТЗ, - почему не допустить, что и обратная задача под силу?

Никто и не говорит, что железка тупая. Но сообщения же пишутся не железками для железок, а для других людей или будущих себя.


То, что оно представлено более низкоуровневым языком — это не проблема вообще, код же читают люди, которые пишут программы. И чтобы понять, что именно было изменено — достаточно поглядеть дифф или даже список файлов, в некоторых случаях.


А вот почему этот коммит был сделан — на этот вопрос уже никак не ответить, если человек, который его сделал уже забыл/уволился/умер, а контекст внесения изменений очень важен. Важнее, чем пересказ изменений человекочитаемым DSL.


А ситуация, когда автор коммита описывает намерение — это нормальная ситуация. Неправильно — если он этого не делает. Причём для этого не нужно что-то супер подробное писать, часто достаточно "fixes #123". Иначе история изменений становится бесполезной и в проекте всё плохо с регламентом.

НЛО прилетело и опубликовало эту надпись здесь
Естественно. У него же нет ничего, кроме кода. А там эта информация (о цели изменения) отсутствует.
Вообще в работах, на которых мы основывались, предполагается, что по содержимому коммитов часто можно понять в том числе и зачем они были сделаны.

Для современных методов это возможно, но во многом зависит от данных для обучения. Далеко не всегда мотивация коммита явно видна по внесенным изменениям, но при обучении на некотором количестве похожих примеров нейросети вполне могут уловить общий смысл.

Правда, исследований, насколько это так на самом деле, не проводилось: сложно придумать какие-то автоматические метрики для оценки такой характеристики, а при опросе людей в предыдущих работах оценивалась только близость сгенерированных сообщений к реальным. Ещё немного осложняет ситуацию то, что в открытых репозиториях, из которых собирались данные, есть примеры не только вида "зачем был сделан коммит", но и "что было сделано в коммите". Замечание очень важное, об этом стоит подумать, спасибо Вам :)
И вот опять же вы говорите о «методах», но забываете о данных. «Для современных методов это возможно»: возможно что? Повторять ошибки, которые делают пользователи?

Вы считаете, что метод, который дает результат, близкий к предсказанным — это хорошо, но не всегда это так. Например, можно было бы реализовать модель, которая исправляет грамматику в тексте так, чтобы повторять типичные ошибки, присутствующие в данных. Хорошо ли это? Вы пытаетесь реализовать бота, который будет лениться так же, как ленятся люди. Правильный ли это путь? «Нейросети вполне могут уловить общий смысл»: они НЕ могут уловить смысл, которого не может быть в коде. Программирование — это в том числе и творчество. Нейронка может «уловить общий смысл», сказав, что стихотворение, начинающееся словами «Ночь, улица, фонарь, аптека» — это стихотворение об аптеке, более того, это стихотворение так и называется (и тут нейронка явно обрадуется тому, что все так легко предсказывается). Но вот беда: «Ночь, улица, фонарь, аптека» — это не то, что описывает суть произведения. А как нейронка образуется тому, что черный квадрат Малевича называется именно «Черным квадратом»! Она даже не задумается о том, зачему автору потребовалось изображать эту геометрическую фигуру аж четыре раза в течение жизни: наоборот, это будет способствовать подтверждению уверенности модели. Нейронка нисколько не смутится тому, что «Красный квадрат» того же автора имеет слегка скошенную форму. Но вот беда: то, что ныне известно под названием «Красный квадрат» выставлялось при жизни автора под названием «Живописный реализм крестьянки в двух измерениях».

Так вот на практике выходит, что разработчик, который пытается реализовать какую-нибудь «крестьянку», коммитит невнятную скошенную геометрическую фигуру, описанную (неверно) коммит сообщением как «красный квардат». С трудом проходит ревью, а уже последующие поколения гадают, что за хрень хранится в репозитории. Так коммит за коммитом нарастает ком грязи, впоследствии именуемый легаси кодом. Я сомневаюсь в пользе автоматического тула для упрощения генерации кома грязи.

IMHO, автоматическую генерацию коммитов можно реализовать через поиск убранных "//TODO:" и "//fixme:" и добавленных. Это можно было бы объединить с багтрекером, или issue.

Смотрю на таблицу с результатами и ничего не понимаю.
Что значат цифры? Что такое Bleu-4? NMT?
Где потерялся обзор результатов?
BLEU — метрика качества из области нейронного машинного перевода, в данном случае она оценивает близость между автоматически сгенерированными сообщениями и соответствующими реальными. Подробнее можно почитать, например, тут или в оригинальной статье.

NMT и все остальное из раздела «Существующие работы» — названия методов из предыдущих исследований в этой области, цифрами рядом с ними обозначены статьи из списка в конце поста.

Пояснений к табличке с результатами действительно мало, в будущем постараюсь поработать над этим :)

Извиняюсь за долгий ответ!
«много интересных задач, автоматическое решение которых может пригодиться для создания удобных инструментов для разработчиков» — типичная ситуация, когда лень одного человека оборачивается головной болью остальных. Вы поставили телегу вперед лошади: это не сообщение к коммиту должно отражать содержимое, а наоборот: коммит должен отражать идею разработчика, а сообщение содержать внятное описание того, зачем этот коммит понадобился. Напрашивается аналогия с поворотниками у автомобиля: поскольку есть категория водителей, не утруждающих себя обозначением маневра сигналами поворотников, взять и «изобрести» девайс, который будет включать их сам при повороте руля… Тоже как бы «автоматическое решение для удобства», только теряется сам смысл.

Поскольку я ярый поборник дисциплины в использовании Git, написании точных и осмысленных комментариев, я бы хотел использовать ссылку на данную разработку как пример антипаттерна. Буду очень благодарен, если вы приведете пример комментария, который система выдает на коммит, содержащий сортировку пузырьком.

Чтобы немного подсластить пилюлю: с академической точки зрения работа интересная. Возможно, она имеет смысл для аннотирования старого легаси кода. Но ее практическое применение именно для автоматической генерации сообщений к новому коммиту способно нанести немалый вред.
Не совсем поняла, в чем Вы видите главную проблему — в использовании содержимого коммита для генерации сообщений или в попытках автоматизации этой задачи в принципе. Поэтому мне сложно судить, в чем заключается возможный вред от подобной системы. Буду благодарна, если Вы подробнее распишете свою мысль, всегда интересно услышать разные мнения :)

Попробовала запустить одну из моделей с коммитом с сортировкой пузырьком, она, увы, не справилась — результат выглядит так. Но тут стоит сказать, что в открытом датасете, на котором она обучена, вряд ли присутствуют похожие примеры.

Описанный в посте этап проекта скорее исследовательский. Полученные модели не планируется использовать для генерации сообщений на практике, но методы на их основе могут пригодиться, например, для того, чтобы предлагать пользователям варианты нескольких следующих токенов при вводе сообщений.
Спасибо за ответ. Да, я вижу вред в автоматизации этой задачи.

Повторюсь: с академической точки зрения задача интересная. Предлагать пользователям варианты следующих токенов? Возможно, что в такой постановке все не столь страшно, но все же направление, IMHO, с практической точки зрения вредное.

Когда-то считалось, что код — это язык передачи идеи от человека машине. Сейчас все более проявляется другая идея: что код есть язык передачи идеи от одного инженера другому. А вот истории коммитов это касается в особенности. В современной парадигме уже даже комментарии считаются моветоном, т.к. они очень быстро устаревают, и почти никогда не обновляются. Место комментариев занимают сообщения коммитов: вот они-то не устареют никогда, т.к. аннотируют не код, а его место в истории. Это по сути становится основным способом одного инженера передать мысль другому. И эта мысль является метаинформацией, не следующей напрямую из diff-а. По хорошему, сообщение коммита должно отвечать на следующие вопросы:
  • в чем состояла проблема, которую решает данное изменение;
  • каковы ограничения данного решения;
  • что бы произошло, не будь данный коммит применен;
  • насколько важным было применение данного коммита;

и т.д.

На практике, к сожалению, инженеры часто воспринимают необходимость оставить сообщение как ненужную бюрократическую сложность. Репозитории кишат коммитами со словами «WIP» (Work In Progress), «Changes after review», «Tests added», «Codestyle fixed», «Fix build», «Fix typo». История превращается в жуткий мусор. Впрочем, не только история, но и сам код начинает напоминать здание с разбитыми окнами, где каждый следующий, ужаснувшись текущему состоянию, оставляет мусора не меньше, чем уже было. Что будет, если сообщения будет составлять бот? Если сейчас я еще могу как-то достучаться до разработчика, что так нельзя, что «WIP» не должен попадать в историю, то дальше у людей появится индульгенция: «а что, это бот сам мне предложил». Короче, я считаю, что написание сообщение коммита — это ручная работа, и она не должна быть упрощена. Более того, ее цель — усложнить жизнь тех, чьи коммиты сложно описать словами. Ну вот как код ревью: это некий процесс, который не должен быть очень простым. Что проще было бы его автоматизировать: сразу аппрувить любой коммит, избавляя команду от «ненужной» сложности ручной работы?

Резюмирую: ваша работа хороша с точки зрения эксперимента. Я понимаю ваше желание увидеть в ней практическое применение, но, пытаясь рассуждать о нем, вы наступаете на больнючую мозоль инженеров, работающих с кодом практически, и имеющих дело не с идеализированным миром, а с жутким паноптикумом укоренившихся анти-паттернов. Пусть хорошее исследование останется хорошим исследованием, не толкайте его раньше времени в мир, где оно станет плохой привычкой.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий