Читаем Кодеры за работой полностью

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

Аллен: Да. У меня была группа из 17 программистов.

Сейбел: Как происходил переход от этапа разработки к этапу написания кода? Вы вчетвером собрались и установили интерфейсы между компонентами системы. Это произошло до того, как ваши 17 программистов начали писать код, или процесс написания кода влиял и на общую концепцию в целом?

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

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

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

Разработка ПО как таковая появилась позже. В то время еще не существовало разработки ПО, не создавалось крупных процессов. В следующем проекте (компьютер 360, руководитель Фред Брукс), в котором я не была занята, с ПО были большие проблемы. Технически с 360 все пошло на лад где-то в 1963 году. И некоторые разработчики аппаратного обеспечения перестали заниматься компьютером: ничего не зная о ПО, они занялись им, поскольку оно пребывало в полном хаосе. Это был настоящий бардак.

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

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

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

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

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

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

Аллен:

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

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

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

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

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

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

Перейти на страницу:

Все книги серии Профессионально

Кодеры за работой
Кодеры за работой

Программисты — люди не очень публичные, многие работают поодиночке или в небольших группах. Причем самая важная и интересная часть их работы никому не видна, потому что происходит у них в голове. Питер Сейбел, писатель-программист, снимает покров таинственности с этой профессии. Он взял интервью у 15 величайших профессионалов: Кена Томпсона, создателя UNIX, Верни Козелла, участника первой реализации сети ARPANET, Дональда Кнута, Гая Стила, Саймона Пейтон-Джонса, Питера Норвига, Джошуа Блоха, Брэда Фицпатрика, создателя Живого Журнала, и других. Все они «подсели» на программирование еще в школе. Тогда, на заре зарождения отрасли, лишь в немногих учебных заведениях читались курсы по компьютерным наукам. Поэтому будущим гуру приходилось покорять профессиональные вершины самостоятельно, но всех их отличает творческое горение и полная самоотдача любимому делу.Вы узнаете, что они думают о будущем программирования и как сами научились программировать, как, по их мнению, нужно проектировать ПО, как выбор языка программирования влияет на продуктивность и можно ли облегчить выявление труднонаходимых ошибок.

Питер Сейбел

Биографии и Мемуары / Программирование / Прочая компьютерная литература / Документальное / Книги по IT
Человеческий фактор
Человеческий фактор

Немногие книги о компьютерах оказали такое заметное влияние на управление разработкой программного обеспечения, как «Человеческий фактор». Уникальное озарение этой книги, долгие годы сохранявшей свое положение в списке бестселлеров: самые сложные проблемы разработки ПО носят не технологический, а социальный характер. Эти человеческие проблемы решать не просто, однако, решив их, вы увеличите шансы на успех до верхнего предела.В третьем издании появилось шесть новых глав и внесены многочисленные правки в основной текст, так что теперь книга лучше соответствует современным средам разработки и современным проблемам. В частности, обсуждаются патологии лидерства, которые раньше за патологии не считались, эволюционирующая культура собраний, а еще растущее понимание того, что некоторые наши инструменты служат скорее якорями, а не двигателями. Каждый, кому необходимо управлять проектом по разработке ПО или целой организацией такого рода, найдет на страницах этой книги множество ценных советов.

Тимоти Листер , Том ДеМарко

Деловая литература
97 этюдов для программистов. Опыт ведущих экспертов
97 этюдов для программистов. Опыт ведущих экспертов

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

Пит Гудлиф

Программирование, программы, базы данных

Похожие книги