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

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

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

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

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

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

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

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

Сейбел: Как насчет разработки через тестирование?

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

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

Еще мне не нравится вот что - мы в Google то и дело сталкиваемся с этим: программа не укладывается в простую булевскую модель теста. В тесте есть assertEqual, assertNotEqual, assertTrue и так далее. Это хорошо, но нам нужно также иметь assertAsFastAsPossible. Нам нужны утверждения относительно огромной базы данных возможных запросов: мы получаем результаты, которые оцениваются по стоимости достижения определенной точности, стоимости повторного вызова - и хотим их оптимизировать. Но вот этих статистических или непрерывных значений, которые мы хотим оптимизировать, в тестах нет. А от булевского типа - “верно или нет” - проку мало.

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

Норвиг: Да. Но просто поглядев на методы, применяемые в тестах, вы поймете, что они не годятся для этого, что в них не предусмотрена такая возможность. Я поражаюсь тому, насколько этот подход распространен в Google. Работая в Junglee, я однажды читал об этих вещах лекцию в отделе контроля качества. Мы занимались исследованиями покупок и сказали тогда: “Нужен тест - можем ли мы по такому-то запросу получить 80% верных ответов”. Они спросили: “Хорошо, а неверный ответ - это ошибка в программе?” Я сказал: “Нет, один неверный ответ здесь не будет ошибкой”. И они удивились: “Как так, неверный ответ не считается ошибкой?” Как будто здесь был выбор только между “да” и “нет”, в то время как это скорее напоминало компромисс.

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

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

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

Отличный урок проектирования программ. Мало кто задается вопросом: “Как будет работать моя программа, если отключат электричество?”.

Сейбел: А как в этом случае идет работа в Google?