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

Я решил написать специализированный алгоритм, убирающий все, что не нужно в данной конкретной программе. Чем более специализированными они были, тем короче становились. А когда Роберт брал мою программу, она удлинялась, делаясь более универсальной. Думаю, это философия UNIX: программа должна делать то, что от нее требуется, и ничего больше. У Роберта была другая философия: программа должна быть частным случаем некоей более общей программы. Поэтому мы попеременно добавляли то общего, то специального.

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

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

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

Армстронг:ОТР проектировали я, Мартин Бьёрклунд и Магнус Фрё-берг. Над первоначальным проектом работали только мы трое. Мы собирались каждое утро за чашкой кофе, долго беседовали - час, два часа - и за это время исписывали всю доску. Я сразу же писал всю документацию, а они - весь код. Правда, иногда я тоже выдавал фрагмент-другой кода. И когда я писал документацию и понимал, что не могу что-то описать, мы это меняли. Или они приходили ко мне со словами: “Программа не будет работать, мы поняли сегодня утром, потому что вот это не так, и это, и это”. К концу дня у нас была вся нужная документация и весь нужный код - или достаточно того и другого, чтобы работать. И на этом мы успокаивались.

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

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

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

Сейбел:В этом случае вы писали документацию еще до кода или, по крайней мере, одновременно с ним. Вы так делаете всегда?

Армстронг:Зависит от сложности задачи. Если она очень сложная, я часто начинаю с документации. Чем сложнее, тем больше я склонен начинать с документации.

Мне нравится делать документацию. По-моему, до появления документации в нормальном виде программу нельзя считать готовой. Писать спецификации мне тоже нравится. Некоторые говорят: “Хотите знать, что делает программа? Читайте код”. Думаю, это непрофессиональный подход. Код показывает мне, что программа делает, а не то, что она должна по идее делать. Код - это решение задачи. Если нет спецификации или какой-либо документации, приходится догадываться о задаче по решению. Догадка может быть неверной. Я хочу иметь объяснение - в чем состоит задача.

Сейбел:На этой стадии вы пишете внутреннюю документацию для других программистов или документацию для пользователя?

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

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

Если бы я программировал на Haskell, то с самого начала задумался бы о типах, написал для них документацию. Работая с Лиспом или Erlang, можно начать с кода, не особенно заботясь о типах. В каком-то смысле написание документации - тоже забота о типах. Начинается со связки “есть”. “Мелодия есть последовательность нот”. Хорошо. Мелодия есть последовательность аккордов, каждый из которых является сочетанием нот равной длины. Простыми определениями терминов в документации - такое-то есть то-то - вы делаете своего рода анализ типов и декларативно размышляете о структурах данных.

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

Армстронг:Да. Новые языки вполне хороши. Haskell и ему подобные, Erlang. Есть интересные языки, которые надо использовать активнее.

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

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

Армстронг:Пролог сильно отличается от других языков. Там реализован любопытный способ мышления, и он подходит не для всех задач, хотя и для очень многих. Он мало распространен, к нашему стыду, - ведь программы на нем выходят очень короткими. Когда я написал первую свою программу на Прологе, то испытал нечто вроде шока. Поразительное было ощущение. Смотри - где программа, которую ты написал? Ты всего лишь рассказал немного фактов о системе, о своей задаче, а он сообразил, что делать. Просто чудесно! Надо бы бросить Erlang и вернуться к Прологу.