Кодеры за работой. Размышления о ремесле программиста
Шрифт:
Сейбел: Какова худшая ошибка из всех найденных вами?
Норвиг: С самыми большими ошибками (не моими) я имел дело, когда участвовал в чистке после программных сбоев на Марсе в 1998 году. Первый — из-за того, что вместо ньютонов были указаны футофунты. И второй — преждевременное отключение двигателей из-за сбоя программы, — мы так думали, но без полной уверенности.
Сейбел: Помню один из отчетов по Mars Climate Orbiter — как раз ту историю с футофунтами и ньютонами. Вы там были единственным специалистом по компьютерам. Вы тоже участвовали в разговоре
Норвиг: Ну, после событий, когда нашли причину, все было просто. Они разобрались довольно быстро. А потом было расследование — как такое могло случиться? Думаю, было несколько причин. Первая — аутсорсинг: одни программы разрабатывала JPL в Пасадене, другие — Lockheed-Martin в Колорадо. Два специалиста из двух разных команд попросту не обедали вместе, иначе, убежден, этой проблемы бы не было. А так, один написал другому по электронной почте: «С этими измерениями что-то не так, кажется, мы слегка просчитались. Но не очень сильно, все должно быть в порядке».
Сейбел: Это происходило уже во время полета?
Норвиг: Да. И даже во время полета была возможность выловить ошибку. Они знали, что не все в порядке, поэтому и послали письмо, но не отметили это в системе отслеживания ошибок. Если бы они это сделали, в НАСА очень хорошо налажено отслеживание ошибок, и все можно было бы исправить даже на поздней стадии. А вместо этого — неформальное письмо, которое так и осталось без ответа. В JPL считали, что в Lockheed-Martin решили проблему, а в Lockheed считали, что раз JPL больше не спрашивает, значит, волноваться не о чем.
Так что перед нами проблема коммуникации. Но это еще и проблема повторного использования кода. В НАСА превосходная система проверок критически важных программ. При запуске предыдущего аппарата кое-что тоже записывалось в футофунтах, но это был просто лог, он не использовался для навигации. И проблему не отнесли к критически важным. А в марсианском проекте изменилась навигационная система, и лог-файл стал входными данными для навигации.
Сейбел: Выходит, в одном месте генерировались данные в футофунтах, а затем передавались в другую программу, которая обсчитывала ввод, ожидая, что данные будут в ньютонах?
Норвиг: Именно так. Другой ключевой проблемой было слишком большое число солнечных частиц. Космический аппарат асимметричен из-за солнечных батарей, он слегка вращается из-за этих частиц, так что необходимо для противовеса запускать ракетные двигатели. Сотрудник Lockheed, недавно принятый на работу, разговаривал с производителем ракетных двигателей, у которого все спецификации были в футофунтах. Так они и оказались записаны — сотрудник не знал, что НАСА требует данных в метрической системе.
Сейбел: Прочитав отчет, я был поражен позицией НАСА. Позиция примерно такая: «Проблема возникла из-за программной ошибки, но у нас было много других способов определить, что аппарат отклонился от заданного курса, и мы должны были это сделать. Мы в любом случае должны были выправить ситуацию, даже если наши данные оказались неверными из-за глупейшего программного глюка». Восхитительно.
Норвиг: Да, они заняли позицию стороннего наблюдателя.
Сейбел:
Норвиг: Думаю, да. В вашем компьютере миллионы ошибок, но он тем не менее работает.
Сейбел: Говорят, программы для шаттлов стоят чуть ли не 1500 долларов за строку, поскольку пишутся очень тщательно и предположительно не содержат ошибок. Это просто слухи?
Норвиг: Нет, это похоже на правду. Но, по-моему, это не оптимальное решение. Программы с ошибками служили бы им лучше.
Сейбел: Более дешевые и производительные?
Норвиг: Да. Астронавтам приходится запоминать массу всего. А надо учить их обращаться лишь с тем, чего не может сделать программа. Астронавтов же помещают в симуляторы, прокручивают перед ними разные ситуации, и когда что-то не так, перед тобой мелькают картинки на экране. Ты не можешь остановиться, прокрутить назад, выявить самое важное. А учить надо так: «Если вы видите вот это, значит, происходит вон то». К ним приходят сотни сообщений подряд об отказе какой-нибудь электрической штуки, и они должны ответить наизусть: «Похоже, изначально отказало вот это, а остальные сообщения идут из-за каскадного отключения». Почему не передоверить все это программе? Но в НАСА не пытаются — не хотят связываться с этим.
Сейбел: Сменим тему. Какие методы и инструменты отладки вы предпочитаете? Операторы печати? Формальные доказательства? Символические отладчики?
Норвиг: Все вместе, по ситуации. Иногда я использую IDE, которая хорошо умеет трассировать, а иногда Emacs, в котором всего этого нет. Конечно, я трассирую и распечатываю. И думаю. Пишу небольшие тесты, слежу за их выполнением, разбиваю функциональность на части, чтобы понять, где тест не прошел. Честно признаюсь: я часто переписываю код, порой даже когда не нахожу ошибок. Я просто чувствую, что вот в этой части она есть. Что-то меня в этой части беспокоит. Она слишком запутанная. Так не должно быть. Вместо того чтобы внести несколько мелких изменений, я переписываю несколько сотен строк за один раз, и ошибка уходит.
Иногда после этого я чувствую себя виноватым. Ведь я не понял, что это за ошибка, не нашел ее. Я просто разбомбил дом и выстроил новый. В каком-то смысле ошибка ускользнула от меня. Но если решение эффективно — что ж. Это быстрее, чем отыскивать ошибку.
Сейбел: Как насчет утверждений или инвариантов? Насколько формально вы подходите к ним при написании кода?
Норвиг: Скорее неформально. Я не пользуюсь языками со сложными формальными механизмами сверх описания типов, вроде инвариантов цикла. Мне всегда казалось, что хлопот от них больше, чем выгод. Иногда бывает, что цикл не завершается, но это редко, а формальная часть сильно все тормозит. Если же возникла проблема, отладчик сообщит, в каком вы сейчас цикле. Если вы пишете код, от которого зависит много другого кода, и он во что-то встроен, то, конечно, следует доказывать все. Но если встает выбор — выпускать первую версию программы или отлаживать ее, я стою за скорость. Формальная спецификация может подождать.