Мифический человеко-месяц или как создаются программные системы
Шрифт:
15.10 Редко требуется блок-схема более чем на одну страницу — если она вообще нужна. (Стандарт MILSPEC здесь совершенно не прав.)
15.11 Что действительно необходимо — это структурный граф программы без соблюдения стандартов составления блок-схем ANSI.
15.12 Чтобы обеспечить обновление документации, важно включить ее в исходный текст программы, а не держать отдельным документом.
15.13 Для облегчения труда ведения документации есть три важных правила:
• Как можно больше используйте для документирования обязательные части программы, такие как имена
• Используйте свободное пространство и формат, чтобы показать отношения подчиненности, вложенности и улучшить читаемость.
• Вставляйте в программу необходимую текстовую документацию в виде параграфов комментариев, особенно в заголовках модулей.
15.14 В документации, которой будут пользоваться при модификации программы, объясняйте не только «как», но и «почему». Назначение является решающим для понимания. Даже языки высокого уровня совсем не передают значения.
15.15 Методы самодокументирующегося программирования наиболее полезны и мощны при использовании языков высокого уровня.
Эпилог к первому изданию
E.1 Программные системы являются, возможно, самыми сложными и запутанными (в смысле числа различных типов составляющих) созданиями человека.
E.2 Смоляная яма программной инженерии еще долгое время будет оставаться вязкой.
Глава 19 «Мифический человеко-месяц» двадцать лет
Я не знаю другого способа судить о будущем, как с помощью прошлого.
ПАТРИК ГЕНРИ
Опираясь на прошлое, невозможно планировать будущее.
ЭДМУНД БЕРК
Для чего понадобилось юбилейное двадцатое издание?
Самолет гудел в ночи, направляясь к Лагардии. Облака и сумрак скрыли все интересное для глаза. Документ, который я читал, был неинтересным. Однако мне не было скучно. Сидящий рядом попутчик читал «Мифический человеко-месяц», и я ожидал, когда словом или жестом он выдаст свое впечатление. В конце концов, когда мы уже выруливали к выходу, я не выдержал:
— Как вам эта книга? Советуете прочесть?
— Хм, в ней нет ничего, чего я не знал бы раньше.
Я решил не представляться.
Почему «Мифический человеко-месяц» выжил? Почему с ним до сих пор считаются в современной практике программирования? Почему его читательская аудитория выходит за пределы сообщества программистов-разработчиков, а книга порождает статьи, цитаты и письма не только разработчиков программ, но и юристов, врачей, психологов, социологов? Каким образом книга, написанная 20 лет назад об опыте разработки программ, имевшем место 30 лет назад, может до сих пор быть актуальной и даже полезной?
Согласно одному из объяснений, которые можно услышать, разработка программного обеспечения как дисциплина не получила нормального и правильного развития. В поддержку этой точки зрения часто указывают на несоответствие роста производительности труда программистов и эффективности производства компьютеров, выросшей в тысячи раз за последние два десятилетия. Как объясняется
Второе часто выдвигаемое объяснение гласит, что «Мифический человеко-месяц» лишь случайно касается разработки программного обеспечения, а в основном он написан о групповой разработке чего бы то ни было. Доля правды в этом есть. В предисловии к изданию 1975 года сказано, что управление программным проектом имеет больше сходства с любым другим управлением, чем изначально считается большинством программистов. Я до сих пор так считаю. История человечества — это пьеса, в которой сюжеты постоянны, сценарии медленно меняются с развитием культуры, а декорации меняются непрерывно. Поэтому в ХХ веке мы узнаем себя в Шекспире, Гомере и Библии. Поэтому в той мере, в какой «МЧ-М» написан о людях, он устаревает медленно.
Каковы бы ни были причины, книгу продолжают покупать и присылают мне замечания, которые я ценю. Меня часто спрашивают: «Как вы считаете, в чем вы тогда ошиблись? Что устарело в наши дни? Что действительно новое появилось в мире разработки программ?» Эти четкие вопросы вполне законны, и я постараюсь
ответить на них. Не в таком, правда, порядке, но по группам тем. Прежде всего, посмотрим, что было верным в момент написания и осталось таковым до сих пор.
Центральный аргумент: концептуальная целостность и архитектор
Концептуальная целостность. Чистый и элегантный программный продукт должен представить своим пользователям согласованную идеальную модель приложения, стратегий осуществления приложения и тактики пользовательских интерфейсов, используемой при задании действий и параметров. Концептуальная целостность продукта в восприятии пользователя является важнейшим фактором, влияющим на простоту использования. (Есть, конечно, и другие факторы. Важным примером является единообразие пользовательского интерфейса в приложениях для Macintosh. Более того, можно создать согласованные интерфейсы, являющиеся тем не менее, совершенно неуклюжими. Например MS-DOS.)
Есть многочисленные примеры элегантных программных продуктов, созданных одним или двумя людьми. Так делается большая часть чисто интеллектуальных продуктов, таких как книги или музыкальные произведения. Однако во многих промышленных областях процессы разработки продукта не могут осуществляться на основе столь простого подхода к концептуальной целостности. Конкуренция вынуждает к спешке. Во многих современных технологиях конечный продукт обладает большой сложностью, и проектирование неизбежно требует многих человеко-месяцев труда. Для программных продуктов характерны как сложность, так и напряженность графика, обусловленная конкуренцией.