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

Ч А С Т Ь I

СУЩНОСТЬ ОТЛАДКИ

Г Л А В А

1

Ошибки в программах: откуда они берутся и как с ними бороться?

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

Ошибки и отладка

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

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

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

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

Вы должны беспокоиться об ошибках в программах, так как в конечном счете они дорого обходятся вашему бизнесу. Очень скоро заказчики начинают обращать ся к вам за помощью, заставляя вас тратить свое время и деньги, поддерживая текущую разработку, в то время как конкуренты уже работают над следующими версиями. Затем невидимая рука экономики нанесет вам удар: заказчики начнут покупать программы конкурентов, а не ваши. ПО в настоящее время востребова но больше, чем капитальные вложения, поэтому борьба за высокое качество про грамм будет только накаляться. Многие приложения поддерживают расширяемый язык разметки (Extensible Markup Language, XML) для ввода и вывода, и ваши пользо ватели потенциально могут переключаться с программы одного поставщика на программу другого, переходя с одного Web сайта на другой. Это благо для пользо вателей будет означать, что если наши программы будут содержать большое ко личество ошибок, то ваше и мое трудоустройство окажется под вопросом. Это же будет побуждать к созданию более качественных программ. Позвольте мне сфор мулировать это иначе: чем больше ошибок в ваших программах, тем вероятней, что вы будете искать новую работу. Нет ничего более ненавистного, чем заниматься поиском работы.

Что такое программные ошибки?

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

нелогичный пользовательский интерфейс;

неудовлетворенные ожидания;

низкая производительность;

аварийные завершения или разрушение данных.

Нелогичный пользовательский интерфейс

Нелогичный пользовательский интерфейс хоть и не является очень серьезным видом ошибок, очень раздражает. Одна из причин успеха ОС Microsoft Windows — в оди наковом в общих чертах поведении всех разработанных для Windows приложе ний. Отклоняясь от стандартов Windows, приложение становится «тяжелым» для пользователя. Прекрасный пример такого нестандартного, досаждающего пове дения — реализация с помощью клавиатуры функции поиска (Find) в Microsoft Outlook. Во всех других англоязычных приложениях на планете, разработанных для Windows, нажатие Ctrl+F вызывает диалог для поиска текста в текущем окне. А в Microsoft Outlook Ctrl+F переадресует открытое сообщение, что, как я пола гаю, является ошибкой. Даже после многих лет работы с Outlook я никак не могу

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

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

В клиентских приложениях довольно просто решить все проблемы нелогич ности пользовательского интерфейса. Достаточно лишь следовать рекомендаци ям книги Microsoft Windows User Interface (Microsoft Press, 1999), доступной так же в MSDN Online по адресу http://msdn.microsoft.com/library/en us/dnwue/html/ welcome.asp. Если вы чего то не найдете в этой книге, посмотрите на другие при ложения для Windows, делающие что то похожее на то, что вы пытаетесь реали зовать, и следуйте этой модели. Создается впечатление, что Microsoft имеет бес конечные ресурсы и неограниченное время. Если вы задействуете преимущества их всесторонних исследований в процессе решения проблем логичности, то это не будет вам стоить руки или ноги.

Если вы работаете над интерфейсом Web приложения, ваша жизнь существенно труднее: здесь нет стандартов на пользовательский интерфейс (UI). Как пользо ватели, мы знаем, что довольно трудно найти хороший UI в браузере. Для разра ботки хорошего пользовательского интерфейса для Web клиента я могу пореко мендовать две книги. Первая — это образцово показательная библия Web дизай на: «Jacob Nielsen, Designing Web Usability: The Practice of Simplicity». Вторая — небольшая, но выдающаяся книга, которую вы должны дать всем доморощенным спецам по эргономике, которые не могут ничего нарисовать, не промочив горло (так некоторые начальники хотят делать UI, а сами никогда не работали на ком пьютере). Это книга «Steve Krug, Don’t Make Me Think! A Common Sense Approach to Web Usability». Разрабатывая что либо для Web клиента, помните, что не все пользователи имеют 100 мегабитные каналы. Поэтому сохраняйте UI простым и избегайте загрузки с сервера множества мелочей. Исследуя замечательные кли ентские Web интерфейсы, компания User Interface Engineering (www.uie.com) на шла, что такие простые решения, как CNN.com, нравятся всем пользователям. Про стой набор понятных ссылок на информационные разделы кажется им выглядя щим лучше, чем что либо еще.

Неудовлетворенные ожидания

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

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

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

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

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

Низкая производительность

Пользователей очень расстраивают ошибки, приводящие к снижению произво дительности при обработке реальных данных. Такие ошибки (а причина их — в недостаточном тестировании) порой выявляются только на реальных больших объемах данных. Один из проектов, над которым я работал, BoundsChecker 3.0 компании NuMega, содержал подобную ошибку в первой версии технологии Final Check. Эта версия FinalCheck добавляла отладочную и контекстно зависимую информацию прямо в текст программы, чтобы BoundsChecker подробней описывал ошибки. Увы, мы недостаточно протестировали FinalCheck на реальных прило жениях перед выпуском BoundsChecker 3.0. В итоге гораздо больше пользовате лей, чем мы предполагали, не смогло задействовать эту возможность. В последу ющих выпусках мы полностью переписали FinalCheck. Но первая версия имела низ кую производительность, и поэтому многие пользователи больше с ней не рабо тали, хотя это была одна из самых мощных и полезных функций. Что интересно, мы выпустили BoundsChecker 3.0 в 1995 году, а семь лет спустя все еще были люди (по крайней мере двое), которые говорили мне, что они не работают с FinalCheck из за такого негативного опыта!

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

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

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

