Чтение онлайн

5. Каждый раз изменяйте лишь что-то одно. Если вы стараетесь усовершенствовать модуль обработки потоков и одновременно переходите на следующую версию операционной системы, не имеет значения, видите ли вы улучшение, ухудшение или отсутствие изменений — у вас не будет мыслей по поводу того, каким был результат ваших отдельных изменений. Взаимодействие нескольких изменений может быть непредсказуемым и сбивающим с толку. Не делайте этого. Изменяйте за один раз только что-то одно, чтобы вы могли поручиться, что любое отличие, которые вы видите, возникло из-за этого изменения.

Если вы делаете изменение, а результата не видно, немедленно вернитесь обратно. Возможно, оно имело результат, который вы не увидели, и он может проявиться в сочетании с другими изменениями. Это относится к изменениям как в тестировании, так и в кодировании.

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

7. Проверьте подключение. У каждого есть история о какой-нибудь проблеме, оказавшейся в том, что «это не было подключено». Иногда что-то оказывается буквально не подключенным, но для программного обеспечения «не подключено» может означать отсутствующий драйвер или старую версию кода, о которой вы думали, что заменили ее. Или плохое оборудование, когда вы клянетесь, что это проблема программного обеспечения. В одной истории инженеры-программисты и электронщики показывали пальцами друг на друга, и никто не был прав: тестирующее устройство, которое они использовали, не соответствовало спецификации. Основной момент в том, что иногда вы ищете проблему внутри системы, тогда как на самом деле она вне системы, или лежит в основе системы, или в инициализации системы, или вы смотрите не на ту систему.

Не следует также непременно доверять своим инструментам. Производители инструментов также являются инженерами; у них есть ошибки, и вы можете оказаться тем, кто их обнаружит.

8. Оцените свежим взглядом. Есть три причины попросить помощи при отладке.

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

Когда вы описываете ситуацию кому-либо, сообщите о симптомах, которые вы видели, а не о своих предположениях, почему это происходит так. Вы пришли к ним, потому что ваши предположения не ведут вас никуда — не тяните их в ту же колею, в которую попали сами.

9. Если вы не исправили это, это не исправлено. Так вы думаете, это исправлено? Испытайте. Раз вы могли заставить ошибку повторяться постоянно, создайте ту же самую ситуацию и убедитесь, что ошибки нет. Не думайте, что все исправлено лишь потому, что проблема была очевидной. Может, она не была такой очевидной. Может, ваше исправление не было сделано правильно. Может, ваше исправление даже не находится в новом выпуске! Проверьте! Заставьте ошибку исчезнуть.

Вы уверены, что именно ваш код исправил проблему? Или это произошло из-за изменения теста, или туда был внесен какой-то другой код? Когда вы видите, что ваше исправление работает, уберите его и заставьте ошибку появиться снова. Затем верните исправление на место и убедитесь, что ошибки нет. Этот шаг гарантирует, что именно ваше исправление решило проблему.

Дополнительные сведения о книге Debugging и плакат с правилами отладки можно найти для свободной загрузки по адресу

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

1. Debugging, David J. Agans. AMACOM, New York, New York. USA 2003. ISBN: 0-8144-7168-4.

Настоятельно рекомендуем эту книгу. У нее легкий стиль, удивительное звучание, чтение — одно удовольствие!

2. Programming Pearls, 2nd edition, by Jon Louis Bentley. Addison-Wesley, Reading, Massachusetts, USA, 2000, ISBN: 0-201-63788-0. См. также веб-сайт этой книги. [189]

В главе 5 этой книги приведено хорошее обсуждение тестирования элементов и построения тестовой среды.

3. Literate Programming, by Donald E. Knuth. Center for the Study of Language and Information (CSLI), Stanford University, USA, 1992. ISBN: 0-9370-7380-6.

Эта восхитительная книга содержит ряд статей Дональда Кнута по грамотному программированию (literate programming) — методике программирования, которую он изобрел и использовал для создания ТеХ и Metafont. Особый интерес представляет статья, озаглавленная «Ошибки ТеХ», которая описывает, как он разрабатывал и отлаживал ТеХ, включая его журнал всех найденных и исправленных ошибок.

4. Writing Solid Code, by Steve Maguire. Microsoft Press, Redmond, Washington, USA, 1993. ISBN 1-55615-551-4.

5. Code Complete: A Practical Handbook of Software Construction, by Steve McConnell Microsoft Press, Redmond, Washington, USA, 1994. ISBN: 1-55615-484-4.

6. The Practice of Programming, by Brian W. Kernighan and Rob Pike. Addison-Wesley, Reading. Massachusetts, USA, 1999. ISBN: 0-201-61585-X.

• Отладка является важной частью разработки программного обеспечения. Для минимизации ошибок должны использоваться хорошие проектирование и практика разработки, но отладка всегда будет с нами.

• Программы должны компилироваться без оптимизации и с включенными идентификаторами отладки, чтобы упростить отладку под отладчиком. На многих системах компиляция с оптимизацией и компиляция с идентификаторами отладки несовместимы. Это не относится к GCC, вот почему разработчикам GNU/Linux нужно знать об этой проблеме.