, поскольку машинное времЯ теперь не  тратитсЯ  впустую, пока  человек
сидит и думает.
     ’ем   не  менее  интересные  экспериментальные   данные   ѓолда  (Gold)
показывают,  что во времЯ  первого диалога каждого сеанса достигаетсЯ  втрое
больший прогресс в интерактивной отладке, чем при последующих диалогах.8 ќто
убедительно говорит о том, что из-за отсутствиЯ планированиЯ мы не полностью
реализуем потенциал диалоговой работы. Џора стрЯхнуть пыль со старых методов
работы в интерактивном режиме.
     џ  считаю,  что  длЯ  правильного  использованиЯ  хорошей  терминальной
системы на каждые два часа работы за терминалом должно приходитьсЯ два  часа
работы за столом. Џоловина этого  времени уходит на подчистки после  первого
сеанса:  внесение изменений  в  журнал отладки, подшивку  новых  листингов в
системный журнал,  объЯснение  непонЯтных Явлений.  ‚тораЯ  часть  уходит на
подготовку:   планирование  изменений   и  усовершенствований  и  разработку
детальных  тестов  длЯ очередного  сеанса. Ѓез  такого  планированиЯ  трудно
поддерживать продуктивность на  протЯжении всех  двух  часов.  Ѓез подчистки
после  сеанса трудно  сделать  последовательность  сеансов  систематичной  и
продвигающей работу вперед.
     <b>Љонтрольные  примеры.</b>  —то  касаетсЯ  разработки  фактических  процедур
отладки  и  контрольных  примеров,  особенно  удачное  изложение  предлагает
ѓрюнбергер (Gruenberger),9 есть и более короткие описаниЯ в других известных
учебниках.10, 11
     ‘истемнаЯ отладка
     Ќеожиданно   трудным   этапом  созданиЯ   системы   программированиЯ
оказываетсЯ тестирование системы. џ уже обсуждал  некоторые причины как  его
трудности,  так и  непредсказуемости.  Њожно  не сомневатьсЯ  в  двух вещах:
системнаЯ отладка займет больше времени, чем предполагаетсЯ, а ее  сложность
оправдывает  досконально систематичный и плановый  подход.  ђассмотрим,  что
включает в себЯ такой подход.12
     <b>€спользуйте  отлаженные  компоненты.</b>  Ћбычный  здравый  смысл, если  не
обычнаЯ  практика, подсказывают, что системную отладку нужно начинать, когда
работает каждаЯ составлЯющаЯ часть.
     „алее  общепринЯтаЯ  практика следует  двумЯ  путЯми.  Џервый подход  -
"свинти и  попробуй".  ‚идимо,  он основываетсЯ  на том, что кроме ошибок  в
компонентах найдутсЯ  и ошибки  в системе (т.е. в  интерфейсах). —ем  скорее
части  будут соединены вместе, тем скорее  всплывут  системные ошибки. ‹егко
также представить,  что, используЯ компоненты  длЯ тестированиЯ друг  друга,
можно  в значительной мере избежать  созданиЯ  окружениЯ длЯ тестированиЯ. €
то,  и другое, очевидно, ЯвлЯетсЯ правдой, но,  как показывает опыт, не всей
правдой: значительно больше времени сберегаетсЯ  при тестировании системы  с
использованием чистых отлаженных  компонентов,  чем его тратитсЯ на создание
окружениЯ и доскональной проверки компонентов.
     Ќесколько  более  тонким ЯвлЯетсЯ подход "документированной ошибки". Ћн
означает,  что  компонент готов к использованию в системной проверке,  когда
все   его   ошибки   <i>найдены</i>,  но   необЯзательно  уже   исправлены.  ’огда,
теоретически,  при  системном  тестировании  возможные  эффекты этих  ошибок
известны  и  могут  быть  проигнорированы,  а сосредоточитьсЯ можно на новых
ЯвлениЯх.
     ‚се это означает принимать  желаемое  за действительное и происходит от
стремлениЯ объЯснить  провал  графика  работ.  Ќикто не знает всех возможных
последствий  известных   ошибок.  …сли   бы  все   было  просто,   системное
тестирование  не   вызывало  бы   затруднений.   Љроме   того,   исправление
документированных  ошибок, несомненно,  приведет к внесению новых  ошибок, и
системный тест окажетсЯ испорченным.
     <b>‘оздайте больше окружений.</b> Џод "окружением"  Я  понимаю все программы и
данные, созданные длЯ целей отладки, но не предназначенные длЯ использованиЯ
в  конечном продукте.  ‚ окружении  нет смысла иметь  и  половины того кода,
который входит в продукт.
     Ћдин из видов окружениЯ  -  <i>фиктивный компонент</i>, который может состоЯть
только  из  интерфейсов и, возможно, каких-нибудь  искусственных данных  или
небольших контрольных примеров. Ќапример, в  систему может входить программа
сортировки,  котораЯ  еще  не  закончена. ‘вЯзанные  с ней  компоненты можно
тестировать с помощью фиктивной программы, котораЯ просто читает и проверЯет
формат   входных  данных  и  возвращает  набор  правильно  отформатированных
бессмысленных, но упорЯдоченных данных.
     „ругой  вид   -  <i>мини-файл</i>.  ђаспространенным  видом  системной  ошибки
ЯвлЯетсЯ  неправильное  восприЯтие  форматов ленточных  и  дисковых  файлов.
Џоэтому стоит создать несколько маленьких файлов, содержащих лишь  несколько
типовых записей и все описаниЯ, указатели и т.п.
     Џредельный случай мини-файла  - фиктивный файл,  который фактически  не
существует.  џзык управлЯющих заданий  OS/360 имеет такое  средство,  и  оно
очень полезно длЯ отладки компонентов.
     „ругой вид окружениЯ - <i>вспомогательные программы</i>. ѓенераторы данных длЯ
тестированиЯ, печать специального анализа, анализаторы  таблиц  перекрестных
ссылок  -  все  это   примеры  специальных  приспособлений,  которые   может
потребоватьсЯ создать.13
     <b>Љонтролируйте   изменениЯ.</b>  †есткий  контроль   во  времЯ  тестированиЯ
