Кодеры за работой. Размышления о ремесле программиста
Шрифт:
Это была чрезвычайно сложная машина — и программировать ее было сплошным удовольствием. Компилятор представлял собой очень трудную задачу. Весь проект был восхитительно сложным.
Поэтому меня и еще нескольких сотрудников перевели из исследовательского центра IBM в этот проект для разработки компилятора и непосредственно операционной системы. Компилятор по размаху соответствовал самой машине. Из-за того что ранее мне приходилось работать с оптимизатором Фортрана, здесь я работала над оптимизатором для Stretch, который позже назовут Stretch Harvest. Общий план компилятора был утвержден другим комитетом, но мы вчетвером отвечали
Сейбел: Как проект был организован с точки зрения функций, отведенных разным работникам?
Аллен: Три человека разрабатывали общий план компилятора — у нас будет парсер, у нас будет то, у нас будет это, а это мы поставим сюда. И были люди, отвечавшие за продукт целиком, то есть было несколько уровней, на которых осуществлялось принятие решений и руководство проектом.
Затем им понадобилось назначить ответственных за каждый из крупных компонентов. Поэтому они попросили нас четверых, причем трое были женщины, заняться этим и совместно начать разработку интерфейсов.
Сейбел: Были ли помимо вас программисты, занимавшиеся непосредственно реализацией проекта?
Аллен: Да. У меня была группа из 17 программистов.
Сейбел: Как происходил переход от этапа разработки к этапу написания кода? Вы вчетвером собрались и установили интерфейсы между компонентами системы. Это произошло до того, как ваши 17 программистов начали писать код, или процесс написания кода влиял и на общую концепцию в целом?
Аллен: Все происходило, по большому счету, само собой. Ограничения были установлены вышестоящим начальством. Главы отделов, вроде меня, отчитывались перед одним человеком — Джорджем Гровером, который, собственно, и разработал всю глобальную концепцию, особенности которой, в свою очередь, были продиктованы ограничениями у потребителей. Это была командная работа, часто вносились изменения и поправки — отчасти из-за того, что мы изобретали эту систему на ходу. Но был и срок сдачи проекта. Корпоративная субординация не так много значила, работа в команде была важнее.
Сейбел: Случалось ли, что код, написанный кем-то из ваших подчиненных, заставлял пересмотреть какие-либо решения более высокого уровня о взаимодействии компонентов системы?
Аллен: Да, иногда становилось понятно, что задуманный интерфейс не будет работать. Это была часть работы — следить за тем, как все получалось на практике. Мы встречались командой — вчетвером. Но большей частью каждый из нас работал над созданием доверенного ему компонента системы — в этом смысле была огромная свобода.
Разработка ПО как таковая появилась позже. В то время еще не существовало разработки ПО, не создавалось крупных процессов. В следующем проекте (компьютер 360, руководитель Фред Брукс), в котором я не была занята, с ПО были большие проблемы. Технически с 360 все пошло на лад где-то в 1963 году. И некоторые разработчики аппаратного обеспечения перестали заниматься компьютером: ничего не зная о ПО, они занялись им, поскольку оно пребывало в полном хаосе. Это был настоящий бардак.
После того как 360 был закончен, один специалист — не знаю, работал
Сейбел: Вы имеете в виду из-за того, что проект 360 был таким тяжелым?
Аллен: Именно. Таким образом, отдел разработки продукции IBM стал придерживаться процессов Cleanrooom — целого набора процессов. Например, постановкой целей и проектированием системы занимались разные группы. И проектировщики должны были продумать все до мельчайших деталей, чтобы программисты могли писать код в соответствии с разработанной концепцией. И эти группы не были открыты друг другу — вы просто делали все аккуратно и на выходе получали идеальное ПО.
Сейбел: Во время работы над проектом по созданию 360 Брукс отвечал и за программное, и за аппаратное обеспечение?
Аллен: Да, мне кажется, что он контролировал весь проект в целом. Но некоторых из глав ПО-отделов он заменил людьми с опытом создания аппаратного обеспечения. Разумный шаг, поскольку эти специалисты уже выработали прекрасную дисциплину вокруг создания «железа» — разработка микросхем, процесс тестирования и так далее. Это был более проверенный временем и традиционный метод разработки концепции. Мы — специалисты в ПО — все придумывали сами.
Сейбел: То есть вам кажется, что как минимум в рамках этого проекта внесенные ими в процесс разработки ПО изменения оказались спасительными?
Аллен: Этот шаг был абсолютно необходим, но разработчикам ПО было нелегко, когда все эти ребята, понятия не имевшие о ПО, пришли к ним и начали просто назначать проектные экспертизы, проектные спецификации и так далее.
Сейбел: Но все-таки эти изменения спасли проект. Это придало тем ребятам уверенности, и они сделали следующий шаг к процессу Cleanrooom — шаг, который оказался не слишком удачным?
Аллен: Мне кажется, да. Так все и было. Процесс Cleanrooom — «модель водопада» — во время представления руководству получил очень сильного защитника.
Сейбел: Этот защитник был из лагеря разработчиков аппаратного обеспечения?
Аллен: Нет, он был из разработчиков ПО. Но насколько я знаю, он не участвовал в проекте 360 и вряд ли хотел таким образом его спасти. И те из нас, кто уже имел кое-какой опыт работы в сфере ПО, были ошарашены некоторыми из произнесенных тогда заявлений. Но иногда громкие фразы говорят для того, чтобы что-то продать.
Сейбел: Вы когда-нибудь работали над проектом, в рамках которого применялся подобный процесс?
Аллен: О, да. И разочаровалась в нем, потому что на его ранних этапах проектировщик и программист не могли работать совместно. Одна из его проблем состояла — да и, пожалуй, состоит — в том, что жизненный цикл программы очень долог. В те времена для создания крупной программы требовались многие месяцы и даже годы. Менялась конъюнктура, менялись требования. И много значило мнение потребителя о том, что он хочет получить в результате.