Автоматизированный программист Repairnator сделал патчи достаточно хорошие для того, чтобы ввести в заблуждение людей


«В этом мире ничего нельзя заявить определённо, кроме неизбежности смерти и налогов», — писал Бенджамин Франклин в 1789. Если бы он жил сегодня, он мог бы ещё добавить в этот список ошибки в программах.

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

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



Сегодня их мечты сбываются благодаря работе Мартина Монпераса и его друзей из Королевского технологического института в Стокгольме, Швеция. Они, наконец, сделали бота, способного соревноваться с людьми в деле поиска багов и написания качественных патчей.

Ребята назвали бота Repairnator и успешно испытали его, позволив соревноваться с программистами-людьми в поисках исправлений. «Это важная веха на пути к состязаниям с людьми в деле исследований автоматического исправления программ», — говорят они.

Специалисты по информатике давно знают о возможности автоматизации процесса написания патчей. Непонятно лишь, могут ли боты делать эту работу так же быстро и качественно, как люди.

Поэтому Монперас с компанией решили проверить своего бота, замаскировав его под человека-разработчика и позволив ему состязаться с людьми в деле разработки патчей для GitHub, сайта для программирования с контролем версий. «Ключевая идея Repairnator – автоматически создавать патчи, исправляющие ошибки в сборках, показывать их людям-разработчикам, и наблюдать, примут ли разработчики эти патчи как достойные включения в код», — сказали они.

Команда зарегистрировала на GitHub пользователя Luc Esape, якобы программиста из их лаборатории. «У Люка есть фото в профиле, он выглядит разработчиком-юниором, жаждущим вносить вклад в разработку открытого кода на GitHub», — говорят они.

На самом деле, Люк – это Repairnator под прикрытием. Обман был нужен, поскольку модераторы склонны к тому, чтобы оценивать работу ботов и людей по-разному. «Скрытность была необходима, чтобы проверить научную гипотезу о соревновательной способности людей», — говорят Монперас с компанией, уже сообщившие всем заинтересованным сторонам о происходящем.

Команда сделала два подхода к проверке Repairnator. Первое испытание шло с февраля по декабрь 2017, когда она запускала Repairnator на постоянном списке из 14 188 проектов с GitHub в поисках ошибок. «Мы обнаружили, что наш прототип способен делать порядка 30 попыток исправлений в день», — сказали они.

За это время Repairnator проанализировал более 11 500 проектов с ошибками. Он смог воспроизвести ошибки в более чем 3000 случаев. В 15 случаях он смог разработать патч.

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

Второй подход был более успешным. Команда отправила Люка работать над сервисом непрерывной интеграции Travis с января по июнь 2018. Хотя команда не уточняет, что именно они изменили в Repairnator, 12 января он написал первый патч, принятый модератором в сборку. «Иначе говоря, Repairnator впервые смог выйти на уровень человека», — говорят они. За последовавшие шесть месяцев Repairnator выдал пять патчей, принятых модераторами.

Впечатляющее достижение, открывающее путь новому поколению методов разработки ПО. Оно также поднимает интересные вопросы. Разработчики обращают внимание на патч, который Repairnator разработал 12 мая для проекта eclipse/ditto.

После этого команда получила письмо от одного из разработчиков проекта: «Мы принимаем пул-реквесты от пользователей, подписавших лицензионное соглашение Eclipse Foundation Contributor».

Это порождает неприятную проблему, поскольку бот не может подписать лицензионное соглашение. «Кому принадлежит интеллектуальная собственность, и кто отвечает за вклад бота: оператор бота, автор бота, дизайнер алгоритма исправлений?» – задаёт вопрос команда разработчиков.

Такого рода проблемы стоит решить до того, как люди и боты смогут совместно работать дальше. Но Монперас и его команда оптимистично смотрят в будущее. «Мы считаем, что Repairnator служит прототипом будущего разработки ПО, в котором боты и люди без проблем сотрудничают и становятся партнёрами в деле поиска недостатков в ПО», — говорят они.