ЯвлЯетсЯ  впечатлЯющим  методом  отладки аппаратуры, с успехом  применимым к
системам программированиЯ.
     Џрежде всего, кто-то  должен быть ответственным. Ћн, и только он должен
разрешать изменениЯ в компонентах и замену одной версии другой.
     „алее,  как  обсуждалось  выше,  система  должна  иметь  контролируемые
экземплЯры: один экземплЯр с последними версиЯми,  находЯщийсЯ под замком  и
используемый  длЯ  тестированиЯ  компонентов; один  тестируемый экземплЯр  с
установленными  исправлениЯми;  рабочие  экземплЯры  каждого  сотрудника длЯ
внесениЯ исправлений и дополнений в свои компоненты.
     ‚  технических моделЯх  System/360 среди  обычных желтых проводов можно
было  иногда видеть фиолетовые провода. Џри обнаружении дефекта делались две
вещи. Ѓыстро  придумывалось исправление и устанавливалось  в  системе, чтобы
продолжить отладку.  ќто  изменение делалось  фиолетовыми проводами, так что
оно торчало как бельмо на глазу. €зменение регистрировалось  в  журнале. ’ем
временем  готовилсЯ  официальный документ  о  внесении  исправлений, который
запускалсЯ  в  жернова   автоматизированного  проектированиЯ.  ‚  итоге  это
выливалось в измененные чертежи и списки проводов и  новую заднюю панель,  в
которой изменениЯ были  сделаны на печатной  плате  или  желтыми  проводами.
’еперь  физическаЯ  модель  и документациЯ  соответствовали  друг  другу,  и
фиолетовый провод исчезал.
     Џрограммированию тоже требуетсЯ технологиЯ фиолетовых проводов, и очень
требуетсЯ  жесткий  контроль и  глубокое уважение  к  документу,  который  в
конечном  счете,   окажетсЯ  продуктом.  Ќеотъемлемыми  составлЯющими  такой
технологии ЯвлЯютсЯ регистрациЯ всех изменений в журнале и  заметное отличие
в  исходном   коде  между  заплатками  на   скорую  руку  и  продуманными  и
документированными исправлениЯми.
     <b>„обавлЯйте  компоненты  по  одному.</b> ќтот  рецепт также очевиден, но  им
часто  пренебрегают из-за оптимизма и лени.  —тобы следовать  ему, требуютсЯ
фиктивные  программы и  разное  окружение, а  это  отнимает времЯ. € в конце
концов, всЯ эта работа может оказатьсЯ лишней! Њожет быть, ошибок и нет!
     Ќет!  Џротивьтесь соблазну!  ќто то,  в чем  заключаетсЯ  систематичное
тестирование  системы.  Ќужно   предполагать,  что  ошибок  будет  много,  и
планировать упорЯдоченную процедуру избавлениЯ от них.
     “чтите, что нужно иметь полный  набор контрольных примеров длЯ проверки
частично  собранных  систем  после  добавлениЯ каждого  компонента.  Џрежние
примеры,  успешно   выполненные   на  последней   частичной  сборке,   нужно
перезапустить на новой, чтобы проверить, не ухудшилась ли система.
     <b>Љвантуйте  изменениЯ.</b>  Џо  мере  созреваниЯ  системы  времЯ от  времени
начинают  поЯвлЯтьсЯ разработчики  компонентов,  приносЯ свежие версии своих
изделий  -   более   быстрые,  меньшие   по  размеру,   более   полные   или
предположительно  содержащие  меньше  ошибок.  ‡амена работающего компонента
новой версией требует такой же систематической процедуры тестированиЯ, как и
добавление  нового  компонента,  хотЯ  и требует  меньше  времени, поскольку
обычно уже имеютсЯ более полные и эффективные контрольные примеры.
     ЉаждаЯ команда, создающаЯ новый компонент,  использует  новейшую версию
интегрированной системы  в качестве  среды  длЯ  отладки  своего компонента.
ЏроделаннаЯ работа будет отброшена назад, если эта среда изменитсЯ. Љонечно,
она  должна изменитьсЯ.  Ќо внесение изменений  нужно производить  квантами.
’огда  у  каждого пользователЯ  будут промежутки продуктивной  стабильности,
прерываемые  пакетным  обновлением  среды   тестированиЯ.  ќто   оказываетсЯ
значительно менее разрушительным, чем постоЯнные волнениЯ и дрожь.
     ‹еман и Ѓелади дают свидетельства  в пользу того,  что квант  изменений
должен быть либо  очень большим и  редким, либо  очень маленьким и частым.14
ЏоследнЯЯ  стратегиЯ, согласно их модели, больше  подвержена неустойчивости.
Њой опыт это подтверждает: Я никогда не рискну использовать ее на практике.
     Љвантовые   изменениЯ  хорошо  вписываютсЯ   в  технологию   фиолетовых
проводов.   ЃыстраЯ  заплатка   держитсЯ  до  следующей   регулЯрной  версии
компонента,   котораЯ   должна   содержать   исправление  в   отлаженном   и
документированном виде.

        ѓлава 14. Ќазревание катастрофы
     <i>Ќикто не любит приносЯщего дурные вести.
     ‘Ћ”ЋЉЂ
     Љак оказываетсЯ, что проект запаздывает на год?
     ... ‘начала запаздывает на один день.</i>
     Љогда слышишь о катастрофическом  отставании  проекта от  графика, то
представлЯетсЯ  рЯд  обрушившихсЯ на  него больших  бедствий. Ћднако  обычно
причиной катастрофы  служат не  смерчи,  а термиты:  отставание  от  графика
происходит незаметно,  но неумолимо. Ќа  самом  деле, с крупными  бедствиЯми
справитьсЯ  легче:  используютсЯ   крупные  силы,   кореннаЯ  реорганизациЯ,
изобретаютсЯ новые подходы. ‚сЯ команда поднимаетсЯ на борьбу.
     Ћтставание, растущее  понемногу  изо  днЯ  в день, труднее  распознать,
