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

Эта книга - своего рода библии для разработчиков программного обеспечения во всем мире, написанное Бруксом еще в 1975 году. Тогда же книга была издана на русском языке и давно уже стала библиографической редкостью. В США полагают, что без прочтения книги Брукса не может состояться ни один крупный руководитель программного проекта.

Жанры

Рейтинг LiveLib

4,0

345 оценок

5
36%
4
38%
3
21%
2
2%
1
2%

Ваша оценка

Прочитали 400Хотят прочитать 755

Рецензии

EmpyrosX
12 июня 2014
Наконец-то я прочитал эту книгу.
Прочитал в основном только потому, что многие мои знакомые разработчики часто спрашивали: "А ты читал Мифический человеко-месяц?" - обязательно прочитай, это классика.
Для меня чтение этой книги было в тягость, я не нашёл в ней совершенно ничего нового для себя и поставил оценку 1 из 5.
Если бы меня спросили другие, стоит ли им читать, то я бы сказал следующее.
Если вы только окончили институт (стали новоиспеченным инженером-программистом) и мало работали по специальности, то, возможно, книга окажется для вас полезной.
Тот же, кто проработал по специальности уже несколько лет, прочитал нескольких других умных книг как по программированию, так и по управлению, и понимает, чем программа, написанная в гараже на коленках, отличается от полноценного программного продукта навряд-ли найдёт в этой книге для себя что-то новое. Во-первых, многие данные из книги просто устарели - технологии продвинулись настолько вперед, что многие рекомендации теперь просто не нужны. Во-вторых, сама книга написана тяжелым языком, а это обычно говорит о том, что автор не осознает того, о чем пишет. Если взять, например, тот же "Человеческий фактор" от Т. Демарко и Т. Листера, то сразу видно, что товарищи реально понимают о чём пишут и излагают это очень понятным языком.
В целом, весь материал, изложенный в этой книге, можно было бы уменьшить в 20 раз и книга стала бы намного лучше. Мне кажется, что книга продаётся и расходится сейчас только благодаря пиару и некоторым крылатыми фразам типа "Серебряной пули нет". Да, в своё время она была полезна, но сейчас есть лучшие источники для получения знаний.
Читать далее
10 понравилось
0
1,1K
ShCat
15 апреля 2024
Книга про разработку ПО 50-летней давности
Книга о том, как пишутся большое программное обеспечение (ПО), очень большое, например, такое как операционные системы. А точнее — про проблемы при написании такого ПО. При этом эта книга написана в 1975 году! Было переиздание книги в 1995 года, но само содержание изменению не подверглось, добавилась только, по большей части, одна глава. Несмотря на возраст книги почти в 50 лет, она весьма популярна у разработчиков — у меня в руках книга, отпечатанная в 2024 году. Книга подаётся как сборник эссе, но читается как весьма целостная книга.
Действительно, много мыслей до сих пор актуальны, хотя есть что-то, что безбожно устарело, где-то это главы целиком.
Предпоследний главой идут «тезисы книги», которые кратко пересказывают всю книгу. По сути ещё приложили эту же книгу в кратком изложении. Мне кажется было бы проще по тексту подсветить важные мысли. Ну да ладно. Последняя глава — та самая новая глава, оценка мыслей книги, сделанная в 1995 г. — опять вкратце перепечатали книгу со свежими комментариями. Получили трижды написанную книгу в одной. Ну да ладно второй раз.
Основные мысли из книги:
- Стоимость проекта варьируется в зависимости от числа людей и числа месяцев (человеко-месяц), а длительность проекта — нет, т.к. люди и месяца не взаимозаменяемы.
- Практически ни один проект невозможно завершить менее чем за 3/4 от рассчитанного оптимального графика, вне зависимости от числа привлеченных людей.
- При написании ПО, в среднем, 1/3 уходит на планирование и проектирование, 1/6 — на написание кода, 1/4 — на тестирование компонентов, 1/4 — на тестирование всей системы в целомБольшой ошибкой будет не выделять достаточное время на тестирование, т.к. сбои выявляются в конце графика, поэтому о проблеме можно не знать почти вплоть до даты поставки.
- Добавление людей в проект требует увеличение общего объема трудозатрат на: 1) пересмотр и перераспределения работы; 2)обучения новых работников; 3) увеличение времени на коммуникации.
- В большинстве случаев, если проект не укладывается в сроки, то добавление людей задержит его ещё больше.
- Лучше иметь систему, в которой нет каких-то особенностей, но отражается один набор идей архитектурного дизайна (концептуальная целостность), чем иметь систему с кучей хороших, но независимых и несогласованных идей.
- Концептуальная целостность требует, чтобы проект исходил от одного разработчика или их небольшого числа, действующих в унисон.
- Для проекта важен набор документов (целевые критерии, спецификация, график и т.п.) — помимо возможности сообщить друг-другу решения, только когда пишешь, становятся видны недочёты и проступают несогласованностиИсправление ошибки в ПО имеет существенный (20-50%) шанс привнести ещё одну ошибку.
- При планировании надо ставить максимально четкие и недвусмысленные контрольные точки, чтобы не давать возможности участникам заниматься самообманом по поводу их достижения.
- Лучшая документация — это хорошочитаемый код (хорошо оформленный, с комментариями, понятными названиями переменных и т.п.)
И для тех, кто дочитал эту скукотень до конца — бонус трек, очень понравилась мысль, мне точно будет полезна: если вы хотите, чтобы ваши подчиненные открыто информировали о проблемах, то нужно научиться не предпринимать никаких действий в случаях когда проблемы могут быть решены подчиненными без вашего участия.

Ставлю 7, т.к., несмотря на достаточное количество умных мыслей, КПД книги не такой высокий. А может просто из-за того, что я не разработчик, я не осознал всю пользу книги. Желающим — читайте главу 2 (она дала название книги), а потом краткое изложение книги в главе 18. Далее уже можно выборочно почитать отдельные главы.

Читать далее
7 понравилось
0
118
yurykislyak
5 ноября 2017
Книга устаревшая, тяжелая, но очень основательная.
Вещи написаны в книге кажутся поверхностными и очевидными. Прописные истинны, а-ля "9 женщин не могут родить ребенка за месяц".
Но. Я разработчик, и мне было забавно читать и понимать, что за последние пару лет я видел вживую в исполнении менеджмента буквально все ошибки, от которых пытается предостеречь автор.
Хотя, это говорит скорее не о какой-от уникальной ценности информации в книге, а о качестве менеджмента.
Книгу прочесть все-таки стоит, хотя бы из-за легендарной главы "Серебряной пули нет". А еще это неплохой экскурс в историю становления отрасли.
Читать далее
7 понравилось
0
1,8K