Программист-прагматик

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

Кроме того, если ошибка является результатом неправильных данных, которые распространились по нескольким уровням, перед тем как вызвать взрыв, посмотрите, может быть, более усовершенствованная процедура проверки параметров в этих подпрограммах смогла бы помешать ее распространению (см. обсуждение процедур досрочного сбоя и утверждений разделе «Мертвые программы на лгут»).

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

Если устранение этой ошибки заняло много времени, спросите себя, а почему? Можете ли вы сделать что-нибудь, чтобы облегчить устранение этой ошибки в следующий раз, например, встроить усовершенствованные обработчики прерываний (для тестирования) или написать программу-анализатор файла журнала?

И наконец, если ошибка является результатом чьего-то неправильного предположения, обсудите проблему со всей командой: если имеется недопонимание со стороны одного сотрудника, то возможно, он не одинок здесь.

Проделайте все это, и наверняка в следующий раз вы будете избавлены от подобных сюрпризов.

Контрольные вопросы при отладке

• Является ли проблема прямым результатом фундаментальной ошибки или просто ее признаком?

• Ошибка действительно «сидит» в компиляторе? В операционной системе? Или в вашей собственной программе?

• Если бы вам пришлось подробно объяснить вашему коллеге, в чем состоит проблема, что бы вы ему сказали?

• Если подозрительная программа проходит модульное тестирование, то является ли оно достаточно полным? Что произойдет, если вы прогоняете модульный тест с реальными данными?

• Существуют ли условия, вызвавшие данную ошибку, где-либо еще в системе?

Другие разделы, относящиеся к данной теме:

• Программирование на основе утверждений

• Программирование в расчете на совпадение

• Вездесущая автоматизация

• Безжалостное тестирование

Вопросы для обсуждения

• Отладка сама по себе является вопросом.

19 Обработка текста

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

Языки, предназначенные для обработки текста, играют в программировании ту же роль, что станки [23] в столярном деле. Они издают шум, неуклюжи и представляют собой грубую силу. Если при работе с ними вы совершаете ошибку, то разрушенными могут оказаться целые фрагменты. Некоторые клятвенно уверяют, что этим средствам нет места в инструментарии. Но в хороших руках и станки, и языки обработки текста могут быть невероятно мощными и гибкими. Вы можете быстро придать форму материалу, делать стыки и вырезать по дереву. При надлежащем использовании эти инструменты обладают удивительной тонкостью и ловкостью. Но для овладения ими требуется время.

Число хороших языков обработки текста постоянно увеличивается. Разработчики программ для Unix часто любят использовать мощь их командных оболочек, усиленных инструментальными средствами типа awk и sed. Тем, кто предпочитает более структурированные средства, больше по душе объектно-ориентированный характер языка Python [URL 9]. Выбор некоторых падает на Tel [URL 23]. Случается, и мы предпочитаем язык Perl [URL 8] для написания коротких сценариев.