труднее   предотвратить,  труднее  исправить.  ‚чера  не  удалось   провести
совещание из-за болезни  ключевого работника. ‘егоднЯ выключены  все машины,
потому что молниЯ ударила в силовой трансформатор. ‡автра не  удастсЯ начать
тестирование процедур работы с  дисками, поскольку поставка с завода первого
диска задерживаетсЯ на неделю.  ‘негопад, работа  в суде присЯжных, семейные
проблемы,  экстренные  встречи с  клиентами, проверки  руководством - список
бесконечен.  Љаждое  событие задерживает какую-нибудь  работу на  полднЯ или
день. € растет отставание от графика, каждый раз еще на один день.
     ‚ехи или помехи?
     Љак управлЯть большим проектом по жесткому графику? Џрежде всего, надо
<i>иметь</i>  график. “ каждого из событий,  называемых вехами, должна  быть  дата.
‚ыбор дат -  уже обсуждавшаЯсЯ задача оценки, и он решающим образом  зависит
от опыта.
     „лЯ выбора  всех вех есть только одно пригодное правило.  ‚ехами должны
служить  конкретные  особые событиЯ, которые можно идентифицировать с полной
определенностью. ‚ качестве отрицательных  примеров  отметим,  что написание
программы  "закончено на 90  процентов"  в  течение  половины всего  времени
кодированиЯ. Ћтладка "закончена на 99 процентов" почти всегда. "Џланирование
завершено" - событие, которое можно объЯвить почти произвольно.1
     Ќапротив,  вехи должны  быть 100-процентными  событиЯми.  "‘пецификации
подписаны  архитекторами  и  разработчиками", "исходный  код  готов  на  100
процентов, отперфорирован и  загружен  в библиотеку  на диске",  "отлаженнаЯ
версиЯ прошла все контрольные примеры". ’акие конкретные вехи разграничивают
расплывчатые этапы планированиЯ, кодированиЯ и отладки.
     Ќаличие  четко  очерченных  границ   и  недвусмысленность  важнее,  чем
возможность легкой  проверки начальником.  …два ли  человек  станет лгать  о
прохождении  вехи, <i>если</i>  она  очерчена столь  Ясно,  что  от не  может  себЯ
обманывать. Ђ вот если веха расплывчата, начальник часто воспринимает доклад
иначе, чем тот, кто ему докладывает. „ополнЯЯ ‘офокла, скажем,  что никто не
любит и  сам  приносить  дурные вести,  поэтому  они  смЯгчаютсЯ  без  злого
намерениЯ ввести в заблуждение.
     „ва интересных исследованиЯ поведениЯ правительственных  подрЯдчиков по
проведению оценок в крупномасштабных исследовательских проектах показали:
     1.   Ћценки   продолжительности   работы,   тщательно   проведенные   и
пересматриваемые каждые две недели перед началом  работы, не сильно менЯютсЯ
по мере  приближениЯ начала  работы, какими бы  неверными они ни оказались в
конечном итоге.
     2.   Џосле   начала  работы  <i>завышенные</i>  изначально   оценки  постоЯнно
уменьшаютсЯ по мере продвижениЯ.
     3.  <i>‡аниженные</i> оценки существенно не менЯютсЯ, пока до запланированного
срока окончаниЯ работ не остаетсЯ около трех недель.
     —етко  различимые вехи в  действительности  создают  удобство  команде,
котораЯ должна  рассчитывать,  что менеджер их хорошо  определит.  ‘  неЯсно
видимой  вехой  жизнь становитсЯ  труднее.  ќто  уже не  веха, а  мельничный
камень,  перетирающий  боевой  дух,  поскольку   она  вводит  в  заблуждение
относительно потерь времени, пока они не станут непоправимыми. Ђ хроническое
отставание от графика угнетающе действует на моральное состоЯние.
     "„ругаЯ часть тоже опаздывает"
     Ћтставание от графика на один день - ну и что? Љого волнует отставание
на  один  день?  Џозже нагоним. „ругаЯ часть,  в  которую входит наша,  тоже
отстает на один день.
     Њенеджер бейсбола считает <i>энергию</i> важным талантом,  как  длЯ выдающихсЯ
игроков,  так и  длЯ выдающихсЯ команд. ќто способность  бегать быстрее, чем
необходимо, передвигатьсЯ  скорее, чем необходимо,  старатьсЯ  сильнее,  чем
необходимо.  ќнергиЯ  важна  и  длЯ  выдающихсЯ  команд  программистов.  Ћна
обеспечивает упругость, резервную мощность, позволЯющие команде справитьсЯ с
повседневными  неприЯтностЯми, предвосхищать  мелкие беды  и  уберегатьсЯ от
них.  ђассчитаннаЯ  реакциЯ, размеренные усилиЯ  охлаждают  энергию.  Љак мы
видели, <i>нужно</i> приходить в возбуждение из-за отставаниЯ на один день, ибо они
ЯвлЯютсЯ составлЯющими катастрофы.
     Ќо  не  все  отставаниЯ  на один день одинаково катастрофичны.  Џоэтому
необходимо рассчитывать реакцию, хотЯ это и ослаблЯет  энергию. Љак отличить
отставаниЯ, которые  существенны?  Ќичем нельзЯ заменить  диаграммы Џ…ђ’ или
метод критического  пути. ’акаЯ  сеть  показывает, кто находитсЯ в  ожидании
каких событий. Ћна показывает, кто находитсЯ на критическом пути, на котором
любое отставание влечет перенос даты окончаниЯ. Ћна также показывает,  какое
предельное отставание возможно длЯ некоторой работы, прежде чем оно приведет
на критический путь.
     ’ехнологиЯ  Џ…ђ’,  строго  говорЯ,  есть  разработка  графика  работ  с
критическим  путЯми,  когда  длЯ  каждого  событиЯ  производЯтсЯ три оценки,
соответствующие разным  вероЯтностЯм уложитьсЯ в установленные сроки.  џ  не
думаю,  что такое уточнение  стоит  затрачиваемых усилий,  но  длЯ краткости
всЯкую сеть с критическим путЯми буду называть диаграммой Џ…ђ’.
     Џодготовка  диаграмм  Џ…ђ’  есть  самаЯ  ценнаЯ  часть  ее  применениЯ.
