Глава 12 Острый инструмент

Глава 12 Острый инструмент

Хорошего работника узнают по инструменту.

ПОСЛОВИЦА

Даже в наше время многие программные проекты, с точки зрения использования инструментария, работают как механические мастерские. У каждого механика есть свой набор инструментов, собиравшийся в течение всей жизни, который он тщательно запирает и охраняет — наглядное свидетельство личного мастерства. Точно также программист собирает маленькие редакторы, сортировки, двоичные дампы, утилиты для работы с дисками и припрятывает их в своих файлах.

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

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

Таким образом, менеджер проекта должен установить принципы и выделить ресурсы для разработки общих инструментов. В то же время он должен понимать необходимость в специализированных инструментах и не препятствовать разработке собственных инструментов в подчиненных рабочих группах. Есть опасный соблазн попытаться достичь большей эффективности, собрав вместе отдельных разработчиков инструмента и доработав общегрупповой инструментарий. Но это не удается.

Что это за инструменты, разработку которых менеджер должен обдумывать, планировать и организовывать? Прежде всего, вычислительные средства. Для этого требуются машины, и должна быть принята политика планирования времени. Для этого требуется операционная система, и должна быть установлена политика обслуживания. Для этого требуется язык, и должна быть заложена политика в отношении языка. Затем идут утилиты, средства отладки, генераторы контрольных примеров и текстовый процессор для работы с документацией. Рассмотрим их поочередно.[1]

Целевые машины

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

Каковы типы целевых средств? Если бригада создает новый супервизор или другое программное средство, составляющее сердцевину системы, то ей, конечно, нужна своя машина. Для таких систем потребуются операторы и один или два системных программиста, чтобы машина была в рабочем состоянии.

Если требуется отдельная машина, то она должна быть довольно специфической: не требуется, чтобы она была быстрой, но требуется, по меньшей мере, 1 Мбайт

оперативной памяти, 100 Мбайт в активных дисках и терминалы. Достаточно символьных терминалов, но со значительно большей скоростью, чем 15 символов в секунду, характерных для пишущих машинок. Наличие большой памяти значительно способствует продуктивности, позволяя заняться разбиением на оверлеи и минимизацией размера после тестирования функций.

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

Планирование времени. Если целевая машина новая, — например, для нее создается первая операционная система, — то машинного времени мало, и планирование становится большой проблемой. Потребности в рабочем времени целевой машины имеет специфическую кривую роста. При разработке OS/360 у нас были хорошие эмуляторы System/360 и другие машины. По прежнему опыту мы оценили, сколько часов рабочего времени S/360 нам понадобится, и стали получать первые машины с производства. Но месяц за месяцем они оставались без нагрузки. Затем сразу все 16 систем оказались загруженными, и распределение времени стало проблемой. Использование машин выглядело примерно как на рисунке 12.1. Все одновременно начали отлаживать первые компоненты, и затем все команды постоянно что-то отлаживали.

Рис. 12.1 Рост использования целевых машин

Мы централизовали все свои машины и библиотеки магнитных лент и организовали для их работы профессиональную и опытную группу машинного зала. Для максимизации бывшего в недостатке машинного времени S/360 все отладочные прогоны мы осуществляли в пакетном режиме на подходящих свободных машинах. Мы добились четырех запусков в день (оборачиваемость составила два с половиной часа), а требовалась четырехчасовая оборачиваемость. Вспомогательная машина 1401 с терминалами использовалась для планирования прогонов, отслеживания тысяч заданий и контроля времени оборачиваемости.

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

Это оказалось более удачным способом планирования. Хотя коэффициент использования машины, возможно, несколько упал (а часто и этого не было), производительность поднялась. Для каждого члена команды десять запусков в течение шести часов значительно продуктивнее, чем десять запусков, осуществленных с перерывами в три часа, поскольку постоянная концентрация сокращает время обдумывания. После такой гонки команде обычно требовалось один-два дня, чтобы подогнать работу с документами, прежде чем просить о выделении нового блока. Зачастую всего три программиста могут с пользой поделить и распределить между собой выделенный им блок времени. Похоже, что это лучший способ использования целевой машины при отладке новой операционной системы.

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

Рабочие машины и службы данных

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

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

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

Этот опыт, однако, сослужил плохую службу при программировании новой машины. Лабораторные разработки, предварительные или ранние выпуски компьютеров не работают должным образом, не работают надежно и не остаются неизменными день ото дня. По мере обнаружения ошибок технические изменения производятся во всех экземплярах машины, включая используемый группой программистов. Такая неустойчивость основания достаточно неприятна. Отказы аппаратуры, обычно скачкообразные, еще хуже. И хуже всего неопределенность, лишающая стимула старательно копаться в своем коде в поисках ошибки — ее может там вовсе не быть. Поэтому надежный эмулятор на зрелой машине остается полезным значительно дольше, чем можно было предположить.

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

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

Библиотеки программ и учет. Очень успешным и важным применением вспомогательной машины в программе разработки OS/360 была поддержка библиотек программ. Система, разработанная под руководством У. Р. Кроули (W. R. Crowley), состояла из двух соединенных вместе машин 7010 и общей дисковой базой данных. На 7010 поддерживался также ассемблер для S/360. В этой библиотеке хранился весь протестированный или находящийся в процессе тестирования код, как исходный, так и ассемблированные загрузочные модули. На практике библиотека была разбита на подбиблиотеки с различными правами доступа.

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

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

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

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

