Эта задача вовсе не безнадежна. Обычно человек использует около 10000 слов родного языка, образованные люди — значительно больше. Каким-то образом мы обучаемся синтаксису и тонким семантическим различиям. Мы правильно опеределяем различия между словами гигантский, огромный, пространный, колоссальный, громадный — никто не говорит о колоссальных пустынях и пространных слонах.

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

• Обучение происходит в контексте предложения, поэтому нужно публиковать многочисленные примеры составных продуктов, а не просто библиотеки составляющих частей.

• Человек запоминает только правописание. Синтаксис и семантика изучаются постепенно, в контексте, путем применения.

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

Чистый итог по пулям: положение прежнее

Итак, мы возвращаемся к основам. Сложность — это то, чем мы занимаемся, и сложность — это то, что нас ограничивает. Р. Л. Гласс (R. L. Glass) писал в 1988 году, точно суммируя мои взгляды 1995 года:

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

Некоторые считают это безрадостной картиной. Это те, кто полагал, что вот-вот наступит прорыв.

Но некоторые из нас — достаточно сварливые, чтобы считать себя реалистами, — относятся к этому как к глотку свежего воздуха. Наконец-то можно сосредоточиться на чем-то более близком к жизни, чем журавль в небе. Теперь, вероятно, мы сможем заняться постепенными усовершенствованиями производства программного обеспечения, которые действительно достижимы, а не ждать прорывов, которые вряд ли когда-либо произойдут. [29]

Сегодня о технике разработки программного обеспечения известно значительно больше, чем в 1975 году. Какие из утверждений, содержащихся в первом издании 1975 года, подтвердились опытом и данными? Какие были опровергнуты? Какие устарели в нашем изменчивом мире? Чтобы вам легче было судить, здесь, в виде сводки, приведены важнейшие утверждения книги 1975 года, которые я считал верными: факты и извлеченные из опыта практические правила, приведенные с сохранением изначального смысла. (Можно задаться вопросом: если это все, что было сказано в первоначальном издании, почему тогда это заняло так много места?) В скобках приведены свежие комментарии.

Большинство этих предложений можно проверить на практике. Излагая их в сжатой форме, я надеюсь сконцентрировать мысли читателя, измерения и комментарии.

Глава 1. Смоляная яма

1.1 Для создания системного программного продукта требуется примерно в девять раз больше усилий по сравнению с составляющими его программами, написанными отдельно для частного использования. По моей оценке, превращение программы в продукт вводит коэффициент, равный трем; проектирование, интеграция и тестирование компонентов, которые должны образовать согласованную систему, также вводит коэффициент, равный трем; все эти составляющие стоимости существенно независимы друг от друга.

1.2 Занятие программированием «отвечает глубокой внутренней потребности в творчестве и удовлетворяет чувственные потребности, которые есть у всех у нас», доставляя пять видов радости:

• Радость, получаемая при создании чего-либо своими руками.

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

• Очарование создания сложных головоломных объектов, состоящих из взаимодействующих движущихся частей.

• Радость, получаемая от неизменного узнавания нового, неповторяемости задачи.

• Удовольствие от работы со столь податливым материалом — чистой мыслью, который, тем не менее, существует, движется и работает так, как не могут словесные объекты.

1.3 В то же время этому занятию присущи и огорчения:

• При изучении программирования труднее всего привыкнуть к требованию совершенства.

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

• Страшно только на словах: фактическая власть приобретается как следствие успешного выполнения задач.

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

• Программному продукту грозит устаревание еще до его завершения. Настоящий тигр — не пара бумажному, если требуется реальное использование.

Глава 2. Мифический человеко-месяц

2.1 Программные проекты чаще проваливаются из-за нехватки календарного времени, чем по всем остальным причинам, вместе взятым.

2.2 Чтобы приготовить вкусную пищу, нужно время; некоторые задачи нельзя ускорить, не испортив результат.

2.3 Все программисты являются оптимистами: «Все будет хорошо».

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

2.5 Но сами наши идеи бывают ошибочными — отсюда и ошибки в программах.

2.6 Наши методы оценивания, основанные на учете затрат, смешивают затраты с полученным результатом. Человеко-месяц является ошибочным и опасным заблуждением, поскольку предполагает, что месяцы и количество людей можно менять местами.

2.7 Разделение задачи между несколькими людьми вызывает дополнительные затраты на обучение и обмен информацией.

2.8 Мое практическое правило: 1/3 времени — на проектирование, 1/6 — на написание программы, 1/4 — на тестирование компонентов и 1/4 — на системное тестирование.

2.9 Как научной дисциплине нам не хватает методов оценки.

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

2.11 Закон Брукса: если проект не укладывается в сроки, то добавление рабочей силы задержит его еще больше.

2.12 Добавление рабочей силы увеличивает общий объем затрат тремя путями: труд по перекраиванию задач и происходящее при этом нарушение работы, обучение новых людей, дополнительное общение.

Глава 3. Операционная бригада

3.1 Самые лучшие программисты-профессионалы в 10 раз продуктивнее слабых при равной подготовке и двухлетнем стаже (Сакман, Грант и Эриксон).

3.2 Данные Сакмана, Гранта и Эриксона не выявили корреляции между опытом и продуктивностью. Я думаю, что это всегда так.

3.3 Лучше всего иметь маленькую активную команду — как можно меньше мыслителей.

3.4 Часто лучше всего, если команда состоит из двух человек, один из которых является лидером. (Обратите внимание, как Богом задуман брак.)

3.5 Для создания действительно крупных систем маленькая активная команда работает слишком медленно.

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

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

Глава 4. Аристократия, демократия и системное проектирование