Ћпределение топологии сети, указание зависимостей в ней  и оценивание  путей
заставлЯют выполнить  большой объем очень  конкретного планированиЯ на самых
ранних  стадиЯх  проекта. ЏерваЯ  диаграмма всегда  ужасна,  и  длЯ созданиЯ
второй приходитсЯ проЯвить много изобретательности.
     ‚о времЯ выполнениЯ проекта диаграмма Џ…ђ’ дает ответ на деморализующие
извинениЯ  типа  "другаЯ часть  тоже  запаздывает".  Ћна  показывает,  когда
необходимо  развить энергию, чтобы увести свою  часть работы с  критического
пути, и подсказывает способы наверстать потерЯнное времЯ в других частЯх.
     Џод ковром
     Љогда  менеджер  низового  звена  видит,  что  его маленькаЯ  команда
отстает, он не склонен бежать к начальнику со своим горем. ‚озможно, команда
сумеет   наверстать   времЯ,  либо  он  сможет  что-нибудь   придумать   или
реорганизовать длЯ решениЯ проблемы. ‡ачем же беспокоить этим начальника? „о
поры  до времени  это  допустимо. „лЯ того и существуют  менеджеры  низового
звена,  чтобы решать такие проблемы. Ђ у начальника достаточно других забот,
требующих  его  вмешательства,  чтобы   искать  новые.  ’ак  всЯ  эта  грЯзь
заметаетсЯ под ковер.
     Ќо каждому начальнику нужны два вида данных: информациЯ о срывах плана,
котораЯ требует вмешательства, и картина состоЯниЯ дел, чтобы быть в курсе.3
‘ этой целью он должен знать положение дел во всех своих  командах. Џолучить
правдивую картину нелегко.
     ‚  этом месте интересы менеджера низового звена и начальника вступают в
противоречие. Њенеджер низового звена боитсЯ, что если он доложит начальнику
о  возникшей у  него проблеме, тот  возьметсЯ  за нее сам. …го вмешательство
отнимет у менеджера  его функции,  уменьшит его власть и нарушит другие  его
планы.  Џоэтому, пока менеджер считает, что может сам решить проблему, он не
докладывает о ней начальнику.
     “ начальника есть два  способа заглЯнуть под коврик. €спользовать нужно
оба. Џервый - уменьшить конфликт ролей и  стимулировать открытие информации.
‚торой - сдернуть коврик.
     <b>“меньшение конфликта ролей.</b> ‚ первую очередь  начальник должен провести
различие между  данными и действиЯх и  данными  о состоЯнии дел.  Ћн  должен
приучить себЯ <i>не вмешиватьсЯ</i> в проблемы, которые могут решить его менеджеры,
и <i>никогда  не  вмешиватьсЯ</i>  в  проблемы  непосредственно во  времЯ  изучениЯ
состоЯниЯ дел. џ знал одного начальника,  который  неизменно снимал трубку и
начинал давать указаниЯ, не дочитав до конца первый абзац отчета о состоЯнии
дел. Џри таких действиЯх вам обеспечено утаивание полных данных.
     Ќапротив, если менеджер знает, что его начальник  воспримет  отчет  без
паники или вмешательства, он будет давать честные оценки.
     ‚есь  этот  процесс  идет  успешно, если  начальник  подчеркивает,  что
совещаниЯ, заслушиваниЯ и конференции носЯт характер <i>изучениЯ состоЯниЯ дел</i>,
а  не  <i>принЯтиЯ мер  по проблемам</i>,  и  ведет  себЯ соответствующим  образом.
Ћчевидно,  можно  созвать   совещание  по  принЯтию   мер   по   результатам
заслушиваниЯ о  состоЯнии дел, если  возникает ощущение,  что проблема вышла
из-под  контролЯ. Ќо  тогда  по крайней  мере все  знают, что происходит,  и
начальник дважды подумает, прежде чем взЯть управление на себЯ.
     <b>‘дергивание  коврика.</b>  ’ем  не  менее  необходимо иметь  способ  узнать
истинное  положение дел независимо от наличиЯ  стремлениЯ к  сотрудничеству.
Ћсновой такого изучениЯ служит диаграмма Џ…ђ’ с часто расположенными вехами.
‚ большом проекте можно потребовать  еженедельного изучениЯ какой-либо части
ее, рассматриваЯ всю диаграмму раз в месЯц или около того.
     ѓлавным  документом  ЯвлЯетсЯ  отчет  с  указанием  вех  и  степени  их
фактического выполнениЯ. (Ќа рисунке 14.1 показан фрагмент  такого  отчета.)
Ћн  может показывать отставание  по некоторым позициЯм и служить  в качестве
повестки   днЯ  совещаниЯ.  ‚сем  известны  выносимые  на  него  вопросы,  и
соответствующие   менеджеры   готовы   доложить   о   причинах   отставаниЯ,
предполагаемых  сроках завершениЯ, принимаемых  мерах, а также  требуетсЯ ли
помощь от начальника или других групп, и если да, то какаЯ.
     ‚.  ‚ысоцкий  из   Bell  Telephone  Laboratories  добавлЯет   следующее
наблюдение:
     <i>„лЯ менЯ  оказалось удобным иметь в отчете  о состоЯнии дел две  даты -
"плановую"  и "оцениваемую". Џлановые  даты принадлежат менеджеру  проекта и
представлЯют  собой  последовательный  план  работы длЯ проекта  в  целом, a
priori  ЯвлЯющийсЯ  приемлемым.  Ћцениваемые   даты  принадлежат  менеджерам
низшего звена,  в переделах компетенции  которых  находЯтсЯ  рассматриваемые
участки, и представлЯют  их мнениЯ о сроке фактического  наступлениЯ событиЯ
при  имеющихсЯ у них ресурсах и получении входных данных (или обЯзательствах
об их поставке).  Њенеджер проекта должен осторожно относитьсЯ к оцениваемым
датам  и   стремитьсЯ  к   получению   точных,  неискаженных  оценок,  а  не
утешительно-оптимистичных или перестраховочно- консервативных  данных.  …сли
эта позициЯ утвердитсЯ в умах, то менеджер</i>

     <img src=mithsoftware_pic14_1.png>

     ђис. 14.1
     <i>проекта действительно сможет предвидеть, что он попадет в беду, если не
