Мифический человеко-месяц или как создаются программные системы

ОглавлениеДобавить в закладки К обложке

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

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

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

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

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

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

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

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

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

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

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

Третий шаг, объектно-ориентированное программирование, вводит важное понятие наследования, при котором классы (типы данных) по умолчанию имеют атрибуты своих предков в иерархии классов. [14] То, что мы рассчитываем получить от объектно-ориентированного программирования, происходит, в сущности, от первого шага, инкапсуляции модулей, плюс идея заранее подготовленных библиотек модулей или классов, спроектированных и протестированных с целью повторного использования. Многие предпочли проигнорировать тот факт, что такие модули не просто программы, а программные продукты в том смысле, который разъяснен в главе 1. Напрасно рассчитывать на успешное повторное использование модулей, не оплачивая начальные издержки на разработку качественных программных модулей: обобщенных, надежных, протестированных и документированных. Объектно-ориентированное программирование и повторное использование обсуждались в главах 16 и 17.

Насколько мифичен человеко-месяц? Модель и данные Бёма


-= 98 =-
Регистрация.
Забыли пароль?
Логин
Пароль
Запомнить меня