Как исправить баг

Багфикс человека: как фиксить баги, которые мешают работать

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

Как оказалось, причина у всего этого одна — когнитивные искажения. Вот про них и поговорим.

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

Когнитивные искажения — как вредные привычки. Жить можно, но лучше бы с ними покончить. И тут с вредными привычками даже проще: мы хотя бы знаем, что курить или точить пиццу под покровом ночи — грешновато, и надо бы в один прекрасный день это прекратить. А когнитивные искажения если в лицо не знаешь — то даже не представляешь, с чем бороться. Сам мозг против этого (но об этом ниже).

Так как когнитивные искажения мешают работать, понимать друг друга и, по итогу, выполнять задачи, от них нужно избавляться. Это касается менеджеров, разработчиков, дизайнеров, аналитиков, копирайтеров — всех. В идеальном мире каждый сам отлавливает и фиксит свои искажения, но в реальности, как мы знаем, без тестировщиков (взгляда со стороны) такое редко случается. Так что будьте готовы: если вы не фиксите свой баг — однажды окружающие придут на помощь и заставят вас это сделать. А я расскажу, как именно 🙂 Не буду рассматривать все 130 искажений — пройдусь только по тем, которые были пойманы в нашей студии и которые часто встречаются у работников ИТ-сферы.

Генерализация частных случаев

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

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

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

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

Это невозможно!

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

У такой реакции несколько причин:

• лень разбираться в новой задаче;
• сработал эффект сопротивления, и человек хочет доказать, что он сам волен решать, что делать, а что нет;
• задача противоречит чувству прекрасного.

Этот баг уже легче отловить самому. Просто нужно помнить и верить, что не бывает невыполнимых задач. Вспомнили — и думайте, какие ресурсы нужны, чтобы выполнить задание.

Если вы словили это когнитивное искажение у коллеги — задайте ему тот же вопрос, какой задали бы себе: «Скажи, пожалуйста, что тебе потребуется, чтобы сделать эту задачу?». И повторяйте его, пока коллега не поймёт, что ему не верят, да и действительно задача не так уж и невыполнима.

Ну и в будущем, если ситуация повторится, на «Это невозможно!» у вас будет кейс, как человек задачу с таким же диагнозом решил за N минут. Напомните ему этот случай пару раз — и дальше он уже научится сам фиксить этот баг.

Проклятие знания

Проклятие знания — ситуация, когда человек более информированный не может рассмотреть проблему с точки зрения человека, который знает меньше. Отсюда, кстати, столько непонятых гениев. Среди менеджеров даже больше, чем среди программистов или дизайнеров. В основном этот багуля встречается у неопытных менеджеров — которым кажется, что сделать ВОТ ТАК было очевидным решением, которое даже проговаривать не обязательно (чего, естественно, и не было сделано и не сформулировано в задаче). А то, что программист/дизайнер/аналитик этого не понял — его косяк. Конечно, такое нужно фиксить.

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

Личное оскорбление

Следующее когнитивное искажение — когда критика результата воспринимается как личное оскорбление тем, чью работу критикуют.

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

1. Отделить хорошее и плохое.
2. В работе, пусть её и нужно переделать, все равно были какие-то положительные моменты — вспомните их и похвалите коллегу.
3. Объясните, в чём ошибка. Возможно, человек не знает, как эту ошибку исправить, и именно поэтому сопротивляется и бунтует.
4. Инициируйте повторное обсуждение или брейншторм по уже пройденным вопросам.
5. Попросите помощи коллег или выделите дополнительный ресурс — например, время на рисёрч.
6. Настаивайте на переделке плохого.
7. Закрепите пройденный урок: выясните причину, почему искажение активировалось, и запомните, как вы его пофиксили.

Эффект генерации

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

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

Поэтому не бойтесь и не стесняйтесь повторять постановки — это реальный рабочий приём, проверенный пилотами.

Слепое пятно

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

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

Теперь, когда вы знаете про когнитивные искажения, и даже понимаете, в каких именно местах они выпирают и мешают работать, вы сможете с ними бороться. Конечно, будет трудно поначалу, да ещё и слепое пятно будет мешаться. Но со временем оно уменьшится. И тогда и вам, и вашим коллегам станет проще жить и работать — в процессах станет меньше необъяснимых лаж и больше конструктива, мира, дружбы и жвачки.

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

