[{"data":1,"prerenderedAt":63},["ShallowReactive",2],{"$fzrFU5D_yBzzfvA45nIqvXzV9BOGMEditdKXmsKv-Wtw":3},{"article":4,"relatedArticles":42,"tagCounts":61},{"slug":5,"content":6,"headings":7,"notes":34,"groupedNotes":35,"title":36,"date":37,"description":38,"tags":39,"author":41},"brooks-frederick-p-jr-the-mythical-man-month-essays-on","\u003Ch4 id=\"1-общее-описание\">1. Общее описание\u003C\u002Fh4>\n\u003Cp>Книга представляет собой классический сборник эссе, посвященных \u003Cstrong>управлению сложными проектами в области программной инженерии\u003C\u002Fstrong>. Это не систематический учебник или справочник, а скорее глубокое размышление автора, основанное на его личном опыте руководства проектами OS\u002F360 в IBM. Текст рассчитан на \u003Cstrong>профессиональных программистов и руководителей проектов\u003C\u002Fstrong>, особенно тех, кто управляет крупными коллективами. Читатель научится понимать фундаментальные причины провалов графиков, узнает о важности концептуальной целостности продукта и получит практические советы по организации команд и процессов разработки.\u003C\u002Fp>\n\u003Ch4 id=\"2-структура-и-карта-охвата\">2. Структура и карта охвата\u003C\u002Fh4>\n\u003Cp>Книга состоит из 19 глав, которые изначально задумывались как самостоятельные эссе, но имеют центральную аргументацию, изложенную в главах 2–7.\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>Подробно разбираются:\u003C\u002Fstrong> проблемы оценки сроков, структура команд («хирургическая бригада»), концептуальная целостность и архитектура систем, коммуникации внутри проекта.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Упоминаются или рассматриваются как сопутствующие:\u003C\u002Fstrong> инструменты разработки, документирование и психологические аспекты управления.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Принцип организации:\u003C\u002Fstrong> первые 15 глав — это оригинальные эссе 1975 года, за которыми следуют дополнения юбилейного издания, включая знаменитую статью «Серебряной пули нет» (глава 16) и ретроспективный анализ спустя 20 лет (главы 17–19). Порядок глав продиктован логикой развития проекта: от осознания сложности («Смоляная яма») к организации команды, проектированию, контролю и, наконец, анализу самой природы софта.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch4 id=\"3-подробное-описание-разделов\">3. Подробное описание разделов\u003C\u002Fh4>\n\u003Ch5 id=\"часть-i-природа-программирования-и-мифы-управления-главы-12\">Часть I: Природа программирования и мифы управления (Главы 1–2)\u003C\u002Fh5>\n\u003Cp>В начале автор определяет программирование как творческую деятельность, полную радостей и огорчений, и вводит понятие \u003Cstrong>«программного системного продукта»\u003C\u002Fstrong>, создание которого в 9 раз сложнее написания простой программы. Центральная тема — \u003Cstrong>мифический человеко-месяц\u003C\u002Fstrong>. Брукс доказывает, что люди и время не являются взаимозаменяемыми ресурсами в системном программировании из-за затрат на обучение и коммуникацию. Формулируется \u003Cstrong>Закон Брукса\u003C\u002Fstrong>: добавление людей в поздний проект задерживает его еще сильнее.\u003C\u002Fp>\n\u003Ch5 id=\"часть-ii-организация-команды-и-концептуальная-целостность-главы-37\">Часть II: Организация команды и концептуальная целостность (Главы 3–7)\u003C\u002Fh5>\n\u003Cp>Автор предлагает концепцию \u003Cstrong>«хирургической бригады»\u003C\u002Fstrong> Харлана Миллаза, где один ведущий программист («хирург») создает систему, а остальные члены команды обеспечивают его всем необходимым, что позволяет сохранить единство замысла.\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>Концептуальная целостность\u003C\u002Fstrong> называется важнейшим фактором успеха системы. Для ее достижения архитектура (описание интерфейса пользователя) должна быть отделена от реализации.\u003C\u002Fli>\n\u003Cli>Рассматривается проблема «аристократии» архитекторов и «демократии» исполнителей, где дисциплина формы признается благом для творчества.\u003C\u002Fli>\n\u003Cli>Обсуждается крах «Вавилонской башни» как пример провала коммуникаций и предлагается использование формальных \u003Cstrong>рабочих журналов проекта\u003C\u002Fstrong>.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch5 id=\"часть-iii-оценка-ресурсы-и-документация-главы-810\">Часть III: Оценка, ресурсы и документация (Главы 8–10)\u003C\u002Fh5>\n\u003Cp>Приводятся данные о производительности программистов, показывающие, что сложность задач (например, создание ОС по сравнению с компилятором) радикально меняет выработку.\u003C\u002Fp>\n\u003Cul>\n\u003Cli>Подчеркивается роль \u003Cstrong>контроля размера программ\u003C\u002Fstrong> и важность представления данных как сущности программирования.\u003C\u002Fli>\n\u003Cli>Выдвигается «документальная гипотеза»: управление проектом вращается вокруг небольшого набора ключевых документов (цели, спецификации, график, бюджет).\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch5 id=\"часть-iv-жизненный-цикл-и-инструменты-главы-1115\">Часть IV: Жизненный цикл и инструменты (Главы 11–15)\u003C\u002Fh5>\n\u003Cp>Автор дает знаменитый совет: \u003Cstrong>«Планируйте выбросить одну версию, вы все равно это сделаете»\u003C\u002Fstrong>, подчеркивая неизбежность изменений и необходимость пилотных систем.\u003C\u002Fp>\n\u003Cul>\n\u003Cli>Описываются «острые инструменты»: важность симуляторов целевых машин, библиотек программ и использования языков высокого уровня.\u003C\u002Fli>\n\u003Cli>Рассматриваются методы «выращивания» системы через нисходящее проектирование и пошаговую отладку.\u003C\u002Fli>\n\u003Cli>Критикуется «проклятие блок-схем» и предлагается переход к \u003Cstrong>самодокументированным программам\u003C\u002Fstrong>.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch5 id=\"часть-v-серебряной-пули-нет-и-ретроспектива-главы-1619\">Часть V: «Серебряной пули нет» и ретроспектива (Главы 16–19)\u003C\u002Fh5>\n\u003Cp>В главе 16 автор утверждает, что сложность софта является его \u003Cstrong>сущностной характеристикой\u003C\u002Fstrong>, а не случайной. Он предсказывает, что ни одна технология не даст десятикратного роста производительности за десятилетие.\u003C\u002Fp>\n\u003Cul>\n\u003Cli>В ретроспективных главах Брукс признает свои прошлые ошибки (например, он пересмотрел отношение к сокрытию информации по Парнасу) и анализирует влияние микрокомпьютерной революции.\u003C\u002Fli>\n\u003Cli>Подтверждается актуальность концептуальной целостности и важность инвестиций в \u003Cstrong>великих дизайнеров\u003C\u002Fstrong>, а не только в процессы.\u003C\u002Fli>\n\u003C\u002Ful>",[8,12,15,18,22,25,28,31],{"id":9,"text":10,"depth":11},"1-общее-описание","1. Общее описание",3,{"id":13,"text":14,"depth":11},"2-структура-и-карта-охвата","2. Структура и карта охвата",{"id":16,"text":17,"depth":11},"3-подробное-описание-разделов","3. Подробное описание разделов",{"id":19,"text":20,"depth":21},"часть-i-природа-программирования-и-мифы-управления-главы-12","Часть I: Природа программирования и мифы управления (Главы 1–2)",4,{"id":23,"text":24,"depth":21},"часть-ii-организация-команды-и-концептуальная-целостность-главы-37","Часть II: Организация команды и концептуальная целостность (Главы 3–7)",{"id":26,"text":27,"depth":21},"часть-iii-оценка-ресурсы-и-документация-главы-810","Часть III: Оценка, ресурсы и документация (Главы 8–10)",{"id":29,"text":30,"depth":21},"часть-iv-жизненный-цикл-и-инструменты-главы-1115","Часть IV: Жизненный цикл и инструменты (Главы 11–15)",{"id":32,"text":33,"depth":21},"часть-v-серебряной-пули-нет-и-ретроспектива-главы-1619","Часть V: «Серебряной пули нет» и ретроспектива (Главы 16–19)",[],{},"The Mythical Man-Month: Essays on Software Engineering (1995)","2026-07-22","Классика управления разработкой — мифический человеко-месяц, хирургические бригады, концептуальная целостность и отсутствие серебряной пули.",[40],"Программирование","Brooks, Frederick P., Jr.",[43,49,55],{"slug":44,"title":45,"description":46,"date":37,"author":47,"tags":48},"mdn-contributors-css-performance-optimization-2025","CSS performance optimization (2025)","Оптимизация CSS для быстрого рендера — блокировка отрисовки, reflow, анимации на GPU, шрифты и CSS Containment.","MDN Contributors",[40],{"slug":50,"title":51,"description":52,"date":37,"author":53,"tags":54},"simpson-kyle-you-don-t-know-js-async-performance-2015","You Don't Know JS: Async & Performance (2015)","Асинхронность и производительность в JavaScript — событийный цикл, промисы, генераторы, Web Workers и практики бенчмаркинга.","Simpson, Kyle",[40],{"slug":56,"title":57,"description":58,"date":37,"author":59,"tags":60},"spolsky-joel-the-law-of-leaky-abstractions-2002","The Law of Leaky Abstractions (2002)","Закон дырявых абстракций — почему любое упрощение в программировании рано или поздно просачивается и не освобождает от изучения основ.","Spolsky, Joel",[40],{"Программирование":62},9,1785324880330]