Сейбел: Как оцениваются такие схемы?

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

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

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

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

Самая формальная часть - запуск проекта. Есть таблица контрольных проверок - в плане безопасности все проверяется очень тщательно. Если мы это запустим, сможет ли кто-то получить доступ через меж-сайтовый скриптинг? Тут все довольно строго.

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

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

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

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

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

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

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

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

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

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

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

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

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

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