Баги — это норма: как в приложениях возникают ошибки и почему их не нужно бояться

В своей основе мобильное приложение — это код. Баг — это ошибка в коде. неё приложение ведёт себя некорректно, например зависает, вылетает или не откликается на действия пользователя.

Неправильное поведение — закономерный ответ на ошибку. Представьте, что вы написали сложную инструкцию с большим количеством шагов, и в шаге № 404 непонятно объяснили, что делать. этого человек, который будет следовать инструкции, никогда не придёт к правильному результату. Так же и приложение. Оно не поймёт, как себя вести, если в его «инструкции» есть ошибка.

2. Ну, а разве нельзя сразу писать код без ошибок?

Это возможно только в идеальном мире. А в нашем — нет. Приложение — сложная комплексная система. С каждым новым элементом взаимодействие её частей усложняется, и это приводит к возникновению ошибок в мобильном приложении. Всё как в общении: чем больше людей, тем сложнее договориться. Разработчик «соединяет» разные элементы в единый код. Если элемент неизвестный (сторонняя библиотека или сервер, с которым на проекте ещё не работали), разработчик не сможет предвидеть, получится ли у этого элемента найти «общий язык» с существующими частями кода.

К тому же ошибки могут появляться банальных «опечаток» в коде мобильного приложения. Написание кода можно сравнить с набором сообщения. Мы делаем это каждый день, но всё равно ошибаемся. По десять раз перечитываем текст и замечаем опечатку, только когда отправили сообщение собеседнику. От этого не страхует ни проверка орфографии, ни Т9. Все мы люди и не можем быть сконцентрированы 24/7.

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

3. Получается, что ошибки возникают разработчика?

Это не так. Ошибка в приложении может произойти и на стороне интегратора — стороннего сервиса, с которым приложение «сотрудничает». Разработчик не сможет её предотвратить, потому что она находится вне зоны его влияния.

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

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

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

4. Так если разработчик всё проверяет, то почему мы вообще об этом говорим?

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

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

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

5. Отлично! Тестировщик нашёл все баги, разработчик их починил — можно расслабиться.

Подождите, не всё так просто. Нужно быть готовым к тому, что баги будут обнаружены не только во время разработки приложения, но и после релиза, то есть когда приложение появится в сторе — магазине приложений, например в App Store или Google Play.

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

6. А как баг может повлиять на работу приложения?

Зависит от такого, насколько этот баг серьёзен. Условно ошибки, которые выдаёт приложение, можно разделить на три вида: критические, значительные и несущественные.

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

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

7. И что делать, если в моём приложении произошла ошибка?

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

8. Хорошо, значит критический баг починят первым?

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

У критического бага не всегда будет высокий приоритет. Представим, что пользователь не может добавить в корзину штаны, потому что у этой категории товаров сломалась кнопка «В корзину». Если пользователь не может добавить штаны в корзину, значит, он не может их купить. Это критический баг, который нужно чинить. Но в то же время на главном экране приложения есть другая проблема — название магазина написано с опечаткой. Это значительный баг, но приоритет у него выше. Сейчас объясним почему.

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

9. Значит я могу не бояться багов?

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

10. А если я передам приложение на поддержку другой команде?

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

Как искать и исправлять ошибки в коде

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

Шаг 1: Занесите ошибку в трекер

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

1. Вы забыли какую-то важную деталь об ошибке, например, в чем она заключалась.
2. Вы могли делегировать ее кому-то более опытному.

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

Вы должны записать в трекер следующую информацию:

1. Что делал пользователь.
2. Что он ожидал увидеть.
3. Что случилось на самом деле.

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

Шаг 2: Поищите сообщение об ошибке в сети

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

Шаг 3: Найдите строку, в которой проявляется ошибка

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

Шаг 4: Найдите точную строку, в которой появилась ошибка

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

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

Шаг 5: Выясните природу ошибки

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

