конкретные методы. Может быть, тот парень, поискав по слову “судоку”, нашел бы верный ответ. А может, он считал это жульничеством. Не знаю.

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

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

Сейбел: Значит, надо рыться в старых статьях?

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

Сейбел: Вернемся к проектированию программ. Если вы работаете над большой программой и не можете вспомнить, как соединяются все фрагменты кода, то что тогда делаете?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Норвиг: Работа в Google в этом случае идет так себе. Но у нас есть резервное питание и множество дата-центров. Мы продумываем такие варианты: что будет, если сервер, с которым