Если вы думаете, что окончательно исправили ошибку, то на следующем шаге отладки протестируйте исправление повторно, причем лучше несколько раз. Если ошибка находится в строке кода в изолированном модуле, вызываемом только один раз, тестирование исправления выполняется легко. Однако если исправление находится в корневом модуле, особенно в том, который управляет структурами данных, то следует соблюдать особую осторожность, — исправление может коренным образом повлиять на работу других частей проекта.
При тестировании исправлений, особенно в критическом участке кода, нужно удостовериться, что оно работает со всеми состояниями данных — и "хорошими" и "плохими". Ничего нет хуже, чем исправление одной ошибки, которое вызывает две других. Если изменение вносится в критический модуль, то вся команда должна знать об этом. Только тогда станет возможной помощь коллег в обнаружении любых эффектов, наведенных этими изменениями.
История отладочных войн
Сражение
Один из разработчиков, с которым автор работал в NuMega, думал, что он нашел большую ошибку в интегрированной среде разработки программ на Visual C++ (VC IDE1) фирмы NuMega, потому что VC IDE не работала на его машине.
Для тех, кто незнаком с этой средой, приведем небольшую справку. Программные продукты NuMega интегрированы в VC IDE, благодаря чему окна, панели команд и меню NuMega являются частью интерфейса среды VC IDE.
1VC IDE — Visual C++ Integrated Development Environment (Интегрированная Среда Разработки программ на языке Visual C++). Разработчики данной фирмы сокращенно называют эту систему VC IDE-интеграцией (VC IDE integration). — Пер.
Результат
Этот разработчик потратил часа два, исследуя "ошибку" с помощью SoftlCE. Через некоторое время, установив контрольные точки по всей операционной системе, он заметил, что при запуске VC IDE функция API CreateProcess называлась "\\R2D2\VCommon\MSDev98\Bin\MSDEV.EXE", а не "C:\VSCommon \MSDev98\Bin\MSDEV.EXE", как должно было быть.