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

Сейбел:Вы рассказывали, как проверяли Гвидо ван Россума на знание Python, а Кена Томпсона - на знание Си, выясняя, способны ли они придерживаться довольно жестких стандартов кодирования. Для проектирования у вас такие же жесткие стандарты?

Норвиг:Нет. Некоторые стандарты кодирования касаются вопросов проектирования, но все гораздо свободнее. Разумеется, есть определенная политика - нужно получить разрешение на участие в написании кода. И каждое изменение кода кем-то контролируется и проверяется.

Сейбел:Значит, любое изменение кода в хранилище р4 контролируется?

Норвиг:Можно писать экспериментальные фрагменты для себя. Есть исключения, когда ревизия выполняется позднее. Но лучше так делать пореже.

Сейбел:То есть это эквивалент классической проверки — кто-то смотрит ваш код и подтверждает, что в нем все в порядке.

Норвиг:Да. На самом деле это был первый проект Гвидо. Мы использовали для этого утилиту diff, но это слишком громоздкий способ. А Гвидо создал распределенную систему с красивым интерфейсом и подсветкой, так что ревизии кода облегчились.

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

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

Сейбел:Понятно. А проверяющим нужны какие-то навыки?

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

Сейбел:Чем отличаются хорошие проверяющие?

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

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

Норвиг:У всех разные умения. Один из лучших наших специалистов по поиску не очень хорошо программирует - код выходит средний. Но, допустим, его спрашиваешь: “Вводится новый фактор - сколько раз человек щелкает на этой странице, сделав то и то. Как учесть его в наших результатах поиска?” И он отвечает: “В строке 427 есть альфа-переменная, возьмите новый фактор, возведите в квадрат, умножьте на 1,5 и прибавьте к переменной”. Через несколько месяцев экспериментов с разными подходами выясняется, что он был прав, только умножать надо, скажем, на 1,3.

Сейбел:Значит, он четко представляет работу программы.

Норвиг:Он прекрасно понимает код. Другие пишут лучше, но он сразу прикидывает все последствия изменений в коде.

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

Норвиг:Да, не исключено.

Сейбел:Итак, проверки у вас не такие формальные, как в НАСА. Что еще скажете о разнице между культурой “инженеров” и “хакеров”, в лучшем смысле обоих слов?

Норвиг:Разница есть в организационной структуре и в отношении к ПО. Google начинался как компания, производящая ПО, и в те времена были наняты исполнительный директор - PhD компьютерных наук из Беркли, вице-президент по продажам - бывший компьютерный инженер, и так строилась вся фирма. А в НАСА все они специалисты по ракетам! Они мало соображают в программах, считая их необходимым злом. “Линейный код я еще понимаю, но вот циклы - это уже подозрительно. А если там еще и условие внутри цикла - о, это уже слишком далеко от того, что я могу решить через дифференциальное уравнение из теории управления!” Там все настроены очень недоверчиво.

Сейбел:Но так и нужно.

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

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

Сейбел:Какова худшая ошибка из всех найденных вами?

Норвиг:С самыми большими ошибками (не моими) я имел дело, когда участвовал в чистке после программных сбоев на Марсе в 1998 году. Первый - из-за того, что вместо ньютонов были указаны футофунты. И второй - преждевременное отключение двигателей из-за сбоя программы, - мы так думали, но без полной уверенности.

Сейбел:Помню один из отчетов по Mars Climate Orbiter - как раз ту историю с футофунтами и ньютонами. Вы там были единственным специалистом по компьютерам. Вы тоже участвовали в разговоре с производителями ПО, выясняя проблему?

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