предпримет каких-нибудь мер.</i>4
     ‘оздание диаграммы Џ…ђ’ ЯвлЯетсЯ обЯзанностью  начальника и подотчетных
ему менеджеров. ‚несение в  нее изменений, пересмотр и подготовка отчетности
должны осуществлЯтьсЯ  небольшой (от одного до трех человек) группой, как бы
продолжающей начальника. ’акаЯ  группа <i>планированиЯ и контролЯ</i> неоценима при
работе над большим проектом. Ћна не обладает  иными полномочиЯми, кроме  как
требовать от менеджеров низового звена предоставлениЯ сведений  об установке
или изменении вех  и их достижении. Џоскольку группа планированиЯ и контролЯ
осуществлЯет всю  бумажную  часть работы,  нагрузка  на  менеджеров низового
звена ограничиваетсЯ самым важным - принЯтием решений.
     “  нас была умелаЯ, энергичнаЯ и  дипломатичнаЯ  группа планированиЯ  и
контролЯ, возглавлЯвшаЯсЯ Ђ. Њ. Џьетрасанта  (A. M. Pietrasanta), проЯвившим
значительные  изобретательные  способности  длЯ  разработки эффективных,  но
ненавЯзчивых методов контролЯ.  ‚ результате его группа пользовалась широким
уважением и хорошим отношением.  ќто немалое достижение  длЯ группы, котораЯ
по природе своей должна вызывать раздражение.
     ‚ыделение   небольшого  числа   подготовленных  работников   в   группу
планированиЯ и контролЯ приносит большую  отдачу.  „лЯ  успешного завершениЯ
проекта это значительно  лучше,  чем если бы они непосредственно  занимались
разработкой  программных продуктов, так как  группа  планированиЯ и контролЯ
стоит  на  страже   того,  чтобы  неощутимые  задержки  стали   видимыми,  и
сигнализирует  о  критических  положениЯх. ќто  система  раннего обнаружениЯ
потери года, происходЯщей день за днем.

        ѓлава 15. ЋбратнаЯ сторона
     <i>—его мы не понимаем, тем не владеем.
     ѓ…’…
     Ћ, дайте мне выступить комментатором,
     ‘кользЯщим по поверхности и будоражащим умы.
     ЉђЂЃЃ</i>
     омпьютернаЯ  программа  -  это  послание  человека   машине.   ‘трого
выстроенный  синтаксис  и  тщательные  определениЯ  нацелены  на  то,  чтобы
бездумной машине стали понЯтны намерениЯ человека.
     Ќо у  написанной  программы  есть обратнаЯ сторона:  она должна быть  в
состоЯнии рассказать  о  себе  пользователю-человеку. ќто требуетсЯ даже длЯ
программы, написанной  исключительно  длЯ собственных нужд, поскольку памЯть
может изменить автору-пользователю, и ему потребуетсЯ освежить детали своего
труда.
     Ќасколько  же  более  необходима  документациЯ  длЯ   программы  общего
пользованиЯ,  пользователь  которой  отдален  от  автора  во  времени,  и  в
пространстве! „лЯ программного продукта  сторона, обращеннаЯ к пользователю,
столь же важна, как и сторона, обращеннаЯ к машине.
     Њногие   из  нас  бранили  далекого   безымЯнного   автора   за  скудно
документированную программу. € многие поэтому пытались на всю жизнь  привить
молодым программистам уважение  к документации, преодолевающее лень  и пресс
графика работ. ‚ целом нам это не удалось. џ думаю, мы использовали неверные
методы.
     ’омас „ж. “отсон ‘тарший* (Thomas J. Watson, Sr.) рассказал мне историю
своего первого опыта в качестве продавца кассовых аппаратов в северной части
штата  Ќью-‰орк.  €сполненный  энтузиазма,  он  отправилсЯ в  путь  в  своем
фургоне, нагруженном кассовыми аппаратами. Ћн прилежно объехал свой участок,
но  ничего не продал. Ћбескураженный,  он  сообщил  об этом  своему хозЯину.
Џослушав   некоторое  времЯ,  управлЯющий   сказал:  "Џомоги  мне  загрузить
несколько  касс  в  фургон,  запрЯгай лошадь, и  поедем  снова."  ’ак  они и
сделали,  и  обходЯ  покупателей  одного за  другим,  старик <i>показывал</i>,  <i>как</i>
продавать кассовые аппараты. ‘удЯ по всему, урок пошел впрок.
     Ќесколько  лет  Я  старательно  читал  группам  инженеров-программистов
лекции о необходимости и желательности хорошей документации, увещеваЯ их все
с большим пылом и красноречием. ќто не подействовало. џ предположил, что они
понЯли,  как  правильно  составлЯть  документацию,  но  не делали  этого  по
недостатку рвениЯ. ’огда Я попробовал погрузить в повозку несколько кассовых
аппаратов, т.е. <i>показать</i> им, как делаетсЯ  эта работа. ќто имело значительно
больший успех.  Џоэтому  оставшаЯсЯ часть  этого повествованиЯ  посвЯщена не
столько поучениЯм, сколько объЯснению того, <i>как</i> делать хорошую документацию.
     ЉакаЯ документациЯ требуетсЯ?
     Ќеобходимы   различные   уровни   документации:  длЯ   пользователЯ,
обращающегосЯ  к  программе от  случаЯ к случаю, длЯ  пользователЯ,  который
существенно зависит от программы в своей работе, и длЯ пользователЯ, который
должен адаптировать программу к изменившемусЯ окружению или задачам.
     <b>—тобы использовать программу.</b> Љаждому пользователю  требуетсЯ словесное
