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

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

Сейбел:Вы имеете в виду из-за того, что проект 360 был таким тяжелым?

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

Сейбел:Во время работы над проектом по созданию 360 Брукс отвечал и за программное, и за аппаратное обеспечение?

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

Сейбел:То есть вам кажется, что как минимум в рамках этого проекта внесенные ими в процесс разработки ПО изменения оказались спасительными?

Аллен:Этот шаг был абсолютно необходим, но разработчикам ПО было нелегко, когда все эти ребята, понятия не имевшие о ПО, пришли к ним и начали просто назначать проектные экспертизы, проектные спецификации и так далее.

Сейбел:Но все-таки эти изменения спасли проект. Это придало тем ребятам уверенности, и они сделали следующий шаг к процессу Cleanrooom - шаг, который оказался не слишком удачным?

Аллен:Мне кажется, да. Так все и было. Процесс Cleanrooom - “модель водопада” - во время представления руководству получил очень сильного защитника.

Сейбел:Этот защитник был из лагеря разработчиков аппаратного обеспечения?

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

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

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

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

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

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

Ф. Брукс “Мифический человеко-месяц или Как создаются программные системы”. - СПб.: Символ-Плюс, 2000.

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

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