5. Какой объем тестирования обычно осуществляют инженеры проекта?

Важно знать, чего от вас ждут, и обеспечить соответствующий уровень тестирования. Но не ограничивайтесь этим – делайте то, что необходимо.

Напишите модульные тесты для всех созданных вами фрагментов ко% да. Если нужно модифицировать чужой код, напишите сначала для него тест, если его еще нет. Благодаря этому вы узнаете, как он работа% ет в настоящее время, что нужно исправить и как проверить, что ваши модификации ничего не испортили.

Глава 9. Поиск ошибок

Вопросы для размышления

1.Следует ли требовать, чтобы ошибки исправлял тот программист, ко торый написал код? Или программист, обнаруживший ошибку, лучше сможет ее исправить?

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

С другой стороны, автору кода, скорее всего, проще внести исправле% ние. Он знает свой код вдоль и поперек (в идеале), знает, какие послед% ствия может иметь конкретное изменение. Он раньше других может указать, где находится источник ошибки.

На практике выбор того, кто исправит ошибку, может определяться наличием свободного времени у программистов, а также наличием других обязанностей у членов команды. Если ошибка в программе из% вестна с незапамятных времен, автор кода может быть уже недосту% пен. Он может покинуть компанию, перейти в другой проект или (что самое ужасное) перейти на руководящую работу.

2.Как определить, что лучше – воспользоваться отладчиком или поду мать?

Даже отладчик нужно применять разумным образом. (Помните золо% тое правило отладки?)

Я пользуюсь следующим практическим правилом: не запускай отлад% чик, не определив, какую информацию хочешь от него получить. Опасность заключается в том, что можно бродить с отладчиком по коду, не зная толком, что ты ищешь. Так можно потратить уйму времени и ничего не получить в результате.

3.Чтобы искать и исправлять ошибки в незнакомом коде, следует снача ла изучить его. Однако темпы работы организаций, производящих программное обеспечение, часто не позволяют уделить достаточно времени изучению и освоению ремонтируемой программы. Какая стратегия будет оптимальной в таких условиях?

В своих мечтах вы можете поколотить тех, кто составил такой график, и выделить столько времени, сколько надо, чтобы исправить ошибку, как она того требует. Однако проснемся…

Лучше всего постараться постепенно изучить код. Двигайтесь по нему с предельной осторожностью и не доверяйте своим впечатлениям: все% гда проверяйте, действительно ли код делает то, что должен по вашим представлениям. Если вам покажется, что вы нашли источник ошибки, поинтересуйтесь, не знаком ли кто%то из вашей команды с подозритель% ным кодом. Обсудите с ними свои планы. Часто во время объяснения си% туации вам становится ясной очевидная вещь, которую вы пропустили.

4.Предложите технологию, препятствующую возникновению ошибок утечки памяти.

Есть несколько хороших методов:

a.Воспользуйтесь языками, в которых их возникновение наименее вероятно, например Java или C#. (И в этих языках могут возник% нуть утечки. Знаете ли вы, в каких ситуациях?)

b.Пользуйтесь «безопасными» структурами данных, которые сами управляют выделением памяти, освобождая вас от этих хлопот.

c.Во избежание проблем применяйте полезные идиомы языка, такие как auto_ptr в C++.

d.Будьте последовательны и методичны при выделении памяти. Убе% дитесь, что на каждое выделение есть освобождение и оно всегда происходит.

e.Пропустите свой код через утилиты проверки работы с памятью и убедитесь в отсутствии ошибок.

5.В каких случаях оправдана кавалерийская атака на поиск и устране ние ошибки в противовес более методичному подходу?

Всегда нужно обдумывать свои действия. Даже скороспелые исправле% ния должны быть хорошо обдуманы. Не пытайтесь густо расставить в своем коде контрольные точки и начать копаться во внутренностях; думайте о том, как устроен код и какие действия от него предполага% лись.

Внутренний голос и непосредственные реакции могут помочь быстро найти ошибку в очень маленькой программе (скажем, из нескольких десятков строк). Но если в программе тысячи строк, необходимо по% нять, как она работает. Ничто не может заменить понимание сути про% исходящего. Нет ничего плохого в том, чтобы исследовать программу в отладчике, но контрольные точки нужно выбирать с умом.