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

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

Сейбел: Вы когда-нибудь работали над проектом, в рамках которого применялся подобный процесс?

Аллен: О, да. И разочаровалась в нем, потому что на его ранних этапах проектировщик и программист не могли работать совместно. Одна из его проблем состояла — да и, пожалуй, состоит — в том, что жизненный цикл программы очень долог. В те времена для создания крупной программы требовались многие месяцы и даже годы. Менялась конъюнктура, менялись требования. И много значило мнение потребителя о том, что он хочет получить в результате.

Сейбел: И вы продвигали изменения по всей вертикали процесса? Или люди шли прямо к программистам: «В общем, мы поняли, заказчику нужен X»?

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

Сейбел: Ну, собственно, Брукс в своей знаменитой книге1 и написал: «Планируйте выбросить первую версию — вам все равно придется это сделать».

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

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

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

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

Сейбел: Итак, вы тогда возглавили крупный проект по созданию компилятора PTRAN; вы впервые стали работать с явным параллелизмом, а не со скрытым параллелизмом в конвейерах центрального процессора и так далее. Тогда это было в новинку — как для вас, так и для IBM.

Аллен: Это было новым веянием для IBM, но мы уже очень запаздывали. Огромная работа, открывшая реальную практическую выгоду в этом плане, началась в Иллинойсе в 1969 или в 1970 году.

Сейбел: Для какого языка предназначался компилятор PTRAN? Был ли это простой Фортран, без дополнительных конструкций для параллелизма?

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

Что касается PTRAN, то мы собирались использовать «пыльные колоды» (dusty decks), как мы их называли, то есть уже существующую базу кода, после чего автоматически задействовать предоставляемые железом параллельные компоненты.

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

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

Собственно, мы строили это на основе уже существовавших работ, в частности Дэйва Кука. Некоторые работы были из Нью-Йоркского университета. Мы наняли группу свежеиспеченных PhD из ряда мест, в которых уже к тому моменту был наработан определенный опыт. У нас было довольно много значительных результатов — и в практической, и в теоретической части; мы работали одновременно и над тем, и над другим. Я убеждена в том, что практика должна быть выражаемой в узнаваемых алгоритмах, в теории и способах представления решения задач, а алгоритмы должны применяться на практике, для того чтобы понять, насколько они ценны и как их применять. Я считаю, что в нашей области при работе над проектом лучше всего сочетать теорию и практику.

Сейбел: Во время работы над проектом PTRAN вы руководили командой. Вы тогда все еще писали код?

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

Если мы не можем реализовать его по-настоящему, то этот вызов останется. И проделанная работа будет не столь полезна, как мне хотелось. В конце концов один из моих подчиненных все запрограммировал. Я прочла программу целиком, изучила каждый фрагмент кода, проанализировала все использованные структуры данных. Это было потрясающе. Я сказала: «То что надо. Это работает».

Сейбел: То есть вы просмотрели все фрагменты кода, которые должны были войти в систему?

Аллен: Да, да, да.

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

Аллен: Нет, я была научным руководителем группы. Было 10-12 основных сотрудников, и мы разделили всю работу таким образом, что каждый владел каким-то ее куском.

Сейбел: Как минимум начиная с выхода книги Джеральда Вайнберга «The Psychology of Computer Programming» (Психология программирования) не утихают споры, что лучше — когда кто-то один «владеет» кодом и соответственно отвечает за него или совместная работа, позволяющая избежать вещей, понятных только одному. Судя по всему вы решили, что оптимальным вариантом было разделить владение кодом?

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

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

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