Фредерик Брукс - Мифический человеко-месяц или как создаются программные системы
11.16 Руководитель проекта должен стремиться к тому, чтобы его менеджеры и технический персонал были настолько взаимозаменяемы, насколько позволяют их способности. В частности, нужно иметь возможность легко переводить людей с технической на управленческую работу и обратно.
11.17 Препятствия к поддержанию эффективной организации с двойной служебной лестницей являются социологическими. Необходимо постоянно бдительно и энергично бороться с ними.
11.18 Легко установить соответствующие размеры жалованья для соответствующих ступенек двойной лестницы, но требуется принять меры, чтобы дать им соответствующий престиж: одинаковые офисы, одинаковые службы поддержки, в значительной мере компенсирующие управленческую деятельность.
11.19 Организация по типу операционной бригады позволяет активно решать все стороны этой проблемы. Это действительно долгосрочное решение проблемы гибкой организации.
Два шага вперед, шаг назад: сопровождение программ
11.20 Сопровождение программы в корне отличается от сопровождения аппаратной части; оно состоит, главным образом, из изменений, исправляющих конструктивные дефекты, включение дополнительных функций или адаптацию к изменениям среды использования или конфигурации.
11.21 Стоимость пожизненного сопровождения широко используемой программы обычно составляет 40 и более процентов стоимости ее разработки.
11.22 Стоимость сопровождения сильно зависит от числа пользователей: чем больше пользователей, тем больше ошибок они находят.
11.23 Кэмпбел отмечает интересную кривую взлета и падений обнаруживаемых ошибок в течение жизни продукта.
11.24 Исправление одной ошибки с большой вероятностью (от 20 до 50 процентов) вносит другую.
11.25 После каждого исправления нужно прогнать весь набор контрольных примеров, по которым система проверялась раньше, чтобы убедиться, что она каким-нибудь непонятным образом не повредилась.
11.26 Методы разработки программ, позволяющие исключить или по крайней мере выявить побочные эффекты, могут резко снизить стоимость сопровождения.
11.27 То же можно сказать о методах реализации проектов меньшим числом интерфейсов и меньшим количеством ошибок.
Шаг вперед, шаг назад: энтропия системы с течением времени растет
11.28 Леман и Белади считают, что общее количество модулей растет линейно с номером версии операционной системы (OS/360), но числи модулей, затронутых изменениями, растет экспоненциально в зависимости от номера версии.
11.29 Все исправления имеют тенденцию к разрушению структуры, увеличению энтропии и дезорганизации системы. Даже самое искусное сопровождение программы только отдаляет момент повержения ее в состояние неисправимого хаоса, выходом из которого является повторное проектирование с самого начала. (Иногда реальная необходимость обновления программы, например, с целью повышения производительности, вызывает необходимость изменения
внутренних границ структур. Часто исходные границы служат причиной выявляющихся впоследствии недостатков.)
Глава 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 Системную отладку нужно начинать, только убедившись в работоспособности компонентов, (в противоположность подходу «свинти и попробуй» и началу системной отладки при известных, но не устраненных ошибках в компонентах). (Это особенно справедливо для бригад.)
