Роббинс Д. - Отладка приложений для Microsoft .NET и Microsoft Windows - 2004

ГЛАВА 1 Ошибки в программах: откуда они берутся и как с ними бороться?	21

Шаг 4. Разделяй и властвуй

Если вы воспроизвели ошибку и хорошо описали ее, у вас есть предположения о ее природе и месте, где она прячется. На этом этапе вы начинаете приводить в порядок и проверять свои предположения. Важно помнить фразу: «Обратись к исходнику, Люк!»3 . Отвлекитесь от компьютера, прочтите исходный текст и по думайте, что происходит при работе программы. Чтение исходного текста заста вит вас потратить больше времени на анализ проблемы. Взяв за исходную точку состояние машины на момент аварийного завершения или появления проблемы, проанализируйте различные сценарии, которые могли привести к этой части кода. Если ваше предположение о том, что не так работает, не приводит к успеху, оста новитесь и переоцените ситуацию. Вы уже знаете об ошибке немного больше — теперь вы можете переоценить свое предположение и попробовать снова.

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

Шаг 5. Мысли творчески

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

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

В нескольких компаниях, в которых я работал, прерыванием наивысшего при оритета было нечто называемое «разговор об ошибке». Это означает, что вы со

3«Use the source, Luke!» — популярный у программистов каламбур, получившийся из фразы героя «Звездных войн» Оби Ван Кеноби «Use the force, Luke!» («Применяй силу, Люк»). Используется, когда хотят привлечь внимание к исходному тексту, вместо того чтобы искать ответ на вопрос в конференциях или у службы поддержки. В форумах и переписке чаще используют более экспрессивный, хоть и менее легитимный ко роткий вариант: RTFS (Read The Fucking Source). — Прим. перев.

22 ЧАСТЬ I Сущность отладки

вершенно выбиты из колеи и должны подробно обсудить ошибку с кем либо. Идея такова: вы идете в чей то кабинет и представляете свою проблему на доске. Сколько раз я приходил в чужой кабинет, открывал маркер, касался им доски и решал проблему, не проронив ни слова! Именно подготовка разума представить проблему помогает миновать дерево, в которое вы уперлись, и увидеть лес. Человека для разговора об ошибке вы должны выбрать не из числа коллег, с которыми вы тес но работаете над той же частью проекта. Таким образом, вы можете быть увере ны, что ваш собеседник не сделает тех же предположений о проблеме, что и вы.

Что интересно, этот «кто то» даже не обязательно должен быть человеком. Мои кошки, оказывается, — прекрасные отладчики, и они помогли мне найти множе ство мерзких ошибок. Я собирал их вместе, обрисовывал проблему на доске и давал сработать их сверхъестественным способностям. Конечно же, было трудновато объяснить происходящее почтальону, стоящему на пороге, учитывая, что в такие дни я не принимал душ и ходил в одних трусах.

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

Шаг 6. Усиль инструментарий

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

Некоторые компании, такие как Compuware и Rational, разрабатывают прекрас ные средства как для управляемого, так и для неуправляемого кода. Я всегда про пускаю свои тексты программ через эти средства, прежде чем приступить к труд ному этапу отладки. Так как ошибки неуправляемого кода всегда труднее найти, чем ошибки управляемого, эти средства гораздо важнее. Compuware NuMega пред лагает BoundsChecker (средство обнаружения ошибок), TrueTime (средство ана лиза производительности) и TrueCoverage (средство исследования кода програм мы). Rational предлагает Purify (обнаружение ошибок), Quantify (производитель ность) и PureCoverage (средство исследования кода). Суть в том, что, если вы не используете средства сторонних производителей для облегчения отладки своих проектов, вы тратите на отладку больше времени, чем необходимо.

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

ГЛАВА 1 Ошибки в программах: откуда они берутся и как с ними бороться?	23

Шаг 7. Начни интенсивную отладку

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

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

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

Если вы правильно планируете проект, проводите отладку по шагам, описан ным выше, и следуйте рекомендациям главы 2 — будем надеяться, вы не потрати те много времени на интенсивную отладку.