описание программы. Џо большей части документациЯ страдает отсутствие общего
обзора. Ћписаны  деревьЯ, прокомментированы  кора  и листьЯ, но план  леса *
’омас  „ж.  “отсон  ‘тарший  -  основатель  компании  IBM  (<i>примеч.  перев.</i>)
отсутствует. —тобы написать полезное текстовое описание, взглЯните издалека,
а затем медленно приближайтесь:
     1. <i>Ќазначение</i>.  —то ЯвлЯетсЯ главной функцией программы и  причиной  ее
написаниЯ?
     2. <i>‘реда</i>. Ќа каких машинах,  аппаратных конфигурациЯх  и  конфигурациЯх
операционной системы будет она работать?
     3. <i>Ћбласть определениЯ и область значений.</i>  Љаковы  допустимые значениЯ
входных  данных?  Љакие  правильные  значениЯ  выходных   результатов  могут
поЯвитьсЯ?
     4.  <i>ђеализованные  функции  и  использованные алгоритмы.</i>  —то конкретно
может делать программа?
     5. <i>”орматы ввода-вывода</i>, точные и полные.
     6.  <i>€нструкциЯ по  работе,</i> в  том  числе описание вывода на  консоль  и
устройство вывода при нормальном и аварийном завершении.
     7. <i>Ћпции.</i> Љакой выбор предоставлЯетсЯ пользователю в отношении функций?
Љаким образом нужно его задавать?
     8.  <i>‚ремЯ  работы.</i> ‘колько  времени занимает решение  задачи  заданного
размера на заданной конфигурации?
     9. <i>’очность и проверка.</i> Љакова ожидаемаЯ  точность  результатов?  Љакие
имеютсЯ средства проверки точности?
     —асто все  эти данные можно изложить на трех или четырех страницах. Џри
этом нужно уделить особое внимание  полноте и точности.  Ѓольшую часть этого
документа нужно вчерне написать  до разработки  программы,  поскольку в  нем
воплощены основные плановые решениЯ.
     <b>—тобы доверЯть  программе.</b> Ћписание  того, как использовать  программу,
нужно дополнить описанием того,  как  убедитьсЯ  в ее работоспособности. ќто
означает наличие контрольных примеров.
     Љаждый  экземплЯр  поставлЯемой  программы должен  содержать  несколько
небольших контрольных примеров, которые можно постоЯнно использовать,  чтобы
уверить пользователЯ в том, что он может доверЯть программе, и она правильно
загружена в машину.
     Љроме того, нужны  более  тщательные  тесты, которые обычно выполнЯютсЯ
только  после модификации программы.  Ћни относЯтсЯ к  трем участкам области
входных данных:
     1. Ћсновные параметры,  проверЯющие главные функции программы на обычно
встречаемых данных.
     2.  Џримеры на грани допустимого,  проверЯющие  границы области входных
данных и убеждающие, что работают наибольшие значениЯ, наименьшие значениЯ и
все допустимые исключениЯ.
     3.  Џримеры  за  границей  допустимого, проверЯющие границы  с обратной
стороны  и  убеждающие,  что  недопустимые   значениЯ  вызывают   правильные
диагностические сообщениЯ.
     <b>—тобы модифицировать программу.</b> „лЯ адаптации или исправлениЯ программы
требуетсЯ значительно больше данных. ђазумеетсЯ, требуютсЯ все детали, а они
содержатсЯ   в   хорошо   прокомментированном  листинге.   “   пользователЯ,
модифицирующего  программу или  редко  ее  использующего,  возникает  остраЯ
необходимость в Ясном отчетливом обзоре, на этот раз внутренней структуры. ‚
такой обзор входЯт:
     1. Ѓлок-схема или граф подпрограммной  организации.  Џодробнее  об этом
см. ниже.
     2. Џолные описаниЯ используемых алгоритмов или ссылки на такие описаниЯ
в литературе.
     3. ђазъЯснение структуры всех используемых файлов.
     4. Ћбзор организации прохождениЯ данных - последовательности, в которой
данные или программы  загружаютсЯ  с ленты или диска  и описание  того,  что
делаетсЯ на каждом ходе.
     5. Ћбсуждение модификаций, предполагаемых исходным проектом, сущность и
расположение добавочных  блоков  и выходов  и дискурсивное обсуждение мыслей
автора   программы   относительно   изменений,   которые   могут   оказатьсЯ
желательными, и как их можно провести. Џолезно также изложить его  замечаниЯ
о скрытых ловушках.
     Ѓич блок-схем
     Ѓлок-схема чаще всего ЯвлЯетсЯ лишней частью программной документации.
„лЯ  многих программ блок-схемы  вообще не нужны. ђедкие  программы  требуют
блок- схемы более чем на одну страничку.
     Ѓлок-схемы  показывают  структуру   принЯтиЯ  программой  решений,  что
ЯвлЯетсЯ  лишь   одной  стороной   структуры  программы.  Љогда   блок-схема
размещаетсЯ  на  одной   странице,   структура   решений  выглЯдит  довольно
элегантно, но наглЯдность  сразу утрачиваетсЯ, когда есть несколько страниц,
свЯзанных пронумерованными входами и выходами.
     ЋдностраничнаЯ  блок-схема  длЯ  значительной   по  размеру   программы
становитсЯ, в сущности, диаграммой структуры программы и этапов или шагов. ‚
этом  качестве   она  очень  удобна.  ђисунок  15.1  показывает  такой  граф
подпрограммной структуры.

     <img src=mithsoftware_pic15_1.png>

     <b>ђис. 15.1</b> ѓраф структуры программы (пример W. V. Wright)
     Љонечно, такой структурный граф не требует  особых усилий по соблюдению
стандартов   ANSI   длЯ   блок-схем.  ‚се   эти  правила  относительно  вида
прЯмоугольников,  соединительных  линий,  нумерации и т.п. нужны  только длЯ
пониманиЯ подробных блок-схем.
     ЏодробнаЯ   пошаговаЯ   блок-схема   ЯвлЯетсЯ  досадным   анахронизмом,
