Мифический человеко-месяц или как создаются программные системы, Фредерик Брукс
Read

Мифический человеко-месяц или как создаются программные системы

Эта книга — юбилейное (дополненное и исправленное) издание своего рода библии для разработчиков программного обеспечения во всем мире, написанное Бруксом еще в 1975 году. Тогда же книга была издана на русском языке и давно уже стала библиографической редкостью. В США полагают, что без прочтения книги Брукса не может состояться ни один крупный руководитель программного проекта.
more
Impression
Add to shelf
Already read
317 printed pages
Научпоп

Related booksAll

One fee. Stacks of books

You don’t just buy a book, you buy an entire library… for the same price!

Always have something to read

Friends, editors, and experts can help you find new and interesting books.

Read whenever, wherever

Your phone is always with you, so your books are too – even when you’re offline.

Bookmate – an app that makes you want to read

ImpressionsAll

Aleksandr Shakun
Aleksandr Shakunshared an impression5 months ago
👍
🎯Worthwhile

Dmitry Bezuglyy
Dmitry Bezuglyyshared an impression8 months ago
👍
🔮Hidden Depths

QuotesAll

течение ряда лет при планировании разработки программного обеспечения я пользуюсь следующим эмпирическим правилом:
1/3 — планирование,
1/6 — написание программ,
1/4 — тестирование компонентов и предварительное системное тестирование,
1/4 — системное тестирование при наличии всех компонентов.
Вкратце мое мнение заключается в том, что трудности, испытываемые при управлении крупными программными проектами, иного рода, нежели при управлении небольшими проектами, что связано с проблемами разделения труда. Я считаю важнейшей задачей сохранение концептуальной целостности самого продукта.
разработка грандиозных идей — это удовольствие, а поиск паршивых маленьких «жучков» — это всего лишь работа.
В течение ряда лет при планировании разработки программного обеспечения я пользуюсь следующим эмпирическим правилом:
1/3 — планирование,
1/6 — написание программ,
1/4 — тестирование компонентов и предварительное системное тестирование,
1/4 — системное тестирование при наличии всех компонентов.
Программист, подобно поэту, работает почти непосредственно с чистой мыслью.
Редко удается контролировать условия работы и даже ее цели. На языке администрирования это означает, что полномочия ниже ответственности. Впрочем, похоже, что в любой работе, где должен быть получен результат, формальная власть никогда не соизмерима с ответственностью. На практике фактическая (в противоположность формальной) власть приобретается в результате успешного выполнения задач.
Сложность — это то, чем мы занимаемся, и сложность — это то, что нас ограничивает. Р. Л. Гласс (R. L. Glass) писал в 1988 году
Глава 1 Смоляная яма

Een Schip op bet strand is een baken in zee. (Корабль на мели — моряку маяк.)
ГОЛЛАНДСКАЯ ПОСЛОВИЦА
Самая яркая сцена доисторических времен — борьба огромных животных со смертью в смоляных ямах. Воображение представляет динозавров, мамонтов и саблезубых тигров, пытающихся высвободиться из смолы. Чем отчаянней борьба, тем сильнее затягивает смола, и как бы ни был силен или ловок зверь, в конечном итоге ему уготована гибель.
Такой смоляной ямой в последнее десятилетие было программирование больших систем: в ней сгинул не один большой и сильный зверь. По большей части это происходило в области систем, где мало кому удалось реализовать спецификации, уложиться в график и бюджет. Большие и малые, массивные и жилистые — одна за другой эти команды увязли в смоле. Казалось, ничто в отдельности не вызывает трудностей — одну лапу всегда можно вытащить. Но накопление действующих одновременно и взаимовлияющих факторов все более и более замедляет движение. Вызывает удивление неприятность возникшей проблемы, и распознать ее сущность нелегко. Но нужно это сделать, если мы собираемся решить ее.
Поэтому начнем с определения того, что такое системное программирование, и какие радости и печали оно таит.
Системный программный продукт
Время от времени можно прочесть в газете о том, как в переоборудованном гараже пара программистов сделала замечательную программу, оставившую позади разработки больших команд. И каждый программист охотно верит в эти сказки, поскольку знает, что может создать любую программу со скоростью, значительно превышающей те 1000 операторов в год, которые, по сообщениям, пишут программисты в промышленных бригадах.
Почему же до сих пор все профессиональные бригады программистов не заменены одержимыми дуэтами из гаражей? Нужно посмотреть на то, что, собственно, производится.
В левом верхнем углу рисунка 1.1 находится программа. Она является завершенным продуктом, пригодным для запуска своим автором на системе, на которой была разработана. В гаражах обычно производится такой продукт, и это — тот объект, посредством которого отдельный программист оценивает свою производительность.
Есть два способа, которыми программу можно превратить в более полезный, но и более дорогой объект. Эти два способа представлены по краям рисунка.
При перемещении вниз через горизонтальную границу программа превращается в программный продукт. Это программа, которую любой человек может запускать, тестировать, исправлять и развивать. Она может использоваться в различных операционных средах и со многими наборами данных. Чтобы стать общеупотребительным программным продуктом, программа должна быть написана в обобщенном стиле. В частности, диапазон и вид входных данных должны быть настолько обобщенными, насколько это допускается базовым алгоритмом. Затем программу нужно тщательно протестировать, чтобы быть уверенным в ее надежности. Для этого нужно подготовить достаточное количество контрольных примеров для проверки диапазона допустимых значений входных данных и определения его границ, обработать эти примеры и зафиксировать результаты. Наконец, развитие программы в программный продукт требует создания подробной документации, с помощью которой каждый мог бы использовать ее, делать исправления и расширять. Я пользуюсь практическим правилом, согласно которому программный продукт стоит, по меньшей мере, втрое дороже, чем просто отлаженная программа с такой же функциональностью.