Вы начали цикл for с единицы вместо нуля или наоборот. Или, например, подумали, что метод .count() или .length() вернул индекс последнего элемента. Проверьте документацию к языку, чтобы убедиться, что нумерация массивов начинается с нуля или с единицы. Эта ошибка иногда проявляется в виде исключения Index out of range .
Ваш процесс или поток пытается использовать результат выполнения дочернего до того, как тот завершил свою работу. Ищите использование sleep() в коде. Возможно, на мощной машине дочерний поток выполняется за миллисекунду, а на менее производительной системе происходят задержки. Используйте правильные способы синхронизации многопоточного кода: мьютексы, семафоры, события и т. д.
1. Неправильные настройки или константы
   Проверьте ваши конфигурационные файлы и константы. Я однажды потратил ужасные 16 часов, пытаясь понять, почему корзина на сайте с покупками виснет на стадии отправки заказа. Причина оказалась в неправильном значении в /etc/hosts , которое не позволяло приложению найти ip-адрес почтового сервера, что вызывало бесконечный цикл в попытке отправить счет заказчику.
2. Неожиданный null
   Бьюсь об заклад, вы не раз получали ошибку с неинициализированной переменной. Убедитесь, что вы проверяете ссылки на null , особенно при обращении к свойствам по цепочке. Также проверьте случаи, когда возвращаемое из базы данных значение NULL представлено особым типом.
3. Некорректные входные данные
   Вы проверяете вводимые данные? Вы точно не пытаетесь провести арифметические операции с введенными пользователем строками?
4. Присваивание вместо сравнения
   Убедитесь, что вы не написали = вместо == , особенно в C-подобных языках.
5. Ошибка округления
   Это случается, когда вы используете целое вместо Decimal , или float для денежных сумм, или слишком короткое целое (например, пытаетесь записать число большее, чем 2147483647, в 32-битное целое). Кроме того, может случиться так, что ошибка округления проявляется не сразу, а накапливается со временем (т. н. Эффект бабочки).
6. Переполнение буфера и выход за пределы массива
   Проблема номер один в компьютерной безопасности. Вы выделяете память меньшего объема, чем записываемые туда данные. Или пытаетесь обратиться к элементу за пределами массива.
7. Программисты не умеют считать
   Вы используете некорректную формулу. Проверьте, что вы не используете целочисленное деление вместо взятия остатка, или знаете, как перевести рациональную дробь в десятичную и т. д.
8. Конкатенация строки и числа
   Вы ожидаете конкатенации двух строк, но одно из значений — число, и компилятор пытается произвести арифметические вычисления. Попробуйте явно приводить каждое значение к строке.
9. 33 символа в varchar(32)
   Проверяйте данные, передаваемые в INSERT , на совпадение типов. Некоторые БД выбрасывают исключения (как и должны делать), некоторые просто обрезают строку (как MySQL). Недавно я столкнулся с такой ошибкой: программист забыл убрать кавычки из строки перед вставкой в базу данных, и длина строки превысила допустимую как раз на два символа. На поиск бага ушло много времени, потому что заметить две маленькие кавычки было сложно.
10. Некорректное состояние
    Вы пытаетесь выполнить запрос при закрытом соединении или пытаетесь вставить запись в таблицу прежде, чем обновили таблицы, от которых она зависит.
11. Особенности вашей системы, которых нет у пользователя
    Например: в тестовой БД между ID заказа и адресом отношение 1:1, и вы программировали, исходя из этого предположения. Но в работе выясняется, что заказы могут отправляться на один и тот же адрес, и, таким образом, у вас отношение 1:многим.

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

Шаг 6: Метод исключения

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

Попробуйте отключать компоненты системы один за другим, пока не найдете минимальную конфигурацию, которая будет работать. Затем подключайте их обратно по одному, пока ошибка не вернется. Таким образом вы вернетесь на шаг 3.

Шаг 7: Логгируйте все подряд и анализируйте журнал

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

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

Шаг 8: Исключите влияние железа или платформы

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

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

Ради интереса, переключите кабель питания в другую розетку или к другому ИБП. Безумно? Почему бы не попробовать?

Если у вас возникает одна и та же ошибка вне зависимости от среды, то она в вашем коде.

Шаг 9: Обратите внимание на совпадения