пригодным  только  длЯ  новичков   в  алгоритмическом  мышлении.   ‚веденные
ѓолдштайном  и  фон  Ќейманом1 прЯмоугольники  вместе  со  своим  содержимым
служили Языком  высокого уровнЯ, объединЯЯ непостижимые операторы  машинного
Языка  в  осмысленные  группы. Љак давно  понЯл  €версон,2 в систематическом
Языке  высокого  уровнЯ группировка  уже проведена,  и каждый  прЯмоугольник
содержит  оператор   (рис.  15.2).  Џоэтому   сами  прЯмоугольники  ЯвлЯютсЯ
утомительным и отнимающим место  упражнением в черчении и  вполне могут быть
удалены. ’огда остаютсЯ только стрелки. ‘трелки, свЯзывающие один оператор с
другим, расположенным в следующей строке, излишни, и их можно удалить. ’огда
остаютсЯ  только   GO   TO,   и   если   придерживатьсЯ   хорошей   практики
программированиЯ  и использовать  блочные структуры длЯ минимизации числа GO
TO, таких стрелок  окажетсЯ немного, но  они  очень  способствуют пониманию.
‚полне можно нарисовать их на листинге и вовсе избавитьсЯ от блок-схемы.
     ‚ действительности о блок-схемах больше говорЯт, чем  пользуютсЯ ими. џ
никогда не видел опытного программиста, который  в повседневной деЯтельности
рисовал бы  подробные блок-схемы, прежде  чем  начать писать программу. ’ам,
где блок-схемы требуютсЯ правилами  организации, они почти всегда  создаютсЯ
задним  числом.  Њногие  гордЯтсЯ  использованием  специальных  программ длЯ
генерации  этого   "незаменимого  инструмента  разработки"   на  основе  уже
законченной программы. „умаю, что этот всеобщий опыт не ЯвлЯетсЯ постыдным и
предосудительным  отходом от хорошей практики программированиЯ, признаватьсЯ
в котором можно  лишь с нервным смешком.  Ќапротив,  это  результат здравого
рассуждениЯ, дающий нам урок относительно полезности блок-схем.
     Ђпостол Џетр сказал о новообращенных Язычниках и законе ЊоисеЯ: "—то же
вы  [желаете]  возложить  на выи учеников иго, которого не могли  понести ни
отцы  наши,  ни  мы?"  („еЯниЯ  апостолов  15:10).  ’о  же  сказал  бы  Я  о
программистах-новичках и устаревшей практике блок-схем.
     ‘амодокументирующиесЯ программы
     Ћдин  из  основных принципов  обработки данных  учит, что  безрассудно
старатьсЯ поддерживать  синхронность  независимых  файлов. ‡начительно лучше
собрать их в один файл, в котором каждаЯ запись содержит все данные их обоих
файлов, относЯщиесЯ к данному ключу.
     ’ем  не  менее  наша  практика документированиЯ  программ  противоречит
собственным  теориЯм.  Ћбычно  мы  пытаемсЯ  поддерживать программу  в виде,
пригодном длЯ ввода в машину, а независимый комплект документации, состоЯщей
из текста и блок-схем, - в виде, пригодном длЯ чтениЯ человеком.
     ђезультаты   этого   подтверждают   мысль  о   неразумности   поддержки
независимых файлов. ЏрограммнаЯ документациЯ получаетсЯ  удивительно плохой,
а ее сопровождение - и того хуже. ‚носимые в программу изменениЯ не получают
быстрого, точного и обЯзательного отражениЯ в документе.
     џ  полагаю,   что  правильным  решением  должно  быть  слиЯние  файлов:
включение  документации  в  исходный текст  программы.  ќто  одновременно  и
сильный побудительный мотив к  должному сопровождению,  и гарантиЯ того, что
документациЯ всегда будет под рукой у пользователЯ. ’акие программы называют
<i>самодокументирующимисЯ</i>.
     Ћчевидно, при этом неудобно, хотЯ и возможно, включать блок-схемы, если
в  этом есть необходимость.  Ќо,  принЯв во  внимание анахронизм блок-схем и
использование преимущественно Языков  высокого  уровнЯ, становитсЯ возможным
объединить программу с документацией.
     €спользование исходного кода программы в качестве носителЯ документации
влечет  некоторые  ограничениЯ. ‘  другой  стороны,  непосредственный доступ
читателЯ документации  к  каждой строке программы открывает возможность  длЯ
новых технологий. Џришло времЯ разработать радикально новые подходы и методы
составлениЯ программной документации.
     ‚ качестве важнейшей цели мы должны попытатьсЯ предельно уменьшить груз
документации - груз, с которым  ни  мы,  ни наши  предшественники толком  не
справились.
     <b>Џодход.</b>  Џервое предложение состоит  в  том,  чтобы разделы  программы,
обЯзанные присутствовать в ней согласно требованиЯм  Языка программированиЯ,
содержали как  можно больше документации. ‘оответственно,  метки,  операторы
объЯвлениЯ и  символические имена включают  в  задачу  передать читателю как
можно больше смысла.

     <img src=mithsoftware_pic15_2.png>

     <b>ђис. 15.2</b>  ‘равнение блок-схемы  и  соответствующей  программы  на PL/I
(фрагмент)
     ‚торое предложение -  в максимальной мере использовать  пространство  и
формат,  чтобы улучшить  читаемость  и  показать  отношениЯ подчиненности  и
вложенности.
     ’ретье   предложение  -  включить  в  программу  необходимую  текстовую
документацию  в   виде  параграфов   комментариев.  ‚  большинстве  программ
достаточно  иметь построчные комментарии.  ‚ программах,  отвечающих жестким
стандартам  организаций  на  "хорошее  документирование",  их  часто слишком
много.  Ћднако  даже  в  этих  программах   обычно  недостаточно  параграфов
комментариев,  которые действительно  способствуют понЯтности и  обозримости
целого.
     Џоскольку   документациЯ   встраиваетсЯ   в   используемые   программой
