(Я полагаю, что это полезно до сих пор, в 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 говорит: «Если вы пропустили один крайний срок, будьте уверены, что пропустите и второй.» [120] )
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 Смоляная яма программной инженерии ещё долгое время будет оставаться вязкой.