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

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

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

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

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

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

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

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

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

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

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

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

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

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

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