Аналогично, разработчики могут попробовать построить вертикальный срез продукта, в котором полностью реализован весьма ограниченный набор функций, чтобы заранее пролить свет на те места, где могут таиться опасности для производительности продукта. В чем состоит различие между сборкой на первой вехе в процедуре Microsoft и быстрым макетом? В функциях. Продукт с первой вехи может иметь такую ограниченную функциональность, что ни для кого не будет представлять интереса. Готовность продукта к поставке определяется завершенностью в предоставлении полезного набора функций и своим качеством, уверенностью в надежной работе.

Парнас был прав, а я — нет в отношении сокрытия информации

В главе 7 я противопоставляю две точки зрения на то, в какой мере каждый участник команды может иметь право или поощряться к знанию проектов и текстов программ, созданных коллегами. Во время проекта Operating System/360 мы решили, что все программисты должны видеть весь материал, т.е. у каждого программиста была рабочая тетрадь проекта, которая к концу насчитывала свыше 10000 страниц. Харлан Миллз убедительно доказывал, что «программирование должно быть открытым процессом», что предоставление всей работы на общее обозрение способствует контролю качества как благодаря давлению со стороны коллег, заставляющему работать хорошо, так и благодаря тому, что коллеги действительно находят промахи и ошибки.

Этот взгляд резко противоречит мнению Дэвида Парнаса о том, что программные модули должны быть инкапсулированы, с хорошо определенными интерфейсами, а внутренность таких модулей должна быть частной собственностью программиста, невидимой снаружи. Программисты эффективнее всего работают, будучи ограждены от внутренностей чужих модулей. [13]

В главе 7 я заклеймил идею Парнаса как «рецепт катастрофы». Парнас был прав, а я ошибался. Сегодня я убежден, что ограничение информации, часто осуществляемое теперь методами объектного программирования, является единственным способом поднять уровень программных разработок.

Используя другие методы, можно действительно попасть в беду. Согласно методике Миллза программисты могут получить подробности семантики интерфейсов, с которыми они работают, узнав, что находится «по ту сторону». Укрывание этой семантики может быть причиной системных ошибок. С другой стороны, методика Парнаса способствует устойчивости при внесении изменений и больше подходит к стратегии проектирования, предполагающей изменения в будущем.

В главе 16 утверждается следующее:

• большая часть роста производительности разработки программного обеспечения обеспечена устранением второстепенных трудностей, таких как неудобные языки программирования и медленная оборачиваемость пакетной обработки;

• легких решений в этом направлении практически не осталось;

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

Самое очевидное на этом пути — признать, что программы составляются из концептуальных блоков, значительно более крупных, чем отдельные операторы языков высокого уровня: подпрограмм, или модулей, или классов. Если мы сумеем ограничить проектирование и построение программ задачей соединения вместе и параметризации таких блоков из ранее созданных наборов, то радикально повысим концептуальный уровень и избавимся от огромного объема работ и широких возможностей для ошибок, существующих на уровне отдельных операторов.