Питер Сейбел - Кодеры за работой. Размышления о ремесле программиста

Сейбел:Прочитав отчет, я был поражен позицией НАСА. Позиция примерно такая: “Проблема возникла из-за программной ошибки, но у нас было много других способов определить, что аппарат отклонился от заданного курса, и мы должны были это сделать. Мы в любом случае должны были выправить ситуацию, даже если наши данные оказались неверными из-за глупейшего программного глюка”. Восхитительно.

Норвиг:Да, они заняли позицию стороннего наблюдателя.

Сейбел:Часто ли встречаются крупные ошибки, о которых мы ничего не знаем, потому что другие процессы позволяют системе работать?

Норвиг:Думаю, да. В вашем компьютере миллионы ошибок, но он тем не менее работает.

Сейбел:Говорят, программы для шаттлов стоят чуть ли не 1500 долларов за строку, поскольку пишутся очень тщательно и предположительно не содержат ошибок. Это просто слухи?

Норвиг:Нет, это похоже на правду. Но, по-моему, это не оптимальное решение. Программы с ошибками служили бы им лучше.

Сейбел:Более дешевые и производительные?

Норвиг:Да. Астронавтам приходится запоминать массу всего. А надо учить их обращаться лишь с тем, чего не может сделать программа. Астронавтов же помещают в симуляторы, прокручивают перед ними разные ситуации, и когда что-то не так, перед тобой мелькают картинки на экране. Ты не можешь остановиться, прокрутить назад, выявить самое важное. А учить надо так: “Если вы видите вот это, значит, происходит вон то”. К ним приходят сотни сообщений подряд об отказе какой-нибудь электрической штуки, и они должны ответить наизусть: “Похоже, изначально отказало вот это, а остальные сообщения идут из-за каскадного отключения”. Почему не передоверить все это программе? Но в НАСА не пытаются - не хотят связываться с этим.

Сейбел:Сменим тему. Какие методы и инструменты отладки вы предпочитаете? Операторы печати? Формальные доказательства? Символические отладчики?

Норвиг:Все вместе, по ситуации. Иногда я использую IDE, которая хорошо умеет трассировать, а иногда Emacs, в котором всего этого нет. Конечно, я трассирую и распечатываю. И думаю. Пишу небольшие тесты, слежу за их выполнением, разбиваю функциональность на части, чтобы понять, где тест не прошел. Честно признаюсь: я часто переписываю код, порой даже когда не нахожу ошибок. Я просто чувствую, что вот в этой части она есть. Что-то меня в этой части беспокоит. Она слишком запутанная. Так не должно быть. Вместо того чтобы внести несколько мелких изменений, я переписываю несколько сотен строк за один раз, и ошибка уходит.

Иногда после этого я чувствую себя виноватым. Ведь я не понял, что это за ошибка, не нашел ее. Я просто разбомбил дом и выстроил новый. В каком-то смысле ошибка ускользнула от меня. Но если решение эффективно - что ж. Это быстрее, чем отыскивать ошибку.

Сейбел:Как насчет утверждений или инвариантов? Насколько формально вы подходите к ним при написании кода?

Норвиг:Скорее неформально. Я не пользуюсь языками со сложными формальными механизмами сверх описания типов, вроде инвариантов цикла. Мне всегда казалось, что хлопот от них больше, чем выгод. Иногда бывает, что цикл не завершается, но это редко, а формальная часть сильно все тормозит. Если же возникла проблема, отладчик сообщит, в каком вы сейчас цикле. Если вы пишете код, от которого зависит много другого кода, и он во что-то встроен, то, конечно, следует доказывать все. Но если встает выбор - выпускать первую версию программы или отлаживать ее, я стою за скорость. Формальная спецификация может подождать.

Сейбел:Вы делали что-нибудь специально, чтобы научиться на собственных ошибках?

Норвиг:Да, это очень интересно, и я хотел бы делать больше в этом смысле. Сейчас я веду переговоры об эксперименте, в масштабах компании или даже всего мира, который облегчил бы понимание таких вопросов. Как классифицировать ошибки и какие факторы надо учитывать в плане продуктивности? Возможно, тип личности программиста? Какие именно программисты более продуктивны? Интересно, какие поддающиеся учету факторы помогают одним программистам работать лучше других? Если это зависит от размера монитора, может, надо дать всем мониторы покрупнее?

Сейбел:Если выяснится, что чем меньше монитор, тем выше эффективность, вас возненавидят.

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