Почему порочно «наивное» программирование с пошаговым отладчиком

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

С профессиональной точки зрения неадекватность подхода «начнем, как попало, потом отладим» заключается в следующем:

• в низкой производительности программиста, так как поиск решения — т.е. построение программы — осуществляется в значительной степени наугад (хорошо известно выражение «агония отладки» — «the agony of debugging»);

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

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

Альтернативой наивному подходу являются систематические методы, в которых программа выводится из требуемых пред- и постусловий (см. книги Вирта, Гриса и Дейкстры в списке литературы). Такое проектирование опирается на систематическую верификацию (доказательство, проверку) логических свойств программы, которые должны удовлетворяться в ключевых точках программы (пред- и постусловия для процедур, инварианты циклов и т.п.). Тогда и «отладка» в идеале сводится к устранению синтаксических ошибок и мелких описок.
Для такого систематического программирования более чем достаточны средства, предлагаемые в Блэкбоксе (при аварийной остановке — например, если нарушено логическое условие в ASSERT — Блэкбокс дает возможность исследовать состояние локальных переменных всех процедур в цепочке вызовов, приведших к аварийной остановке, а также глобальных переменных всех модулей).
Отсутствие пошагового отладчика дисциплинирует процесс программирования подобно тому, как невозможность применить GOTO стимулирует использование методов, приводящих к программам, имеющим хорошую структуру.

Чем плохи «залатанные» программы

1. Такие программы очень трудно сопровождать. Хорошо известна эмпирическая закономерность, что время жизни программ превосходит ожидания их авторов: после успешного решения одной задачи возникает желание воспользоваться решением еще раз. Но задачи меняются, и старые программы приходится «сопровождать» — приспосабливать к меняющимся условиям. Опыт показывает, что сопровождение отнимает львиную долю усилий программистов.

Сопровождать программу, можно только четко понимая, что и как она делает. Даже если сопровождением занимается автор программы, то отнюдь не факт, что он помнит детали своих старых кодов (простой пример из жизни: перенос макросов для MS Word между версиями 6.0 и 2002, предугадать который было совершенно невозможно при их написании в 1994 г.). Разобраться с «залатанной» программой, как правило, гораздо труднее, чем с программой, построенной систематическими методами.
Поэтому, кстати, и вероятность внесения новых, причем трудноустранимых ошибок при модификации тоже велика, а дальнейшее «залатывание» — даже если оно и завершится чем-то похожим на успех — еще сильнее запутает структуру программы и заложит основу для еще бОльших проблем в будущем. Этот известный эффект можно назвать законом повышения энтропии в структуре больших программ.

2. Такие программы страдают низкой надежностью. С «залатанной» программой никогда нет уверенности, что в ней предусмотрены все ситуации, которые могут возникнуть при выполнении. Поэтому такую программу нельзя считать надежной.

Конечно, абсолютно надежной нельзя считать никакую достаточно сложную программу.
Но, во-первых, надежность программ повышается действительно радикально, если использовать соответствующие методы и инструменты (языки и т.п.). В интервью директора Центра по надежности программного обеспечения университета Карнеги-Меллон (США) отмечалось, что 95% из более чем 50 тысяч программных дефектов, исследованных центром за 9 месяцев 2002 г., относятся к категории «предотвратимых», т.е. таких, которые исключаются при использовании надлежащих средств программирования.
Во-вторых, нужно учесть и стоимость ошибок для тех, кто программой будет пользоваться: даже потерей пяти минут работы из-за сбоя редактора трудно пренебрегать, если умножить эффект на миллионы пользователей. Тем более, если речь идет о потере космической ракеты стоимостью сотни миллионов долларов.