Шаг 8. Проверь, что ошибка устранена

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

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

24 ЧАСТЬ I Сущность отладки

Отладка: фронтовые очерки

Куда девалась интеграция?

Боевые действия

Один из программистов, с которым я работал в NuMega, думал, что нашел серьезную ошибку в интеграции Visual C++ Integrated Development Environ ment (VC IDE) компании NuMega, так как она не работала на его машине. Для тех из вас, кто не знаком с VC IDE от NuMega, я немного расскажу о ней. Интеграция программных продуктов от NuMega с VC IDE существует уже много лет. Такая интеграция позволяет появляться окнам, панелям инстру ментов и меню от NuMega непосредственно в среде VC IDE.

Исход

Этот программист потратил несколько часов, используя отладчик ядра Soft ICE для поиска ошибки. Он установил точки останова практически по всей ОС. Наконец он нашел свою «ошибку». Он заметил, что при запуске VC IDE CreateProcess вызывается с указанием пути \\R2D2\VSCommon\MSDev98\Bin\ MSDEV.EXE вместо пути C:\VSCommon\MSDev98\Bin\MSDEV.EXE, с которым, как он думал, должен происходить вызов. Иначе говоря, вместо запуска VC IDE с его локальной машины (C:\VSCommon\MSDev98\Bin\MSDEV.EXE) он запускал ее со своей старой машины (\\R2D2\VSCommon\MSDev98\Bin\ MSDEV.EXE). Как такое могло случиться?

Он только что получил новую машину и установил полностью VC IDE компании NuMega для работы. Чтобы упростить себе жизнь, он скопиро вал ярлыки рабочего стола (файлы LNK) со старой машины, на которой VC IDE была установлена без средств интеграции, на свою новую машину, пе ретащив ярлыки мышью. При перетаскивании ярлыков система изменяет внутренние пути, чтобы отобразить размещение исходных файлов в новых условиях. Поскольку он всегда запускал VC IDE щелчком ярлыка на рабо чем столе, который ссылался на старую машину, то и в новых условиях он также запускал VC IDE со старой машины.

Полученный опыт

Этот программист неправильно начинал отладку, сразу же запуская отлад чик ядра, вместо попытки повторить проблему разными способами. На шаге 1 процесса отладки («Воспроизведи ошибку») я рекомендовал попытаться повторить ошибку различными способами, чтобы убедиться, что перед вами действительно ошибка, а не несколько ошибок, маскирующих и усложня ющих другую. Если бы этот программист следовал шагу 5 («Мысли творчес ки»), то он был бы освобожден от этой работы, потому что он сначала по думал бы о проблеме вместо немедленного погружения в нее.

ГЛАВА 1 Ошибки в программах: откуда они берутся и как с ними бороться?	25

Шаг 9. Научись и поделись

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

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

Последний секрет отладки

Я бы хотел поделиться с вами последним секретом отладки: отладчик может от ветить на все ваши вопросы, только если вы задаете ему корректные вопросы. Еще раз: я советую всегда иметь в голове предположение (что то такое, что вы хотите доказать или опровергнуть), прежде чем запустить отладчик. Как я рекомендовал на шаге 7, до того как я прикоснусь к отладчику, я записываю свое предположе ние, чтобы всегда быть уверенным, что у меня есть цель.

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

Резюме

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

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

Г Л А В А

2

Приступаем к отладке

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

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

Следите за изменениями проекта

вплоть до его окончания

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

ГЛАВА 2 Приступаем к отладке	27

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

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

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

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

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

Системы управления версиями

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

28 ЧАСТЬ I Сущность отладки

файл в систему управления версиями, спросите себя, сможет ли эта информация понадобиться в ближайшие пару лет сопровождающим программистам. Если да, ей самое место в системе управления версиями.

Блочные тесты также нужно включать в систему управления версиями

