Страница:
внутренних границ структур. Часто исходные границы служат причиной выявляющихся впоследствии недостатков.)
Глава 12. Острый инструмент
12.1 Менеджер проекта должен установить принципы и выделить ресурсы для разработки общеупотребляемых инструментов, в то же время он должен признать необходимость в персонализированных инструментах.
12.2 Бригадам, разрабатывающим операционные системы, необходима для отладки собственная целевая машина. Для нее требуется скорее максимум памяти, чем максимум скорости, и системный программист для поддержки стандартного программного обеспечения.
12.3 Машина для отладки или ее программное обеспечение должны иметь инструмент для автоматического подсчета и изменения всех видов параметров программы.
12.4 Потребность в целевой машине описывается специфической кривой: после низкой активности следует взрывной рост, который потом выравнивается.
12.5 Системной отладкой, как астрономией, всегда занимались преимущественно по ночам.
12.6 Вопреки теории, выделение времени целевой машины одной бригаде значительными блоками оказалось лучшим вариантом планирования времени, чем чередование использования машины бригадами.
12.7 Этот предпочтительный при нехватке компьютеров метод планирования времени пережил 20 лет (с 1975 года) технологических изменений, поскольку является наиболее продуктивным. (И остается им в 1995 году.)
12.8 Если целевой компьютер является новым, необходим его логический эмулятор. Его можно получить раньше, и он обеспечивает надежную машину для отладки даже после того, как поставляется настоящая машина.
12.9 Главную библиотеку программ нужно разделить на: 1) набор индивидуальных «игровых площадок», 2) подбиблиотеку системной интеграции, проходящую системное тестирование и 3) версию-релиз. Формальное разделение и перемещение обеспечивают контроль.
12.10 Инструмент, обеспечивающий наибольшую экономию труда в программном проекте, — это, наверное, система редактирования текстов.
12.11 Объемистость системной документации создает новый тип непостижимости (см., например Unix), но это значительно предпочтительнее, чем более распространенный крайний недостаток документации.
12.12 Создайте эмулятор производительности снаружи внутрь, сверху вниз. Начните работу с ним как можно раньше. Прислушайтесь к тому, что он вам скажет.
Языки высокого уровня
12.13 Только лень и инертность препятствуют повсеместному применению языков высокого уровня и интерактивного программирования. (Но сегодня они приняты повсеместно.)
12.14 Язык высокого уровня способствует не только увеличению производительности, но и отладке. Меньше ошибок и легче поиск.
12.15 Прежние возражения, связанные с функциональностью, размером и скоростью результирующей программы устарели благодаря развитию языков и технологии компиляции.
12.16 Сегодня единственный подходящий кандидат для системного программирования — PL/I. (Больше не соответствует действительности.)
Интерактивное программирование
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 Для программного продукта сторона, обращенная к пользователю, — документация — столь же важна, как и сторона, обращенная к машине.
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 Смоляная яма программной инженерии еще долгое время будет оставаться вязкой.
Для чего понадобилось юбилейное двадцатое издание?
Самолет гудел в ночи, направляясь к Лагардии. Облака и сумрак скрыли все интересное для глаза. Документ, который я читал, был неинтересным. Однако мне не было скучно. Сидящий рядом попутчик читал «Мифический человеко-месяц», и я ожидал, когда словом или жестом он выдаст свое впечатление. В конце концов, когда мы уже выруливали к выходу, я не выдержал:
— Как вам эта книга? Советуете прочесть?
— Хм, в ней нет ничего, чего я не знал бы раньше.
Я решил не представляться.
Почему «Мифический человеко-месяц» выжил? Почему с ним до сих пор считаются в современной практике программирования? Почему его читательская аудитория выходит за пределы сообщества программистов-разработчиков, а книга порождает статьи, цитаты и письма не только разработчиков программ, но и юристов, врачей, психологов, социологов? Каким образом книга, написанная 20 лет назад об опыте разработки программ, имевшем место 30 лет назад, может до сих пор быть актуальной и даже полезной?
Согласно одному из объяснений, которые можно услышать, разработка программного обеспечения как дисциплина не получила нормального и правильного развития. В поддержку этой точки зрения часто указывают на несоответствие роста производительности труда программистов и эффективности производства компьютеров, выросшей в тысячи раз за последние два десятилетия. Как объясняется в главе 16, аномалия состоит не в замедленном развитии программирования, а в беспрецедентном в истории человечества взрыве компьютерных технологий. В целом, причина этого в постепенном переходе производства компьютеров из сборочного производства в обрабатывающее, из трудоемкого производства в капиталоемкое. Разработка же аппаратного и программного обеспечения, в отличие от производства, остается по своей сути трудоемкой.
Второе часто выдвигаемое объяснение гласит, что «Мифический человеко-месяц» лишь случайно касается разработки программного обеспечения, а в основном он написан о групповой разработке чего бы то ни было. Доля правды в этом есть. В предисловии к изданию 1975 года сказано, что управление программным проектом имеет больше сходства с любым другим управлением, чем изначально считается большинством программистов. Я до сих пор так считаю. История человечества — это пьеса, в которой сюжеты постоянны, сценарии медленно меняются с развитием культуры, а декорации меняются непрерывно. Поэтому в ХХ веке мы узнаем себя в Шекспире, Гомере и Библии. Поэтому в той мере, в какой «МЧ-М» написан о людях, он устаревает медленно.
Каковы бы ни были причины, книгу продолжают покупать и присылают мне замечания, которые я ценю. Меня часто спрашивают: «Как вы считаете, в чем вы тогда ошиблись? Что устарело в наши дни? Что действительно новое появилось в мире разработки программ?» Эти четкие вопросы вполне законны, и я постараюсь
ответить на них. Не в таком, правда, порядке, но по группам тем. Прежде всего, посмотрим, что было верным в момент написания и осталось таковым до сих пор.
Центральный аргумент: концептуальная целостность и архитектор
Концептуальная целостность. Чистый и элегантный программный продукт должен представить своим пользователям согласованную идеальную модель приложения, стратегий осуществления приложения и тактики пользовательских интерфейсов, используемой при задании действий и параметров. Концептуальная целостность продукта в восприятии пользователя является важнейшим фактором, влияющим на простоту использования. (Есть, конечно, и другие факторы. Важным примером является единообразие пользовательского интерфейса в приложениях для Macintosh. Более того, можно создать согласованные интерфейсы, являющиеся тем не менее, совершенно неуклюжими. Например MS-DOS.)
Есть многочисленные примеры элегантных программных продуктов, созданных одним или двумя людьми. Так делается большая часть чисто интеллектуальных продуктов, таких как книги или музыкальные произведения. Однако во многих промышленных областях процессы разработки продукта не могут осуществляться на основе столь простого подхода к концептуальной целостности. Конкуренция вынуждает к спешке. Во многих современных технологиях конечный продукт обладает большой сложностью, и проектирование неизбежно требует многих человеко-месяцев труда. Для программных продуктов характерны как сложность, так и напряженность графика, обусловленная конкуренцией.
Таким образом, всякий достаточно большой или срочный продукт, требующий усилий многих людей, сталкивается со специфической трудностью: результат должен концептуально согласовываться с разумом одиночного пользователя и в то же время проектироваться усилиями нескольких разумов. Как организовать проектирование, чтобы достичь такой концептуальной целостности? Это центральный вопрос «МЧ-М». Один из его тезисов гласит, что существуют качественные различия между управлением большими и маленькими программными проектами — лишь в силу числа работающих над ними голов. Для достижения согласованности необходимы обдуманные и даже героические действия.
Архитектор. С четвертой по шестую главу я доказываю, что самое важное — назначить одного человека архитектором продукта, ответственным за все его стороны, воспринимаемые пользователем. Архитектор формирует и имеет в своем владении общедоступную идеальную модель продукта, с помощью которой пользователю будет объяснено его применение. В ее состав входит подробное указание всех его функций и средств вызова и управления. Архитектор также действует в интересах пользователя при поиске компромисса между функциями, техническим характеристиками, размером, стоимостью и выполнением графика работ. Выполнение этой задачи требует полной занятости, и только в очень маленьких группах может быть совмещено с должностью руководителя. Архитектора можно сравнивать с режиссером, а менеджера — с продюсером кинокартины.
Отделение архитектуры от разработки и реализации. Чтобы сделать возможным осуществление архитектором своей главной задачи, необходимо отделить архитектуру, т.е. определение продукта в восприятии пользователя, от его разработки. Архитектура и разработка определяют четкую грань между разными частями задачи проектирования, и по каждую сторону этой грани лежит большая работа.
Рекурсивность архитектуры. В очень больших проектах одному человеку не справиться со всей архитектурой, даже если он избавлен от всех забот, связанных с разработкой. Поэтому главный архитектор системы должен разбить целое на подсистемы. Границы подсистем должны быть проведены так, чтобы интерфейсы между ними были минимальны и легче всего строго определяемы. Тогда у каждой части может быть свой архитектор, подчиняющийся главному архитектору системы в отношении архитектуры. Очевидно, при необходимости этот процесс может быть продолжен рекурсивно.
Сегодня я убежден более чем когда-либо. Концептуальная целостность является важнейшим условием качества продукта. Наличие системного архитектора есть важнейший шаг в направлении концептуальной целостности. Эти принципы ни в коей мере не ограничиваются разработкой программного обеспечения, а справедливы при проектировании любой сложной конструкции, будь то компьютер, самолет, стратегическая оборонная инициатива или система глобальной навигации. После преподавания в более чем 20 лабораториях разработки программного обеспечения я стал настаивать, чтобы группы учащихся, даже из четырех человек, выбирали менеджера и отдельно — архитектора. Разделение функций в таких маленьких группах может показаться несколько чрезмерным требованием, но, по моим наблюдениям, это оправдано и способствует достижению успеха.
Эффект второй системы: функциональность и угадывание частоты
Проектирование для больших групп пользователей. Одним из последствий революции, произведенной персональными компьютерами, является все возрастающее, по крайней мере в области обработки деловых данных, вытеснение заказных программ коробочными программными пакетами. Более того, стандартные программные пакеты продаются сотнями тысяч и даже миллионами экземпляров. Системные архитекторы программ, поставляемых вместе с машиной, всегда должны были создавать проект, ориентированный на большую аморфную массу пользователей, а не на отдельное определенное приложение в одной компании. Теперь такая задача встает перед очень многими архитекторами.
Парадокс состоит в том, что спроектировать инструмент общего назначения, нежели специализированный, гораздо труднее именно потому, что нужно придать вес различающимся потребностям разных пользователей.
В погоне за функциональностью. Архитектор инструмента общего назначения, такого, например, как электронная таблица или текстовый редактор, подвержен сильному соблазну перегрузить продукт функциями предельной полезности ценой снижения производительности и даже простоты использования. Вначале привлекательность предлагаемых возможностей кажется очевидной. Расплата производительностью становится очевидной лишь при системном тестировании. Утрата простоты использования коварно подкрадывается по мере того, как небольшими порциями добавляются новые функции, а руководства пользователя все более разбухают. [1]
Соблазн особенно велик в отношении долгоживущих массовых продуктов, развивавшихся на протяжении ряда поколений. Миллионы покупателей требуют сотен новых возможностей. Всякая просьба свидетельствует о наличии спроса на рынке. Часто архитектор первоначальной системы уже ушел в поход за новой славой, и архитектура оказалась в руках людей с меньшим опытом взвешенного представления общих интересов пользователей. В недавней рецензии на Microsoft Word 6.0 сказано: «Переполнен возможностями; обновление замедлено перегруженностью… Кроме того, Word 6.0 занимает много места и медленно работает.» С неудовольствием отмечается, что Word 6.0 занимает 4 Мбайт памяти и сообщается, что из-за богатых дополнительных функциональных возможностей «даже Macintosh IIfx едва пригоден для выполнения Word 6». [2]
Определение группы пользователей. Чем крупнее и аморфнее группа предполагаемых пользователей, тем более необходимо явно ее определить, если вы намерены достичь концептуальной целостности. У каждого члена группы проектировщиков наверняка есть неявный мысленный образ пользователя, и все образы будут отличаться друг от друга. Поскольку представление архитектора о пользователе явно или подсознательно оказывает влияние на все архитектурные решения, важно, чтобы команда проектировщиков пришла к единому общему образу. Для этого необходимо составить список признаков предполагаемых пользователей, указав в нем:
• кто они такие,
• что им нужно,
• что, по их мнению, им нужно,
• чего они хотят.
Частоты. Для любого программного продукта каждая характеристика пользователя представляет собой распределение со множеством возможных значений и соответствующими частотами. Как архитектору получить эти частоты? Изучение этой слабо очерченной популяции представляется сомнительным и дорогостоящим занятием. [3] С годами я пришел к убеждению, что архитектор должен угадать или, если вам больше нравится, постулировать полный набор признаков и значений вместе с частотами для создания полного, явного и общего для всех описания группы пользователей.
Такая непривлекательная процедура имеет ряд полезных последствий. Во-первых, при стремлении точно угадать частоты архитектор вынужден очень тщательно обдумать, какова возможная группа пользователей. Во-вторых, при фиксации частот возникает обсуждение, полезное для всех участников и выявляющее различия в образах пользователя, имеющихся у разных проектировщиков. В-третьих, явное присвоение частот содействуют пониманию того, какие решения какими свойствами группы пользователей обусловлены. Даже такой неформальный анализ чувствительности приносит пользу. Когда обнаруживается, что очень важные решения зависят от некоторых специфических предположений, оказывается уместным получить более точные численные оценки. (Разработанная Джеффом Конклином (Jeff Conklin) система позволяет формально и точно прослеживать принятие проектных решений и документировать их основания. [4] Мне не приходилось ею пользоваться, но думаю, что она должна быть очень полезна.)
Глава 12. Острый инструмент
12.1 Менеджер проекта должен установить принципы и выделить ресурсы для разработки общеупотребляемых инструментов, в то же время он должен признать необходимость в персонализированных инструментах.
12.2 Бригадам, разрабатывающим операционные системы, необходима для отладки собственная целевая машина. Для нее требуется скорее максимум памяти, чем максимум скорости, и системный программист для поддержки стандартного программного обеспечения.
12.3 Машина для отладки или ее программное обеспечение должны иметь инструмент для автоматического подсчета и изменения всех видов параметров программы.
12.4 Потребность в целевой машине описывается специфической кривой: после низкой активности следует взрывной рост, который потом выравнивается.
12.5 Системной отладкой, как астрономией, всегда занимались преимущественно по ночам.
12.6 Вопреки теории, выделение времени целевой машины одной бригаде значительными блоками оказалось лучшим вариантом планирования времени, чем чередование использования машины бригадами.
12.7 Этот предпочтительный при нехватке компьютеров метод планирования времени пережил 20 лет (с 1975 года) технологических изменений, поскольку является наиболее продуктивным. (И остается им в 1995 году.)
12.8 Если целевой компьютер является новым, необходим его логический эмулятор. Его можно получить раньше, и он обеспечивает надежную машину для отладки даже после того, как поставляется настоящая машина.
12.9 Главную библиотеку программ нужно разделить на: 1) набор индивидуальных «игровых площадок», 2) подбиблиотеку системной интеграции, проходящую системное тестирование и 3) версию-релиз. Формальное разделение и перемещение обеспечивают контроль.
12.10 Инструмент, обеспечивающий наибольшую экономию труда в программном проекте, — это, наверное, система редактирования текстов.
12.11 Объемистость системной документации создает новый тип непостижимости (см., например Unix), но это значительно предпочтительнее, чем более распространенный крайний недостаток документации.
12.12 Создайте эмулятор производительности снаружи внутрь, сверху вниз. Начните работу с ним как можно раньше. Прислушайтесь к тому, что он вам скажет.
Языки высокого уровня
12.13 Только лень и инертность препятствуют повсеместному применению языков высокого уровня и интерактивного программирования. (Но сегодня они приняты повсеместно.)
12.14 Язык высокого уровня способствует не только увеличению производительности, но и отладке. Меньше ошибок и легче поиск.
12.15 Прежние возражения, связанные с функциональностью, размером и скоростью результирующей программы устарели благодаря развитию языков и технологии компиляции.
12.16 Сегодня единственный подходящий кандидат для системного программирования — PL/I. (Больше не соответствует действительности.)
Интерактивное программирование
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 Для программного продукта сторона, обращенная к пользователю, — документация — столь же важна, как и сторона, обращенная к машине.
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 Смоляная яма программной инженерии еще долгое время будет оставаться вязкой.
Я не знаю другого способа судить о будущем, как с помощью прошлого.
ПАТРИК ГЕНРИ
Опираясь на прошлое, невозможно планировать будущее.
ЭДМУНД БЕРК
Для чего понадобилось юбилейное двадцатое издание?
Самолет гудел в ночи, направляясь к Лагардии. Облака и сумрак скрыли все интересное для глаза. Документ, который я читал, был неинтересным. Однако мне не было скучно. Сидящий рядом попутчик читал «Мифический человеко-месяц», и я ожидал, когда словом или жестом он выдаст свое впечатление. В конце концов, когда мы уже выруливали к выходу, я не выдержал:
— Как вам эта книга? Советуете прочесть?
— Хм, в ней нет ничего, чего я не знал бы раньше.
Я решил не представляться.
Почему «Мифический человеко-месяц» выжил? Почему с ним до сих пор считаются в современной практике программирования? Почему его читательская аудитория выходит за пределы сообщества программистов-разработчиков, а книга порождает статьи, цитаты и письма не только разработчиков программ, но и юристов, врачей, психологов, социологов? Каким образом книга, написанная 20 лет назад об опыте разработки программ, имевшем место 30 лет назад, может до сих пор быть актуальной и даже полезной?
Согласно одному из объяснений, которые можно услышать, разработка программного обеспечения как дисциплина не получила нормального и правильного развития. В поддержку этой точки зрения часто указывают на несоответствие роста производительности труда программистов и эффективности производства компьютеров, выросшей в тысячи раз за последние два десятилетия. Как объясняется в главе 16, аномалия состоит не в замедленном развитии программирования, а в беспрецедентном в истории человечества взрыве компьютерных технологий. В целом, причина этого в постепенном переходе производства компьютеров из сборочного производства в обрабатывающее, из трудоемкого производства в капиталоемкое. Разработка же аппаратного и программного обеспечения, в отличие от производства, остается по своей сути трудоемкой.
Второе часто выдвигаемое объяснение гласит, что «Мифический человеко-месяц» лишь случайно касается разработки программного обеспечения, а в основном он написан о групповой разработке чего бы то ни было. Доля правды в этом есть. В предисловии к изданию 1975 года сказано, что управление программным проектом имеет больше сходства с любым другим управлением, чем изначально считается большинством программистов. Я до сих пор так считаю. История человечества — это пьеса, в которой сюжеты постоянны, сценарии медленно меняются с развитием культуры, а декорации меняются непрерывно. Поэтому в ХХ веке мы узнаем себя в Шекспире, Гомере и Библии. Поэтому в той мере, в какой «МЧ-М» написан о людях, он устаревает медленно.
Каковы бы ни были причины, книгу продолжают покупать и присылают мне замечания, которые я ценю. Меня часто спрашивают: «Как вы считаете, в чем вы тогда ошиблись? Что устарело в наши дни? Что действительно новое появилось в мире разработки программ?» Эти четкие вопросы вполне законны, и я постараюсь
ответить на них. Не в таком, правда, порядке, но по группам тем. Прежде всего, посмотрим, что было верным в момент написания и осталось таковым до сих пор.
Центральный аргумент: концептуальная целостность и архитектор
Концептуальная целостность. Чистый и элегантный программный продукт должен представить своим пользователям согласованную идеальную модель приложения, стратегий осуществления приложения и тактики пользовательских интерфейсов, используемой при задании действий и параметров. Концептуальная целостность продукта в восприятии пользователя является важнейшим фактором, влияющим на простоту использования. (Есть, конечно, и другие факторы. Важным примером является единообразие пользовательского интерфейса в приложениях для Macintosh. Более того, можно создать согласованные интерфейсы, являющиеся тем не менее, совершенно неуклюжими. Например MS-DOS.)
Есть многочисленные примеры элегантных программных продуктов, созданных одним или двумя людьми. Так делается большая часть чисто интеллектуальных продуктов, таких как книги или музыкальные произведения. Однако во многих промышленных областях процессы разработки продукта не могут осуществляться на основе столь простого подхода к концептуальной целостности. Конкуренция вынуждает к спешке. Во многих современных технологиях конечный продукт обладает большой сложностью, и проектирование неизбежно требует многих человеко-месяцев труда. Для программных продуктов характерны как сложность, так и напряженность графика, обусловленная конкуренцией.
Таким образом, всякий достаточно большой или срочный продукт, требующий усилий многих людей, сталкивается со специфической трудностью: результат должен концептуально согласовываться с разумом одиночного пользователя и в то же время проектироваться усилиями нескольких разумов. Как организовать проектирование, чтобы достичь такой концептуальной целостности? Это центральный вопрос «МЧ-М». Один из его тезисов гласит, что существуют качественные различия между управлением большими и маленькими программными проектами — лишь в силу числа работающих над ними голов. Для достижения согласованности необходимы обдуманные и даже героические действия.
Архитектор. С четвертой по шестую главу я доказываю, что самое важное — назначить одного человека архитектором продукта, ответственным за все его стороны, воспринимаемые пользователем. Архитектор формирует и имеет в своем владении общедоступную идеальную модель продукта, с помощью которой пользователю будет объяснено его применение. В ее состав входит подробное указание всех его функций и средств вызова и управления. Архитектор также действует в интересах пользователя при поиске компромисса между функциями, техническим характеристиками, размером, стоимостью и выполнением графика работ. Выполнение этой задачи требует полной занятости, и только в очень маленьких группах может быть совмещено с должностью руководителя. Архитектора можно сравнивать с режиссером, а менеджера — с продюсером кинокартины.
Отделение архитектуры от разработки и реализации. Чтобы сделать возможным осуществление архитектором своей главной задачи, необходимо отделить архитектуру, т.е. определение продукта в восприятии пользователя, от его разработки. Архитектура и разработка определяют четкую грань между разными частями задачи проектирования, и по каждую сторону этой грани лежит большая работа.
Рекурсивность архитектуры. В очень больших проектах одному человеку не справиться со всей архитектурой, даже если он избавлен от всех забот, связанных с разработкой. Поэтому главный архитектор системы должен разбить целое на подсистемы. Границы подсистем должны быть проведены так, чтобы интерфейсы между ними были минимальны и легче всего строго определяемы. Тогда у каждой части может быть свой архитектор, подчиняющийся главному архитектору системы в отношении архитектуры. Очевидно, при необходимости этот процесс может быть продолжен рекурсивно.
Сегодня я убежден более чем когда-либо. Концептуальная целостность является важнейшим условием качества продукта. Наличие системного архитектора есть важнейший шаг в направлении концептуальной целостности. Эти принципы ни в коей мере не ограничиваются разработкой программного обеспечения, а справедливы при проектировании любой сложной конструкции, будь то компьютер, самолет, стратегическая оборонная инициатива или система глобальной навигации. После преподавания в более чем 20 лабораториях разработки программного обеспечения я стал настаивать, чтобы группы учащихся, даже из четырех человек, выбирали менеджера и отдельно — архитектора. Разделение функций в таких маленьких группах может показаться несколько чрезмерным требованием, но, по моим наблюдениям, это оправдано и способствует достижению успеха.
Эффект второй системы: функциональность и угадывание частоты
Проектирование для больших групп пользователей. Одним из последствий революции, произведенной персональными компьютерами, является все возрастающее, по крайней мере в области обработки деловых данных, вытеснение заказных программ коробочными программными пакетами. Более того, стандартные программные пакеты продаются сотнями тысяч и даже миллионами экземпляров. Системные архитекторы программ, поставляемых вместе с машиной, всегда должны были создавать проект, ориентированный на большую аморфную массу пользователей, а не на отдельное определенное приложение в одной компании. Теперь такая задача встает перед очень многими архитекторами.
Парадокс состоит в том, что спроектировать инструмент общего назначения, нежели специализированный, гораздо труднее именно потому, что нужно придать вес различающимся потребностям разных пользователей.
В погоне за функциональностью. Архитектор инструмента общего назначения, такого, например, как электронная таблица или текстовый редактор, подвержен сильному соблазну перегрузить продукт функциями предельной полезности ценой снижения производительности и даже простоты использования. Вначале привлекательность предлагаемых возможностей кажется очевидной. Расплата производительностью становится очевидной лишь при системном тестировании. Утрата простоты использования коварно подкрадывается по мере того, как небольшими порциями добавляются новые функции, а руководства пользователя все более разбухают. [1]
Соблазн особенно велик в отношении долгоживущих массовых продуктов, развивавшихся на протяжении ряда поколений. Миллионы покупателей требуют сотен новых возможностей. Всякая просьба свидетельствует о наличии спроса на рынке. Часто архитектор первоначальной системы уже ушел в поход за новой славой, и архитектура оказалась в руках людей с меньшим опытом взвешенного представления общих интересов пользователей. В недавней рецензии на Microsoft Word 6.0 сказано: «Переполнен возможностями; обновление замедлено перегруженностью… Кроме того, Word 6.0 занимает много места и медленно работает.» С неудовольствием отмечается, что Word 6.0 занимает 4 Мбайт памяти и сообщается, что из-за богатых дополнительных функциональных возможностей «даже Macintosh IIfx едва пригоден для выполнения Word 6». [2]
Определение группы пользователей. Чем крупнее и аморфнее группа предполагаемых пользователей, тем более необходимо явно ее определить, если вы намерены достичь концептуальной целостности. У каждого члена группы проектировщиков наверняка есть неявный мысленный образ пользователя, и все образы будут отличаться друг от друга. Поскольку представление архитектора о пользователе явно или подсознательно оказывает влияние на все архитектурные решения, важно, чтобы команда проектировщиков пришла к единому общему образу. Для этого необходимо составить список признаков предполагаемых пользователей, указав в нем:
• кто они такие,
• что им нужно,
• что, по их мнению, им нужно,
• чего они хотят.
Частоты. Для любого программного продукта каждая характеристика пользователя представляет собой распределение со множеством возможных значений и соответствующими частотами. Как архитектору получить эти частоты? Изучение этой слабо очерченной популяции представляется сомнительным и дорогостоящим занятием. [3] С годами я пришел к убеждению, что архитектор должен угадать или, если вам больше нравится, постулировать полный набор признаков и значений вместе с частотами для создания полного, явного и общего для всех описания группы пользователей.
Такая непривлекательная процедура имеет ряд полезных последствий. Во-первых, при стремлении точно угадать частоты архитектор вынужден очень тщательно обдумать, какова возможная группа пользователей. Во-вторых, при фиксации частот возникает обсуждение, полезное для всех участников и выявляющее различия в образах пользователя, имеющихся у разных проектировщиков. В-третьих, явное присвоение частот содействуют пониманию того, какие решения какими свойствами группы пользователей обусловлены. Даже такой неформальный анализ чувствительности приносит пользу. Когда обнаруживается, что очень важные решения зависят от некоторых специфических предположений, оказывается уместным получить более точные численные оценки. (Разработанная Джеффом Конклином (Jeff Conklin) система позволяет формально и точно прослеживать принятие проектных решений и документировать их основания. [4] Мне не приходилось ею пользоваться, но думаю, что она должна быть очень полезна.)