Мифический человеко-месяц или как создаются программные системы
Шрифт:
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 Я считаю, что для правильного использования хорошей системы (интерактивной отладки с быстрой реакцией) на каждые два часа работы за столом должно приходиться два часа работы на машине: один час — на подчистки и документирование после первого сеанса, и один час — на планирование изменений и тестов очередного сеанса.