Поиск трудновыловимой ошибки делением пополам
6 июня 2012
Случается так, что день потрачен на попытку обнаружить причину ошибки, но дело так и не сдвинулось с мёртвой точки. Например, огромная куча JavaScript ещё вчера работала, а сегодня уже отказывается. Причём проявляется это на тестовом сервере, где эта самая куча сжимается и объединяется в один файл.
Для подобных трудновыловимых ошибок, как, впрочем, и для многих других подходит деление пополам.
Если используется система контроля версий, откатываемся на некоторое время назад и смотрим, есть ли ошибка. Если есть — откатываемся ещё. Если нет — идём вперёд ровно на половину. Так мы получим ревизию, которая всё испортила. Далее дело за малым.
Примерно так же можно поступать в вёрстке, если вдруг вылез супербаг. Убиваем половину кода и смотрим, остался ли баг.
Плюс такого подхода в том, что ошибка гарантированно локализуется. Минус — это не быстро.
Комментарии RSS по email OK
Двоичный поиск ))) знакомо
нууу бинарный поиск это долго... давайте заведем для коммитов Дерево ван Эмде Боаса o_O будет лог(лог(n))
Такой же примерно принцип используется в диагностике неисправностей радиоэлектронной техники :)
Похожий подход можно и при отладке использовать - отметить ключевые, важные места и посмотреть как они ведут себя..
В git как раз есть инструмент для этого: git bisect
Когда не работает сжатый яваскрипт, в большинстве случаев надо искать не поставленную точку с запятой в конце файла.
lusever, а что, бывает, что разжатого варианта не сущетвует?
Не однозначно. Вопрос быстроты [в данном случае] будет сводиться к степени изолированности изменений в коммитах. Временные расходы по жонглированию коммитами должна брать на себя VCS (см. комментарий Рустама).
Это называется метод дихотомии. Как-то пришлось его для себя открыть при неработающем htaccess