структуру,  имена  и  форматы,  значительную  часть этой  работы  <i>необходимо</i>
проделать,  когда программу только начинают писать. Ќо именно  тогда и <i>нужно</i>
писать  документацию.  Џоскольку   подход  на  основе   самодокументированиЯ
сокращает дополнительную работу, меньше препЯтствий к его осуществлению.
     <b>Ќекоторые   приемы.</b>  Ќа  рисунке  15.3  показана  самодокументирующаЯсЯ
программа на Языке PL/I.3 —исла в кружочках не ЯвлЯютсЯ ее  частью, а служат
метадокументацией длЯ ссылок при обсуждении.
     1. €спользуйте длЯ каждого запуска свое  имЯ заданиЯ и ведите журнал, в
котором учитывайте предмет проверки, времЯ и полученные результаты. …сли имЯ
состоит из мнемоники (здесь  QLT) и числового суффикса (здесь 4), то суффикс
можно использовать в качестве  номера запуска, свЯзывающего запись в журнале
и листинг. Џри этом длЯ разных прогонов требуютсЯ свои карты заданиЯ, но  их
можно делать колодами с дублированием постоЯнных данных.
     2.   €спользуйте   мнемонические    названиЯ    программы,   включающие
идентификатор версии  - в предположении, что будет несколько  версий.  ‡десь
индекс - две младшие цифры года.
     3. ‚ключите текстовое описание в качестве комментариев к PROCEDURE.
     4.  „лЯ   документированиЯ  алгоритмов  ссылайтесь,   где   можно,   на
литературу. ќто  экономит  место,  адресует к более полному  освещению,  чем
можно  дать  в  программе,  и дает возможность знающему читателю  пропустить
ссылку, оставлЯЯ уверенность, что он вас поймет.
     5. Џокажите  свЯзь  с алгоритмом, описанным  в книге:  а) изменениЯ; б)
особенности использованиЯ; в) представление данных.
     6.   ЋбъЯвите   все  переменные.  €спользуйте  мнемонику.   €спользуйте
комментарии  длЯ  превращениЯ   оператора  DECLARE  в  полноценную  легенду.
Ћбратите внимание, что он уже содержит имена и описаниЯ структур, нужно лишь
дополнить  его  описаниЯми   <i>назначениЯ</i>.  ‘делав   это  здесь,  вы  избежите
отдельного повторениЯ имен и структурных описаний.
     7. Џоставьте метку в начале инициализации.
     8.   Џоставьте   метки   перед  группами   операторов,  соответствующие
операторам алгоритма, описанного в книге.
     9. €спользуйте отступы длЯ показа структуры и группированиЯ.
     10.  ‚ручную  поставьте  стрелки,   показывающие   логический   порЯдок
операторов. Ћни  очень  полезны  при отладке и внесении изменений. €х  можно
поместить на правом поле места длЯ комментариев и сделать частью вводимого в
машину текста.
     11. ‚ставьте строчные комментарии длЯ  поЯснениЯ всего, что неочевидно.
Џри   использовании  изложенных   выше  приемов  они   окажутсЯ   короче   и
малочисленней, чем обычно.
     12. Џомещайте несколько операторов на одной строке или один оператор на
нескольких строках в соответствии с  логической группировкой,  а также чтобы
показать свЯзь с описанием алгоритма.
     <b>‚озражениЯ.</b>  Љаковы недостатки такого подхода  к  документированию? Ћни
существуют, и  в прежние времена  были  существенными, но сейчас  становЯтсЯ
мнимыми.

     <img src=mithsoftware_pic15_3.png>

     <b>ђис. 15.3</b> ‘амодокументирующаЯсЯ программа
     ‘амым  серьезным  возражением  ЯвлЯетсЯ  увеличение  размера  исходного
текста,  который  нужно хранить. Џоскольку  практика  все  более тЯготеет  к
хранению  исходного  кода  в  активных  устройствах, это  вызывает  растущее
беспокойство.  ‹ично Я  пишу более краткие комментарии в программах  на APL,
которые  хранЯтсЯ  на диске, чем в  программах на  PL/I, которые хранЯтсЯ на
перфокартах.
     Ћднако  одновременно  мы движемсЯ  к  хранению  в  активных устройствах
текстовых документов, доступ к которым  и изменение осуществлЯетсЯ с помощью
компьютеризированных  текстовых  редакторов.  Љак  указывалось выше, слиЯние
текста и программы <i>сокращает</i> общее количество хранимых символов.
     Ђналогичное  возражение  вызывает аргумент,  что  самодокументирующиесЯ
программы требуют больше ввода с клавиатуры. ‚ печатном документе требуетсЯ,
по  меньшей  мере,  одно  нажатие  на клавишу длЯ  каждого символа на каждый
черновой экземплЯр.  ‚ самодокументирующейсЯ программе суммарное  количество
символов меньше, и на один символ приходитсЯ меньше нажатий на клавиши,  так
как черновики не перепечатываютсЯ.
     Ђ что  же  блок-схемы и структурные  графы?  …сли  используетсЯ  только
структурный граф  самого  высокого  уровнЯ, он вполне  может  содержатьсЯ  в
отдельном  документе, поскольку  редко подвергаетсЯ  изменениЯм. Ќо конечно,
его  можно включить в исходный  текст программы в качестве комментариЯ,  что
будет благоразумно.
     ‚ какой мере описанные  выше приемы применимы  длЯ  программ  на  Языке
ассемблера? џ думаю,  что  базовый подход документированиЯ  применим  всюду.
‘вободным пространством и форматами  можно пользоватьсЯ с  меньшей  степенью
свободы,  и поэтому  они  используютсЯ не  так  гибко.  €мена  и  объЯвлениЯ
структур,  несомненно,  можно  использовать.  Ћчень  могут  помочь  макросы.
€нтенсивное использование параграфов комментарием ЯвлЯетсЯ хорошей практикой
в любом Языке.
     Ќо  подход  на  основе  самодокументированиЯ  стимулирован  применением
Языков высокого уровнЯ  и обретает наибольшую мощь и наивысшее  оправдание в
Язык