По моему мнению, это было одним из лучших решений в программе OS/360. Эта часть технологии управления была независимо разработана для нескольких крупных программных проектов, в том числе в Bell Labs, ICL и Кембриджском университете. [2] Она применима как к программам, так и к документации. Это — неоценимая технология.

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

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

Система документации. Из всех инструментов больше всего труда может сберечь компьютеризированная система редактирования текста, действующая на надежной машине. Наша система, разработанная Дж. У. Франклином (J. W. Franklin), была очень удобна. Я думаю, без нее руководства по OS/360 появились бы значительно позднее и оказались бы более запутанными. Есть люди, которые станут утверждать, что двухметровая полка руководств по OS/360 является следствием недержания речи, и сама ее объемистость являет собой новый тип непостижимости. И доля правды в этом есть.

Но у меня есть два возражения. Во-первых, хотя документация по OS/360 и ошеломляет размерами, план ее изучения тщательно изложен. Если использовать его избирательно, то чаще всего можно не обращать внимания на большую часть всей массы. Документацию по OS/360 нужно рассматривать как библиотеку или энциклопедию, а не материал для обязательного чтения.

Во-вторых, это гораздо лучше, чем крайняя недостаточность документации, характерная для большинства систем программирования. Я охотно соглашусь, тем не менее, что в некоторых местах текст можно было значительно улучшить, и результатом лучшего описания стал бы меньший объем. Некоторые части (например, «Концепции и средства») сейчас очень хорошо написаны.

Эмулятор производительности. Лучше его иметь. Разработайте его «снаружи внутрь», как описано в следующей главе. Используйте одинаковое проектирование сверху вниз для эмулятора производительности, эмулятора логики и самого продукта. Начните работу с ним как можно раньше. Прислушайтесь к тому, что он вам скажет.

Языки высокого уровня и интерактивное программирование

Сегодня два важнейших инструмента системного программирования — это те, которые не использовались при разработке OS/360 почти десятилетие назад. Они до сих пор не очень широко используются, но все указывает на их мощь и применимость. Это: а) языки высокого уровня и б) интерактивное программирование. Я убежден, что только инертность и лень препятствует повсеместному принятию этих инструментов, технические трудности более не являются извинениями.

Языки высокого уровня. Главные основания для использования языков высокого уровня — это производительность и скорость отладки. Производительность мы обсуждали раньше (глава 8). Имеющиеся данные, хотя и немногочисленные, указывают на многократный рост, а не на увеличение на несколько процентов.

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

Меня эти возможности производительности и отладки ошеломляют. Мне трудно представить себе систему программирования, которую я стал бы создавать на языке ассемблера.

Ну, а как с классическими возражениями против этого инструмента? Их три: я не могу сделать то, что хочу; результирующая программа слишком велика; результирующая программа слишком медленна.

Что касается возможностей, возражение, я думаю, больше не состоятельно. Все свидетельствует в пользу того, что можно делать то, что хочется, потрудившись найти способ, но иногда для этого приходится изловчиться. 3, [4]

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

Что касается скорости, то оптимизирующие компиляторы иногда порождают код, который зачастую выполняется быстрее, чем написанный вручную. Более того, проблемы скорости можно обычно решить, заменив от 1 до 5 процентов скомпилированной программы кодом, написанным вручную, после ее полной отладки. [5]

Какой язык высокого уровня следует использовать для системного программирования? Сегодня единственный достойный кандидат — PL/I. [6] У него очень полный набор операторов; он соответствует окружению операционной среды; имеется целый ряд компиляторов с разными особенностями — интерактивных, быстрых, с улучшенной диагностикой, с высокой степенью оптимизации. Лично я быстрее разрабатываю алгоритмы с помощью APL; затем я перевожу их в PL/I для соответствия системному окружению.

Интерактивное программирование. Одним из оправданий проекта МТИ MULTICS была его польза для создания систем программирования. MULTICS (и вслед за тем TSS IBM) концептуально отличается от других интерактивных компьютерных систем именно в тех отношениях, которые необходимы для системного программирования: многоуровневая система разделения доступа и защиты данных и программ, интенсивное управление библиотеками и средства для совместной работы пользователей терминалов. Я убежден, что во многих приложениях интерактивные системы никогда не заменят системы с обработкой пакетных заданий. Но я думаю, что создатели MULTICS привели самые убедительные доводы в ее пользу именно в применении к системному программированию.

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

Рис. 12.2 Сравнительная производительность при пакетном и диалоговом программировании

Помимо того, есть хорошие отзывы тех, кто разработал таким способом небольшие системы или части систем. Единственные доступные мне данные относительно влияния на программирование больших систем исходят от Джона Харра из Bell Labs. Они представлены на рисунке 12.2. Эти цифры охватывают написание, ассемблирование и отладку программ. Первая программа является, в основном, управляющей. Остальные три — языковые трансляторы, редакторы и т.п. Данные Харра позволяют предположить, что средства интерактивной работы, по крайней мере, удваивают производительности системного программирования. [8]

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

Данный текст является ознакомительным фрагментом.