Кодеры за работой. Размышления о ремесле программиста
Шрифт:
Сейбел: Мы немного говорили об ужасных ошибках, с которыми вы сталкивались, например та история с GNB. Но давайте еще немного поговорим о процессе отладки. Для начала, какие инструменты вы предпочитаете? Инструкции печати отладочной информации? Отладчики исходного кода (symbolic debugger) [13] ? Формальные доказательства корректности?
Завински: За последние годы многое изменилось. Когда я работал на Лиспе, процесс отладки заключался в запуске программы, ее остановке и последующем изучении данных. Был специальный инструмент, который позволял копаться в памяти, и
13
Сейчас все уже пользуются отладчиками, позволяющими проходить по исходному тексту программ, но так было не всегда. В то время, о котором идет речь, не все среды разработки имели подобные отладчики.
– Прим. науч. ред.
Позже, уже работая на Си и используя GNB в Emacs, я попытался сделать то же самое. Именно исходя из этой модели мы создавали Energize. Но мне кажется, что он так никогда нормально и не заработал. Со временем я вообще прекратил пользоваться такими инструментам, а просто вставлял инструкции печати и запускал все снова. И так раз за разом, пока не исправишь ошибку. Интересно, что при переходе на все более и более примитивные среды, такие как JavaScript, Perl, это становится единственным вариантом, поскольку там нет никаких отладчиков.
В те дни люди вообще слабо представляли, что такое отладчик. “Да зачем он тебе нужен? Что он делает - добавляет за тебя инструкции печати? Не понимаю. Что за странные слова ты говоришь?” В те дни отладка в основном заключалась в инструкциях печати.
Сейбел: Имела ли тут значение разница между Лиспом и Си? Помимо инструментов одно из отличий в том, что в Лиспе можно тестировать маленькие кусочки. Можно вызвать небольшую функцию, если в правильности работы есть сомнения, остановить ее на середине и посмотреть, что происходит. А в Си запускаешь программу целиком, во всем ее величии и сложности, и задаешь точку останова в каком-нибудь месте.
Завински: Лисп и аналогичные языки позволяют в этом отношении больше, чем Си. Perl, Python и им подобные в этом смысле немного более похожи на Лисп, но все равно мало кто так делает.
Сейбел: Но ведь GNB дает возможность заглянуть внутрь. Чем он вам не подходит?
Завински: Мне он всегда казался неприятным. Отчасти из-за того, что имеет отношение к Си. Я анализирую массив и вдруг вижу кучу чисел, и нужно лезть туда и вернуть все к нормальному виду. Он никогда не работал правильно, как мог бы работать с нормальным языком.
Сейбел: В то время как в Лиспе, если вы смотрите на массив, он выводится как нужно, поскольку отладчик знает, что есть что.
Завински: Вот именно. Мне всегда казалось, что GNB прыгает вниз-вверх, и в стеке все оказывается перепутанным. Идешь вверх по стеку, а нижняя часть стека из-за проблем в GDB изменяется. Или думаешь, что в регистре должно быть одно значение, но поскольку находишься в другом кадре стека, оно оказывается совсем другим.
Такое чувство, что я не могу по-настоящему доверять сведениям
Похоже, со временем инструменты отладки становятся все хуже и хуже. С другой стороны, люди наконец-то начинают понимать, что распределение памяти вручную - тупиковый путь. Сегодня это уже неактуально, поскольку наиболее сложные ошибки, когда приходится закапываться в структуры данных, происходят редко, ведь в Си они обычно были связаны с проблемами повреждения памяти.
Сейбел: Вы используете операторы утверждений (assertions) или другой более-менее формальный способ документирования или проверки инвариантов?
Завински: Мы тогда ходили вокруг да около, не зная, как приступиться к операторам утверждений в базовом коде Netscape. Очевидно, что добавление операторов утверждений - всегда хорошая идея как для отладки, так и, как вы говорили, для документирования. Этим выражается намерение. Мы добавили множество таких операторов. Но вопрос в том, что произойдет при нарушении утверждения в финальных (не отладочных) версиях? Что тогда? Мы склонились к мысли возвращать нулевое значение в надежде, что программа будет продолжать работать. Ведь если броузер падает, это действительно плохо, гораздо хуже, чем возврат к циклу ожидания, большие утечки памяти или что-то в этом роде, поскольку все это меньше расстраивает пользователей.
Многие программисты инстинктивно говорят: “Выдавайте сообщение об ошибке!” Нет, не нужно. Никого это не волнует. С такими проблемами гораздо легче справиться в языках, поддерживающих исключения, таких как Java. В таких языках просто перехватываешь все исключения на самом верхнем уровне и готово. И не нужно беспокоить пользователя сообщением о том, что какое-то значение равно нулю.
Сейбел: Вы когда-нибудь просто проходили программу пошагово - для отладки или, как некоторые советуют, для проверки написанного кода?
Завински: Нет, не совсем. Обычно я использую пошаговое выполнение для отладки. Пожалуй, иногда для проверки правильности написанного кода. Но не часто.
Сейбел: Так что же вы делаете при отладке?
Завински: Сначала пробегаю глазами код, читаю его, пока не подумаю: “Так, этого не может быть, все должно работать правильно”. Тогда я добавляю некоторый код для проверки и разрешения этого противоречия. Либо если, читая код, я не вижу никаких проблем, то запускаю его на выполнение, останавливаю где-нибудь в середине и смотрю, что происходит. Сложно говорить об этом вообще. Ситуации бывают разные.
Сейбел: Что касается операторов утверждений - насколько формально вы к ним подходите? Кто-то использует стандартное утверждение: “Я считаю, что в этом месте кода некоторое условие должно быть истинным”. А кто-то мыслит более формально: у функций есть предусловия, постусловия и есть глобальные инварианты. Какова ваша позиция?
Завински: Я точно не думаю об этом в контексте математического доказательства корректности. Скорее я за стандартные утверждения. Конечно же, всегда полезно, получив входные данные в функции, хотя бы приблизительно понимать, какие у них ограничения. Может ли это быть пустая строка? Что-то в таком духе.