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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Армстронг: Умение писать. Кто-то из компьютерных теоретиков сказал: «Если у вас плохо с английским, вы никогда не станете хорошим программистом».

Сейбел: Кажется, Дейкстра.

Армстронг: Со мной время от времени советуются университеты насчет учебных планов по компьютерным наукам. Я ведь работаю в компании — вот они и хотят знать, что нужно на практике. Я говорю: «Учите их писать и подбирать убедительные доводы». Большинство выпускников, имеющих степень по компьютерным наукам, не сильны в писании текстов.

Думаю, учить этому очень тяжело, потому что это очень индивидуально. Кто-нибудь перечеркивает твой текст красной ручкой и объясняет, в чем ты неправ. Это отнимает очень много времени. Вы знакомы с советом Хэмминга молодым исследователям?

Сейбел: Из доклада «You and Your Research» (Вы и ваше исследование)?

Армстронг: Хэмминг говорит примерно так: «Делайте правильные вещи. Если вы не делаете правильные вещи в правильных областях, то неважно, что именно вы делаете». Еще он говорит: «Один день в неделю я обязательно осваиваю что-то новое. То есть трачу на освоение нового на 20% больше, чем мои коллеги. Выходит, через 4,5 года я буду знать вдвое больше них, а с учетом сложных процентов получается, что через 5 лет я буду знать втрое больше». Не помню точно, какие там были цифры. По-моему, это верно. Поскольку я занимаюсь исследованиями, то на освоение чего-то нового трачу не 20% времени, а 40%. Я занимался ими 30 лет. И понял, что знаю очень много. Вы спрашивали, как улучшить навыки программирования? Тратьте 20% своего времени на узнавание чего-нибудь нового. Прочтите Хэмминга, он очень хорошо пишет.

Сейбел: Бывало так, что вы находили какой-то код просто красивым?

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

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

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