Рис. 1.1 Эволюция системного программного продукта
При пересечении вертикальной границы программа становится компонентом программного комплекса. Последний представляет собой набор взаимодействующих программ, согласованных по функциям и форматам, и вкупе составляющих полное средство для решения больших задач. Чтобы стать частью программного комплекса, синтаксис и семантика ввода и вывода программы должны удовлетворять точно определенным интерфейсам. Программа должна быть также спроектирована таким образом, чтобы использовать заранее оговоренный бюджет ресурсов — объем памяти, устройства ввода/вывода, процессорное время. Наконец, программу нужно протестировать вместе с прочими системными компонентами во всех сочетаниях, которые могут встретиться. Это тестирование может оказаться большим по объему, поскольку количество тестируемых случаев растет экспоненциально. Оно также занимает много времени, так как скрытые ошибки выявляются при неожиданных взаимодействиях отлаживаемых компонентов. Компонент программного комплекса стоит, по крайней мере, втрое дороже, чем автономная программа с теми же функциями. Стоимость может увеличиться, если в системе много компонентов.
В правом нижнем углу рисунка 1.1 находится системный программный продукт. От обычной программы он отличается во всех перечисленных выше отношениях. И стоит, соответственно, в десять раз дороже. Но это действительно полезный объект, который является целью большинства системных программных проектов.
Радости профессии
Почему заниматься программированием интересно? Какими радостями вознаграждаются те, кто им занимается?
Во-первых, это просто радость, получаемая при создании чего-либо своими руками. Как ребенок радуется, делая куличики из песка, так и взрослый получает удовольствие, создавая какие-либо вещи, особенно если сам их и придумал. Я думаю, что этот восторг — отражение восторга Господа, творящего мир, восторга, проявляющегося в индивидуальности и новизне каждого листочка и каждой снежинки.
Во-вторых, это удовольствие создавать вещи, которые могут быть полезны другим людям. Глубоко в душе мы испытываем потребность в том, чтобы другие использовали результаты нашего труда и считали их полезными. В этом отношении программная система по своей сути — то же, что и изготовленная ребенком подставка для карандашей «папе в подарок».
В-третьих, это очарование создания сложных головоломных объектов, состоящих из взаимодействующих движущихся частей и наблюдения за их работой, круг за кругом демонстрирующей результаты изначально заложенных принципов. Компьютер с работающей на нем программой обладает доведенным до высшего предела очарованием игорного или музыкального автомата.
В-четвертых, это радость, получаемая от неизменного узнавания нового, проистекающего из неповторимой природы задачи. В том или ином отношении задача всегда ставится по-новому, и тот, кто ее решает, получает новые знания — либо практические, либо теоретические, либо те и другие вместе.
Наконец, наслаждение доставляет работа со столь податливым материалом. Программист, подобно поэту, работает почти непосредственно с чистой мыслью. Он строит свои замки в воздухе и из воздуха, творя силой воображения. Трудно найти другой материал, используемый в творчестве, который столь же гибок, прост для шлифовки или переработки и доступен для воплощения грандиозных замыслов. (Как мы позднее увидим, такая податливость таит свои проблемы.)
Он замечает, что нежелание документировать проект происходит не только от лени или недостатка времени. Оно происходит от нежелания проектировщика связывать себя отстаиванием решений, которые, как он знает, предварительные. «Документируя проект, проектировщик становится объектом критики со всех сторон, и должен защищать все, что написал. Если организационная структура может представлять угрозу, не будет документироваться ничего, кроме того, что нельзя оспорить
Компонент программного комплекса стоит, по крайней мере, втрое дороже, чем автономная программа с теми же функциями. Стоимость может увеличиться, если в системе много компонентов.
Итак, в основе планирования разработки программ лежит ложное допущение, что все будет хорошо, т.е. каждая задача займет столько времени, сколько «должна» занять.
Если проект не укладывается в сроки, то добавление рабочей силы задержит его еще больше.
Закон Брукса:
Если проект не укладывается в сроки, то добавление рабочей силы задержит его еще больше.
Почему заниматься программированием интересно? Какими радостями вознаграждаются те, кто им занимается?
Во-первых, это просто радость, получаемая при создании чего-либо своими руками. Как ребенок радуется, делая куличики из песка, так и взрослый получает удовольствие, создавая какие-либо вещи, особенно если сам их и придумал. Я думаю, что этот восторг — отражение восторга Господа, творящего мир, восторга, проявляющегося в индивидуальности и новизне каждого листочка и каждой снежинки.
Во-вторых, это удовольствие создавать вещи, которые могут быть полезны другим людям. Глубоко в душе мы испытываем потребность в том, чтобы другие использовали результаты нашего труда и считали их полезными. В этом отношении программная система по своей сути — то же, что и изготовленная ребенком подставка для карандашей «папе в подарок».
В-третьих, это очарование создания сложных головоломных объектов, состоящих из взаимодействующих движущихся частей и наблюдения за их работой, круг за кругом демонстрирующей результаты изначально заложенных принципов. Компьютер с работающей на нем программой обладает доведенным до высшего предела очарованием игорного или музыкального автомата.
В-четвертых, это радость, получаемая от неизменного узнавания нового, проистекающего из неповторимой природы задачи. В том или ином отношении задача всегда ставится по-новому, и тот, кто ее решает, получает новые знания — либо практические, либо теоретические, либо те и другие вместе.
Наконец, наслаждение доставляет работа со столь податливым материалом. Программист, подобно поэту, работает почти непосредственно с чистой мыслью. Он строит свои замки в воздухе и из воздуха, творя силой воображения. Трудно найти другой материал, используемый в творчестве, который столь же гибок, прост для шлифовки или переработки и доступен для воплощения грандиозных замыслов.
Если проект не укладывается в сроки, то добавление рабочей силы задержит его еще больше.
Маленьких задержек не бывает
Кроме того, постановка задач, обеспечение ресурсами и предоставление информации осуществляется другими людьми. Редко удается контролировать условия работы и даже ее цели. На языке администрирования это означает, что полномочия ниже ответственности.
Программному продукту грозит устаревание еще до его завершения.
Вывод прост: если над проектом работают 200 человек, включая менеджеров, являющихся наиболее знающими и опытными программистами, увольте 175 бойцов, и пусть менеджеры снова займутся программированием.
Архитектор всегда должен быть готов показать пример реализации любой описанной им функции, но он не должен пытаться навязывать определенную реализацию.

Related booksAll

Вальсируя с медведями, Тимоти Листер, Том Демарко
Тимоти Листер, Том Демарко
Вальсируя с медведями
Балдеющие от адреналина и зомбированные шаблонами. Паттерны поведения проектных команд, Джеймс Робертсон, Питер Хрущка, Стив Макменамин, Сьюзан Робертсон, Тимоти Листер, Том Демарко
Джеймс Робертсон, Питер Хрущка, Стив Макменамин, Сьюзан Робертсон, Тимоти Листер, Том Демарко
Балдеющие от адреналина и зомбированные шаблонами. Паттерны поведения проектных команд
Алистэр Коуберн
Люди как нели­ней­ные и наи­бо­лее важ­ные ком­по­ненты в со­зда­нии про­грамм­ного обес­пе­че­ния
Критическая цепь, Элияху Голдратт
Элияху Голдратт
Критическая цепь
fb2epub
Drag & drop your files (not more than 5 at once)