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

Интерактивное программирование

12.17 В некоторых приложениях пакетные системы никогда не будут вытеснены интерактивными системами. (По-прежнему верно.)

12.18 Отладка — это тяжелая и долгая часть системного программирования, и медленная оборачиваемость является проклятием отладки.

12.19 Есть свидетельства тому, что интерактивное программирование по крайней мере удваивает скорость системного программирования.

Глава 13. Целое и части

13.1 Детальная и старательная проработка архитектуры согласно главам 4, 5 и 6 не только упрощает использование продукта, но также облегчает его разработку и делает менее подверженным ошибкам.

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

13.3 Задолго до всякого написания программы спецификация должна быть передана сторонней группе тестирования для тщательного рассмотрения полноты и ясности. Сами разработчики сделать это не могут.

13.4 «Нисходящее проектирование Вирта (с пошаговым уточнением) является самой важной новой формализацией программирования за десятилетие (1965-1975).»

13.5 Вирт проповедует использование на каждом шаге нотации возможно более высокого порядка.

13.6 Хорошее нисходящее проектирование помогает избегать ошибок благодаря четырем обстоятельствам.

13.7 Иногда приходится возвращаться назад, отбрасывать самый верхний уровень и начинать все сначала.

13.8 Структурное программирование, т.е. разработка программ, управляющие структуры которых состоят только из заданного набора операторов, воздействующих на блоки кода (в противоположность беспорядочным переходам), дает верный способ избежать ошибок и представляет собой правильный способ мышления.

13.9 Экспериментальные данные Голда показывают, что во время первого диалога каждого сеанса достигается втрое больший прогресс в интерактивной отладке, чем при последующих диалогах. Все же полезно тщательно спланировать отладку, прежде чем регистрироваться на машине. (Я полагаю, что это полезно до сих пор, в 1995 году.)

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

13.11 Системная отладка (в отличие от отладки компонентов) занимает больше времени, чем ожидается.

13.12 Трудность системной отладки оправдывает тщательную систематичность и плановость.

13.13 Системную отладку нужно начинать, только убедившись в работоспособности компонентов, (в противоположность подходу «свинти и попробуй» и началу системной отладки при известных, но не устраненных ошибках в компонентах). (Это особенно справедливо для бригад.)

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 Для программного продукта сторона, обращенная к пользователю, — документация — столь же важна, как и сторона, обращенная к машине.