Аварийные завершения или разрушение данных

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

Обработка ошибок и решения

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

короткие или невозможные для исполнения сроки;

подход «Сначала кодируй, потом думай»;

непонимание требований;

невежество или плохое обучение разработчика;

недостаточная приверженность к качеству.

Короткие или невозможные для исполнения сроки

Мы все работали в коллективах, в которых «руководство» устанавливало сроки, либо сходив к гадалке, либо, если первое стоило слишком дорого, с помощью магичес кого шара1 . Хоть нам и хотелось бы верить, что в большинстве нереальных гра фиков работ виновато руководство, чаще бывает, что его не в чем винить. В ос нову планирования обычно кладется оценка объема работ программистами, а они иногда ошибаются в сроках. Забавные они люди! Они интраверты, но почти все гда оптимисты. Получив задание, программисты верят до глубины души, что мо гут заставить компьютер пуститься в пляс. Если руководитель приходит и гово рит, что в приложение надо добавить преобразование XML, рядовой инженер говорит: «Конечно, босс! Это займет три дня». Конечно же, он может даже не знать, что такое «XML», но он знает, что это займет три дня. Большой проблемой явля ется то, что разработчики и руководители не принимают в расчет время обуче ния, необходимое для того, чтобы смочь реализовать функцию. В разделе «Пла нирование времени построения систем отладки» главы 2 я освещу некоторые ас пекты, которые надо учитывать при планировании. Кто бы ни был виноват в оши бочной оценке сроков поставки — руководство ли, разработчики или обе сторо

1Детская игрушка «Magic 8 Ball», выпускающаяся в США с 40 х годов, которая «отвеча ет на любые вопросы». На самом деле содержит 20 стандартных обтекаемых ответов.

— Прим. перев.

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

ны — главное, что нереальный график ведет к халтуре и снижению качества про дукта.

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

Подход «Сначала кодируй, потом думай»

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

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

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

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

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

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

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

Когда я занялся программированием, я стал использовать этот вид планиро вания в работе. В первый раз я пришел на совещание и сказал: «Что будет, если Боб помрет до того, как мы минуем стадию выработки требований?» Все заерза ли. Поэтому теперь я формулирую вопросы менее живодерски, вроде: «Что будет, если Боб выиграет в лотерее и уволится до того, как мы минуем стадию выработ ки требований?» Идея та же. Найдите все сомнительные места и путаницу в ва ших планах и займитесь ими. Это не просто сделать, слабых инженеров это сво дит с ума, но ключевые вопросы всегда всплывут, если вы копнете достаточно глубоко. Скажем, на стадии выработки требований вы будете задавать такие воп росы: «Что, если наши требования не соответствуют пожеланиям пользователей?» Такие вопросы помогут предусмотреть в бюджете время и деньги на выработку согласованных требований. На стадии проектирования вы будете спрашивать: «Что, если производительность не будет достаточно высока?» Такие вопросы напомнят вам о необходимости сесть и определить основные параметры производительности и начать планирование, как вы собираетесь добиваться значений этих парамет ров при тестировании в реальных условиях. Планировать будет существенно проще, если вы сможете свести все вопросы в таблицу. Просто будьте благодарны, что ваша жизнь не зависит от поставки ПО в срок.

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

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

Тяжелый случай с СКПД

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

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

Обычно такие совещания с рисованием кружочков и стрелочек занимают 10–15 минут. Однако архитектор выступал уже 45 минут, а я еще ни в чем толком не разобрался. Наконец я окончательно запутался и снова попро сил сделать 10 минутный обзор системы. Мне не нужно было знать все — только основные особенности. Архитектор начал заново, но через 15 ми нут он осветил только 25% системы!

Исход

Это была большая COM система, и теперь я начал понимать, в чем заклю чались проблемы быстродействия. Было ясно, что кто то в команде был без ума от COM. Он не удовлетворился глотком из стакана с живительной вла гой COM, а хлебал из 200 литровой бочки. Как я позже понял, системе нужно было 8–10 основных объектов, а эта команда имела 80! Чтобы вы поняли, насколько нелеп такой подход, представьте себе, что практически каждый символ в строке был представлен COM объектом. Классический случай нулевого практического опыта авторов!

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

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

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

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

Непонимание требований

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

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

Лучший документ такого рода, созданный мной, был просто серией рисунков на бумаге (бумажные прототипы) UI. Основываясь на исследованиях и результа тах обучения у Джэйреда Спула и его компании User Interface Engineering, моя команда рисовала UI и прорабатывала сценарии поведения пользователей. Делая это, мы должны были сосредоточиться на требованиях к разработке и точно по нять, как пользователи собирались исполнять свои задачи. Если вставал вопрос, какое поведение предполагалось по данному сценарию, мы доставали свои бумаж ные прототипы и вновь работали над сценарием.

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

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

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

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