Хотя я только что объяснил важность регистрации в системе управления версия ми всего, что только может понадобиться, во многих компаниях этим советом пренебрегают. Одна из крупнейших проблем, с которыми я когда либо сталки вался в компаниях по разработке ПО, возникла из за отсутствия в системе управ ления версиями блочных тестов (unit test). Если термин «блочный тест» вам не знаком, я вкратце поясню его. Блочный тест — это фрагмент кода, который уп равляет выполнением основной программы. (Иногда эти тесты еще называют те стовыми приложениями или средствами тестирования.) Это тестовый код, со здаваемый разработчиком программы для проведения тестирования «прозрачного ящика», или «белого ящика»1 , позволяющего удостовериться в том, что основные операции программы действительно имеют место. Подробное описание блочных тестов см. в главе 25 «Блочное тестирование» книги Стива Макконнелла (Steve McConnell. Code Complete. — Microsoft Press, 1993).

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

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

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

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

1Glass box, white box — программа, поведение которой строго детерминировано. —

Прим. перев.

ГЛАВА 2 Приступаем к отладке	29

юсь!) уже проводит блочное тестирование. Я только советую регистрировать эти тесты в системе управления версиями, своевременно обновлять их, а также, воз можно, написать какой либо сценарий для их компиляции и компоновки. Следуя правильным методам работы вы сэкономите огромное количество времени. На пример, большую часть программ для этой книги я разрабатывал на компьютере с Microsoft Windows 2000 Server. Чтобы сразу приступить к тестированию на ком пьютере с Microsoft Windows XP, мне нужно было только извлечь код тестов из системы управления версиями и выполнить сценарии их создания. Многие про граммисты разрабатывают одноразовые блочные тесты, чем осложняют тестиро вание в среде других ОС из за невозможности легкого переноса блочных тестов на другую платформу и их компиляции и компоновки. Если все члены группы будут включать блочные тесты в свой код, это позволит им сэкономить много недель работы.

Контроль над изменениями

Отслеживание изменений имеет огромное значение, однако наличие хорошей системы отслеживания ошибок не означает, что разработчикам разрешается вно сить крупномасштабные изменения в исходные коды программы, когда захочет ся. Это сделало бы все отслеживание изменений бесполезным. Идея в том, чтобы контролировать изменения в ходе разработки программы, ограничивая права на совершение определенных типов изменений на определенных этапах проекта; это позволяет постоянно иметь представление о состоянии общих исходных кодов группы. О наилучшей схеме контроля над изменениями, о которой я когда либо слышал, мне рассказал мой друг Стив Маньян (Steve Munyan); он называет ее «Зе леный, желтый и красный период». В зеленый период любой разработчик может регистрировать любые измененные файлы в общих исходных кодах группы. На чальные стадии проекта обычно полностью выполняются в зеленом периоде, потому что в это время группа разрабатывает новые функции программы.

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

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

30 ЧАСТЬ I Сущность отладки

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

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

скольких людей касается эта проблема?

затронет изменение ядро или второстепенную часть программы?

если изменение будет сделано, какие компоненты приложения придется тес тировать заново?

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

Важность меток

Команда записи метки — одна из наиболее важных команд при работе с систе мой управления версиями. В Microsoft Visual SourceSafe она называется меткой (label), в MKS Source Integrity — контрольной точкой (checkpoint), а в PVCS Version Manager — меткой версии (version label). Но, как бы она ни называлась, метка ука зывает на конкретный набор общих для группы исходных текстов программы. Метка позволяет получить нужную версию исходных кодов программы. Если вы создадите ошибочную метку, возможно, вы никогда не получите исходные коды, использованные для создания конкретной версии программы, и не сможете об наружить причину ее отказа.

Я всегда помечаю:

1.достижение всех контрольных точек работы над программой;

2.все переходы между зеленым, желтым и красным периодами разработки;

3.все компоновки (builds), отсылаемые за пределы группы;

4.все ветви дерева разработки, создаваемые в системе управления версиями;

5.правильное выполнение ежедневной компоновки программы и дымовых тес тов (о них см. ниже одноименный раздел этой главы).