Замаскированный под программиста бот исправляет ошибки в коде

[dmxrand]

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

[vesper-bot]

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

[Aniro]

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

[ruomserg]

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

[ruomserg]

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

[amarao]

Вы неправильно понимаете суть тестов. Питон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

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

[ruomserg]

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

[potan]

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

[ruomserg]

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

[Frankenstine]

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

[spidgorny]

Вот этот патч. Почти гениальное исправления. Я бы так не смог.
github.com/eclipse/ditto/commit/b8846ed19637d637405c1d61753b4280fc3454e0

[tungus28]

вспоминается лекция одного русского математика (имени не помню), который на основании теоремы Бёма — Якопини выводил доказательство того, что программист может быть заменен роботом, а вот тестировщик — нет)