Питер Сейбел - Кодеры за работой. Размышления о ремесле программиста
Сейбел: Вы имеете в виду из-за того, что проект 360 был таким тяжелым?
Аллен: Именно. Таким образом, отдел разработки продукции IBM стал придерживаться процессов Cleanrooom - целого набора процессов. Например, постановкой целей и проектированием системы занимались разные группы. И проектировщики должны были продумать все до мельчайших деталей, чтобы программисты могли писать код в соответствии с разработанной концепцией. И эти группы не были открыты друг другу - вы просто делали все аккуратно и на выходе получали идеальное ПО.
Сейбел: Во время работы над проектом по созданию 360 Брукс отвечал и за программное, и за аппаратное обеспечение?
Аллен: Да, мне кажется, что он контролировал весь проект в целом. Но некоторых из глав ПО-отделов он заменил людьми с опытом создания аппаратного обеспечения. Разумный шаг, поскольку эти специалисты уже выработали прекрасную дисциплину вокруг создания “железа” - разработка микросхем, процесс тестирования и так далее. Это был более проверенный временем и традиционный метод разработки концепции. Мы - специалисты в ПО - все придумывали сами.
Сейбел: То есть вам кажется, что как минимум в рамках этого проекта внесенные ими в процесс разработки ПО изменения оказались спасительными?
Аллен: Этот шаг был абсолютно необходим, но разработчикам ПО было нелегко, когда все эти ребята, понятия не имевшие о ПО, пришли к ним и начали просто назначать проектные экспертизы, проектные спецификации и так далее.
Сейбел: Но все-таки эти изменения спасли проект. Это придало тем ребятам уверенности, и они сделали следующий шаг к процессу Cleanrooom - шаг, который оказался не слишком удачным?
Аллен: Мне кажется, да. Так все и было. Процесс Cleanrooom - “модель водопада” - во время представления руководству получил очень сильного защитника.
Сейбел: Этот защитник был из лагеря разработчиков аппаратного обеспечения?
Аллен: Нет, он был из разработчиков ПО. Но насколько я знаю, он не участвовал в проекте 360 и вряд ли хотел таким образом его спасти. И те из нас, кто уже имел кое-какой опыт работы в сфере ПО, были ошарашены некоторыми из произнесенных тогда заявлений. Но иногда громкие фразы говорят для того, чтобы что-то продать.
Сейбел: Вы когда-нибудь работали над проектом, в рамках которого применялся подобный процесс?
Аллен: О, да. И разочаровалась в нем, потому что на его ранних этапах проектировщик и программист не могли работать совместно. Одна из его проблем состояла - да и, пожалуй, состоит - в том, что жизненный цикл программы очень долог. В те времена для создания крупной программы требовались многие месяцы и даже годы. Менялась конъюнктура, менялись требования. И много значило мнение потребителя о том, что он хочет получить в результате.
Сейбел: И вы продвигали изменения по всей вертикали процесса? Или люди шли прямо к программистам: “В общем, мы поняли, заказчику нужен X”?
Аллен: Да. Никто не мог написать спецификации, которые соответствовали бы всем нормам и были бы полезны в отношении всех мелких деталей на протяжении всего жизненного цикла программы. В этом и заключалась проблема. Разумеется, сейчас мы работаем по другой схеме - просто сделай и выброси, что-то вроде того.
Сейбел: Ну, собственно, Брукс в своей знаменитой книге1 и написал: “Планируйте выбросить первую версию - вам все равно придется это сделать”.
Ф. Брукс “Мифический человеко-месяц или Как создаются программные системы”. - СПб.: Символ-Плюс, 2000.
Аллен: Да. На самом деле, это правда - я в этом убеждена. Но зачастую это приводит, на мой взгляд, к тому, что мы не думаем перед тем, как начать делать программу.
Мне всегда нравилось иметь перед собой общую картину - модель. Чаще всего я рисую блок-схему и пишу спецификацию об интерфейсах между частями. В то время мы, конечно, постоянно рисовали блок-схемы, потому что, во-первых, не всегда компьютер был под рукой, а во-вторых, потому что блок-схема - это прекрасный способ отражения взаимоотношений частей системы, планирования того, что и где будет выполняться, и отражения функциональности различных компонентов. Не знаю, что могло бы ее в этом отношении заменить.
Сейбел: Есть несколько разновидностей блок-схем: формальные блок-схемы - они являются частью документации, и схемы, которые чертишь на доске, пытаясь в чем-либо разобраться. Какого типа блок-схемы рисовали вы?
Аллен: В каких-то случаях - формальные блок-схемы. Часто в ядре программы находились очень сложные фрагменты, и было необходимо составить подобную блок-схему. В остальном же речь о схемах второго типа - это был способ выработки решения задачи. Доска изрисовывалась целиком - и становилась своего рода архивом месяца или любого другого периода времени.
Сейбел: Итак, вы тогда возглавили крупный проект по созданию компилятора PTRAN; вы впервые стали работать с явным параллелизмом, а не со скрытым параллелизмом в конвейерах центрального процессора и так далее. Тогда это было в новинку - как для вас, так и для IBM.
Аллен: Это было новым веянием для IBM, но мы уже очень запаздывали. Огромная работа, открывшая реальную практическую выгоду в этом плане, началась в Иллинойсе в 1969 или в 1970 году.
Сейбел: Для какого языка предназначался компилятор PTRAN? Был ли это простой Фортран, без дополнительных конструкций для параллелизма?
Аллен: Именно так, с этого мы начинали. Я хотела сделать то же самое, что мы сделали для оптимизации: пользователь пишет последовательный код на языке так, как это свойственно данному приложению, после чего компилятор оптимизирует и преобразует его для машины, применяя параллелизм.
Что касается PTRAN, то мы собирались использовать “пыльные колоды” (dusty decks), как мы их называли, то есть уже существующую базу кода, после чего автоматически задействовать предоставляемые железом параллельные компоненты.
Сейбел: То есть, по сути, речь шла о том, что сегодня мы называем симметричными мультипроцессорами?
Аллен: Да, возможно. Моделей параллелизма очень много - и в этом одна из трудностей. Думаю, здесь все могло быть гораздо проще. Но многоядерность - одна из наиболее интересных вещей, по крайней мере для меня. А моделей параллелизма много.
Собственно, мы строили это на основе уже существовавших работ, в частности Дэйва Кука. Некоторые работы были из Нью-Йоркского университета. Мы наняли группу свежеиспеченных PhD из ряда мест, в которых уже к тому моменту был наработан определенный опыт. У нас было довольно много значительных результатов - и в практической, и в теоретической части; мы работали одновременно и над тем, и над другим. Я убеждена в том, что практика должна быть выражаемой в узнаваемых алгоритмах, в теории и способах представления решения задач, а алгоритмы должны применяться на практике, для того чтобы понять, насколько они ценны и как их применять. Я считаю, что в нашей области при работе над проектом лучше всего сочетать теорию и практику.
