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

13.14 Рекомендуется создать большое окружение и много проверочного кода и «лесов» для отладки, возможно, на 50 процентов больше, чем сам отлаживаемый продукт.

13.15 Необходимо контролировать изменения и версии, при этом члены команды пусть играют со своими копиями на «площадках для игр».

13.16 Во время системного тестирования добавляйте компоненты по одному.

13.17 Леман и Белади свидетельствуют, что квант изменений должен быть либо большим и вноситься редко, либо очень маленьким — и часто. Последний случай более чреват неустойчивостью. (В Microsoft работают маленькими частыми квантами. Разрабатываемая система собирается заново каждые сутки.)

Глава 14. Назревание катастрофы

14.1 «Как оказывается, что проект запаздывает на один год? …Сначала он запаздывает на один день.»

14.2 Отставание, растущее понемногу изо дня в день, труднее распознать, труднее предотвратить, труднее выправить.

14.3 Чтобы управлять большим проектом по жесткому графику, надо прежде всего иметь график, состоящий из вех и соответствующих им дат.

14.4 Вехи должны быть конкретными, специфическими, измеримыми событиями, определенными с предельной точностью.

14.5 Программист редко лжет относительно движения вехи, если веха очерчена резко, он не может обманывать себя.

14.6 Исследования поведения правительственных подрядчиков по проведению оценок в крупных проектах показали, что оценки сроков работы, тщательно пересматриваемые каждые две недели, незначительно меняются по мере приближения начала работ, что во время работ переоценки уверенно снижаются и что недооценки не меняются, пока до запланированного срока окончания работ не остается около трех недель.

14.7 Хроническое отставание от графика убивает моральный дух. (Джим Маккарти из Microsoft говорит: «Если вы пропустили один крайний срок, будьте уверены, что пропустите и второй.» [2] )

14.8 Для выдающихся команд программистов характерна энергия, как и для выдающихся бейсбольных команд.

14.9 Ничто не заменит график с критическими путями, чтобы определить, какое отставание во что обойдется.

14.10 Подготовка диаграммы критических путей есть самая ценная часть ее применения, поскольку определение топологии сети, указание зависимостей в ней и оценивание путей вынуждают осуществить большой объем очень конкретного планирования на самых ранних стадиях проекта.

14.11 Первая диаграмма всегда ужасна, и для создания второй приходится проявить много изобретательности.

14.12 Диаграмма критических путей дает отпор деморализующей оговорке «другая часть тоже запаздывает».

14.13 Каждому начальнику нужны два вида данных: информация о срывах плана, которая требует вмешательства, и картина состояния дел, чтобы быть осведомленным и иметь раннее предупреждение.

14.14 Получить правдивую картину состояния дел нелегко, поскольку у подчиненных менеджеров есть основания не делиться своими данными.

14.15 Неправильными действиями начальник может обеспечить утаивание всей картины состояния дел; напротив, тщательное рассмотрение отчетов без паники и вмешательства поощряет честный доклад.

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

14.17 Высоцкий: «Я нашел, что удобно иметь в отчете о состоянии работ две даты — «плановую» (дату начальника) и «оцениваемую» (дату менеджера низшего звена). Менеджер проекта должен осторожно относиться к оцениваемым датам.»

14.18 Небольшая группа планирования и контроля, дающая отчеты о прохождении вех, неоценима при работе над большим проектом.

Глава 15. Обратная сторона

15.1 Для программного продукта сторона, обращенная к пользователю, — документация — столь же важна, как и сторона, обращенная к машине.

15.2 Даже для программ, написанных исключительно для себя, текстуальная документация необходима: память может изменить автору-пользователю.

15.3 В целом, преподавателям и менеджерам не удалось воспитать на всю жизнь у программистов уважение к документации, преодолевающее лень и пресс графика работ.

15.4 Эта неудача вызвана не столько недостатком старания или красноречия, сколько неспособностью показать, как проводить документирование эффективно и экономично.

15.5 Документация часто страдает отсутствием общего обзора. Посмотрите сначала издалека, а потом медленно приближайтесь.

15.6 Важная документация пользователя должна быть вчерне написана до разработки программы, поскольку в ней содержатся основные плановые решения. В ней должны быть описаны девять предметов (см. текст главы).

15.7 Программу нужно поставлять с несколькими контрольными примерами: с допустимыми входными данными, допустимыми на грани возможностей, и с явно недопустимыми входными данными.

15.8 Внутренняя документация программы, предназначенная тому, кто должен ее модифицировать, также должна содержать текстуальный обзор, в котором должны быть описаны пять предметов (см. главу).

15.9 Блок-схема чаще всего напрасно включается в документацию. Подробная пошаговая блок-схема устарела благодаря письменным языкам высокого уровня. (Блок-схема — графический язык высокого уровня.)

15.10 Редко требуется блок-схема более чем на одну страницу — если она вообще нужна. (Стандарт MILSPEC здесь совершенно не прав.)

15.11 Что действительно необходимо — это структурный граф программы без соблюдения стандартов составления блок-схем ANSI.

15.12 Чтобы обеспечить обновление документации, важно включить ее в исходный текст программы, а не держать отдельным документом.

15.13 Для облегчения труда ведения документации есть три важных правила:

• Как можно больше используйте для документирования обязательные части программы, такие как имена и объявления.

• Используйте свободное пространство и формат, чтобы показать отношения подчиненности, вложенности и улучшить читаемость.

• Вставляйте в программу необходимую текстовую документацию в виде параграфов комментариев, особенно в заголовках модулей.

15.14 В документации, которой будут пользоваться при модификации программы, объясняйте не только «как», но и «почему». Назначение является решающим для понимания. Даже языки высокого уровня совсем не передают значения.

15.15 Методы самодокументирующегося программирования наиболее полезны и мощны при использовании языков высокого уровня.

Эпилог к первому изданию

E.1 Программные системы являются, возможно, самыми сложными и запутанными (в смысле числа различных типов составляющих) созданиями человека.

E.2 Смоляная яма программной инженерии еще долгое время будет оставаться вязкой.

Глава 19 «Мифический человеко-месяц» двадцать лет

Я не знаю другого способа судить о будущем, как с помощью прошлого.

ПАТРИК ГЕНРИ

Опираясь на прошлое, невозможно планировать будущее.

ЭДМУНД БЕРК

Для чего понадобилось юбилейное двадцатое издание?

Самолет гудел в ночи, направляясь к Лагардии. Облака и сумрак скрыли все интересное для глаза. Документ, который я читал, был неинтересным. Однако мне не было скучно. Сидящий рядом попутчик читал «Мифический человеко-месяц», и я ожидал, когда словом или жестом он выдаст свое впечатление. В конце концов, когда мы уже выруливали к выходу, я не выдержал:

— Как вам эта книга? Советуете прочесть?

— Хм, в ней нет ничего, чего я не знал бы раньше.

Я решил не представляться.

Почему «Мифический человеко-месяц» выжил? Почему с ним до сих пор считаются в современной практике программирования? Почему его читательская аудитория выходит за пределы сообщества программистов-разработчиков, а книга порождает статьи, цитаты и письма не только разработчиков программ, но и юристов, врачей, психологов, социологов? Каким образом книга, написанная 20 лет назад об опыте разработки программ, имевшем место 30 лет назад, может до сих пор быть актуальной и даже полезной?

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