Планирование отладки
Теперь, коротко рассмотрев типы и происхождение ошибок, перейдем к процессу отладки. Многие начинают думать об отладке только тогда, когда на этапе кодирования сталкиваются с аварийным завершением. Думать же об этом следует с самого начала, на этапе разработки требований. Чем лучше спланирован проект, тем меньшее количество времени (и денег) будет затрачено на последующую его отладку.
Как было сказано выше, "расползание" свойств может стать бедствием для проекта. В большинстве случаев незапланированные свойства вводят ошибки и наносят ущерб продукту. Однако это не означает, что в планы не могут быть внесены изменения. Иногда необходимо изменить свойства продукта или добавить новые, чтобы стал более конкурентоспособным и соответствовал запросам пользователя. Главное, перед изменением кода следует точно определить и спланировать все изменения. И имейте в виду, что добавление свойств затрагивает не только код, но воздействует и на тестирование, и на документацию. Существует правило, согласно которому время, необходимое для добавления или удаления свойства, растет экспоненциально по мере приближения к концу производственного цикла.
В превосходной книге Стива Макконнелла "Искусство кодирования" (Steve McConnell. Code Complete. — Microsoft Press, 1993, pp. 25—26) говорится о стоимости исправления ошибки. Сценарий тот же, что и при добавлении или удалении свойств — на этапе разработки требований и планирования стоимость исправления ошибки невелика, однако в процессе дальнейшей работы она растет экспоненциально; то же самое происходит и со стоимостью отладки.
Планирование отладки идет вместе с планированием тестирования. Во время планирования нужно искать способы ускорения и улучшения обоих процессов. Одна из самых лучших предосторожностей, которые вы можете предпринять, состоит в написании специальных программ сброса файловых данных (file data dumpers) и проверки достоверности (validators) для внутренних структур данных, а также для двоичных файлов, если это необходимо. Если приложение читает и пишет данные в двоичный файл, следует написать тестирующую программу, которая будет сбрасывать (dumps) данные в удобочитаемом формате в текстовый файл. Программа сброса (dumper) должна также проверять достоверность данных и все взаимозависимости в двоичном файле. Этот шаг сделает как тестирование, так и отладку более легкими.
Правильное планирование отладки позволяет минимизировать время работы с отладчиком (в этом и состоит ваша цель). Может показаться, что в книге по отладке такой совет выглядит странно, но идея состоит в том, чтобы попробовать совсем избежать ошибок. Встройте такой отладочный код в свои приложения, чтобы именно он (а не отладчик) сообщал вам, где находятся ошибки. Вопросы, касающиеся отладочного кода, рассмотрены в главе 3.