1. Ошибка появляется всегда в одно и то же время? Проверьте задачи, выполняющиеся по расписанию.
2. Ошибка всегда проявляется вместе с чем-то еще, насколько абсурдной ни была бы эта связь? Обращайте внимание на каждую деталь. На каждую. Например, проявляется ли ошибка, когда включен кондиционер? Возможно, из-за этого падает напряжение в сети, что вызывает странные эффекты в железе.
3. Есть ли что-то общее у пользователей программы, даже не связанное с ПО? Например, географическое положение (так был найден легендарный баг с письмом за 500 миль).
4. Ошибка проявляется, когда другой процесс забирает достаточно большое количество памяти или ресурсов процессора? (Я однажды нашел в этом причину раздражающей проблемы «no trusted connection» с SQL-сервером).

Шаг 10: Обратитесь в техподдержку

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

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

Полезные советы (когда ничего не помогает)

1. Позовите кого-нибудь еще.
   Попросите коллегу поискать ошибку вместе с вами. Возможно, он заметит что-то, что вы упустили. Это можно сделать на любом этапе.
2. Внимательно просмотрите код.
   Я часто нахожу ошибку, просто спокойно просматривая код с начала и прокручивая его в голове.
3. Рассмотрите случаи, когда код работает, и сравните их с неработающими.
   Недавно я обнаружил ошибку, заключавшуюся в том, что когда вводимые данные в XML-формате содержали строку xsi:type=’xs:string’ , все ломалось, но если этой строки не было, все работало корректно. Оказалось, что дополнительный атрибут ломал механизм десериализации.
4. Идите спать.
   Не бойтесь идти домой до того, как исправите ошибку. Ваши способности обратно пропорциональны вашей усталости. Вы просто потратите время и измотаете себя.
5. Сделайте творческий перерыв.
   Творческий перерыв — это когда вы отвлекаетесь от задачи и переключаете внимание на другие вещи. Вы, возможно, замечали, что лучшие идеи приходят в голову в душе или по пути домой. Смена контекста иногда помогает. Сходите пообедать, посмотрите фильм, полистайте интернет или займитесь другой проблемой.
6. Закройте глаза на некоторые симптомы и сообщения и попробуйте сначала.
   Некоторые баги могут влиять друг на друга. Драйвер для dial-up соединения в Windows 95 мог сообщать, что канал занят, при том что вы могли отчетливо слышать звук соединяющегося модема. Если вам приходится держать в голове слишком много симптомов, попробуйте сконцентрироваться только на одном. Исправьте или найдите его причину и переходите к следующему.
7. Поиграйте в доктора Хауса (только без Викодина).
   Соберите всех коллег, ходите по кабинету с тростью, пишите симптомы на доске и бросайте язвительные комментарии. Раз это работает в сериалах, почему бы не попробовать?

Что вам точно не поможет

1. Паника
   Не надо сразу палить из пушки по воробьям. Некоторые менеджеры начинают паниковать и сразу откатываться, перезагружать сервера и т. п. в надежде, что что-нибудь из этого исправит проблему. Это никогда не работает. Кроме того, это создает еще больше хаоса и увеличивает время, необходимое для поиска ошибки. Делайте только один шаг за раз. Изучите результат. Обдумайте его, а затем переходите к следующей гипотезе.
2. «Хелп, плиииз!»
   Когда вы обращаетесь на форум за советом, вы как минимум должны уже выполнить шаг 3. Никто не захочет или не сможет вам помочь, если вы не предоставите подробное описание проблемы, включая информацию об ОС, железе и участок проблемного кода. Создавайте тему только тогда, когда можете все подробно описать, и придумайте информативное название для нее.
3. Переход на личности
   Если вы думаете, что в ошибке виноват кто-то другой, постарайтесь по крайней мере говорить с ним вежливо. Оскорбления, крики и паника не помогут человеку решить проблему. Даже если у вас в команде не в почете демократия, крики и применение грубой силы не заставят исправления магическим образом появиться.

Ошибка, которую я недавно исправил

Это была загадочная проблема с дублирующимися именами генерируемых файлов. Дальнейшая проверка показала, что у файлов различное содержание. Это было странно, поскольку имена файлов включали дату и время создания в формате yyMMddhhmmss . Шаг 9, совпадения: первый файл был создан в полпятого утра, дубликат генерировался в полпятого вечера того же дня. Совпадение? Нет, поскольку hh в строке формата — это 12-часовой формат времени. Вот оно что! Поменял формат на yyMMddHHmmss , и ошибка исчезла.