22 августа 2008

Debugging using binary search

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

Решение такой проблемы на корню: обвешивание всего кода юнит-тестами и прогон всех тестов после каждого коммита. Однако не всегда это реализуемо. Либо тесты писать времени нет, либо очень сложно их писать (например, для GUI).

В таком случае можно прибегнуть к двоичному поиску. У нас есть репозиторий и можно получить функцию от номера ревизии - воспроизводится ли данный баг в этой ревизии или нет. Например, в 500-ой его не было а сейчас 1030-ая и он есть. Делим отрезок ревизий [500,1030] пополам, попадаем где-то в 765-ую, апдейтимся до нее, ребилдим проект, смотрим воспроизводится ли баг. Не воспроизводится? Значит он где-то в отрезке [765,1030]. Делим его пополам, и т.д пока не найдем отрезок длинной в один коммит, например [897,898]. Значит 898-ой коммит вызвал появление бага. Смотрим этот коммит и разбираемся в чем дело, выясняем какие изменения привели к багу.

Если коммиты небольшие по объему (а я рекомендую именно так и делать), то довольно быстро можно понять где вылез баг и пофиксить его.

5 комментариев:

Unknown комментирует...

В git для этого как раз есть bisect.

Kirill V. Lyadvinsky комментирует...

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

Anatoly Borodin комментирует...

причём git-bisect можно гонять по тестам вручную, а можно подсунуть скрипт, который даст результат "баг/не_баг/не_скомпилилось"

Raider комментирует...

git впереди планеты всей

Анонимный комментирует...

Давно пользуюсь такой методикой 8)