Франклин, сам известный изобретатель, наверняка был бы впечатлён происходящим.

Комментарии (11)


  1. dmxrand
    26.10.2018 10:29
    +2

    На каком Яп тренировались?


  1. vesper-bot
    26.10.2018 11:08
    +1

    11500 проектов — а языки какие? eclipse/ditto судя по всему ява-проект, но опять-таки непонятно, в какой части кода был патч от бота, может, в мета-коде (Dockerfile, скажем).


    1. Aniro
      26.10.2018 11:54
      +2

      Java: github.com/lucesape
      Ожидаемо, там патчи уровня запуска линтера с ключом --fix, забытую проверку на null добавил, например.
      Даже интереснее — он умеет только NPE исправлять, причем естественно не проверяет, возможно ли оно там вообще.


      1. ruomserg
        26.10.2018 12:03

        Причем, в одном случае люди потом вынесли проверку за цикл, а в другом случае — это действие, фактически, маскирует проблему с конфигурацией программы. В этой ситуации, неудивительно, что люди не различили робота перед собой — лечением симптомов проблемы одинаково занимался бы и программист и ИИ. В общем, создается впечатление, что авторы бота-программиста увидели обычную вежливость к незнакомому разработчику со стороны мейнтейнера, и навыдумывали себе на этой почве невесть что… А так, судя по-описанию, обычный rule-based ИИ. И правила, скорее всего, вручную пишут…


  1. ruomserg
    26.10.2018 17:15

    И еще одна мысль. Распространение таких ботов покончит с тестированием кода. Потому что если тест выявляет проблему — это повод задуматься, откуда она взялась. Может ли в этой точке объект быть null? Если нет, то почему это не было проверено раньше? Если да, то где еще он используется — и проверяется ли он на null там, и т.д. То есть упавший тест, в идеале, сообщает нам о наличии некоторой системной проблемы — которую следует обнаружить и разрешить. А после прохода бота, у нас тесты-то будут все зелененькие, но программа продолжит падать — потому что тесты больше ничего не тестируют. Они с обратной стороны аккуратно закрыты ботовыми заглушками!


    1. amarao
      26.10.2018 22:50

      Вы неправильно понимаете суть тестов. Питон2:

      def op(x, y):
          return x/y
      
      def test_op_even():
          assert op(4, 2) == 2
      
      def test_op_odd():
         assert op(3, 2) == 1.5
      


      Второй тест фейлится. Как будет выглядеть ботофикс?


      1. ruomserg
        27.10.2018 08:12

        Два момента. Первое: тесты бывают разные, и падают они по-разному: один тест может упасть потому что не прошла валидация выходных параметров (ассерты), а другой, посложнее, может и с экспешеном в недрах завершиться. И, насколько видно, сейчас бот охотится именно за последними исключениями. Второе: если начать фантазировать — то ботофикс для второго теста будет выглядеть примерно так: if(x==3 && y==2) return(1.5) — он же бот и не думает, правда. Я не очень знаю систему типов питона, поэтому предполагаю что этот ботофикс ничего не даст, и бот его откатит. Но это сложный случай, потому что нужно менять тип возвращаемого значения. А вот замазать NullPointerException путем оборачивания строчки в if(object!=null) {упавший_код;} еще как автоматически можно. При этом, конечно, проблема не переданного объекта никуда не исчезает — она вытесняется за границу теста. То есть тест не падает, а после деплоя в продакшн с этим эксепшеном падает сразу все приложение.


  1. potan
    26.10.2018 19:56

    А как бы его на свой проект натравить?


    1. ruomserg
      27.10.2018 08:14

      Любой статический анализатор лучше натравить, я думаю…


  1. aquarium
    26.10.2018 20:38

    Жду не дождусь того дня когда на хабре Siri будет сливать карму Алисе за неудачный комментарий. И почему-то мне кажется что ждать осталось не долго.


  1. Frankenstine
    27.10.2018 14:02

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