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