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

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

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

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

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

Норвиг:Нет. И в качестве примера могу привести свою программу проверки правописания. Я сделал ошибку в коде, который оценивал мое правописание, и одновременно немного изменил реальный код. Запустил его - и получил для себя результаты гораздо лучше обычных. И я поверил им! Будь результат очень плохим, я бы стал разбираться. Но тут я поверил в свои хорошие результаты, которые получились из-за небольшого изменения в программе. А надо было трезво все оценить и понять, что результаты не могут так сильно отличаться, что где-то допущена ошибка.

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

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

Сейбел:Почему так соблазнительно решать задачи, которые на самом деле не актуальны?

Норвиг:Мы любим чувствовать себя умными и любим завершенность. Мы хотим как можно скорее завершить работу - закончить и двигаться дальше. Мне кажется, так устроен человек - он может чем-то позаниматься, но потом ему хочется сказать: “Все, готово, выкидываю это из головы и иду дальше”. Но надо еще подсчитать рентабельность полностью завершенной работы. Это кривая в форме S - после 80- или 90-процентной готовности рентабельность неуклонно снижается. И у вас есть сотня других проектов, где вы находитесь внизу кривой и рентабельность намного выше. В какой-то момент вы говорите: “Хватит с этим, переходим к более рентабельным вещам”.

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

Норвиг:Нужна правильная рабочая среда, ориентированная на результат. Думаю, люди способны учиться сами. Вы хотите оптимизировать что-то, но предоставленные сами себе, вы оптимизируете ваше личное удобство. А надо иметь в виду другое, одни говорят - рентабельность, другие - удовлетворенность клиента. Что лучше для клиента - если я закончу эту программу с 9 5-процентной готовностью или примусь за десять других, где готовность 0%?

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

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

Норвиг:Нет, все эти UML-инструменты мне никогда не нравились. Я всегда считал, что, если это нельзя выразить на самом языке, это недостаток языка. Многое приходится делать на более высоком уровне. В Google немалая часть работы связана с разбиением программ на модули и организацией их параллельного выполнения. Нам нужно запустить программу на большом числе машин, но у нас столько-то пользователей, столько-то данных для приложений - как все это будет работать? Поэтому мы скорее думаем в терминах машин и машинных комплексов, чем на уровне функций и взаимодействий. Если это улажено, можно переходить к частным функциям и методам.

Сейбел:Описания делаются на уровне простого языка?

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

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

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

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

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

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

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