Автор Тема: Это может быть полезно всем (Часть 2)  (Прочитано 5219 раз)

0 Пользователей и 1 Гость просматривают эту тему.

Оффлайн ONK

  • Новый пользователь
  • *
  • Сообщений: 4
Продолжение ....

«Затем я попробовал . . .»
Существует множество вещей, которые вы можете делать, когда происходит ошибка. Многие из них сделают проблему еще хуже. Моя подруга в школе удалила по ошибке все свои файлы Word, и, перед тем как позвать знающего человека на помощь, она переустановила Word, а затем попыталась запустить дефрагментатор. Ничего из этого не помогло восстановить файлы, и этим она перемешала свой диск до такой степени, что ни одна программа восстановления файлов в мире не смогла бы ничего восстановить. Если бы она просто оставила все как есть, у нее был бы шанс.
Пользователи вроде этого похожи на мангуста загнанного в угол: упираясь спиной в стену и глядя смерти в лицо, он неистово нападает, потому, что делать что-то должно быть лучше, чем ничего не делать. Это мало подходит к тому типу проблем, которые случаются с компьютером.
Вместо того чтобы быть мангустом, будьте антилопой. Когда антилопа сталкивается с чем-то неожиданным или пугающим, она замирает. Она стоит абсолютно неподвижно и пытается не привлекать внимание, пока она стоит, она думает и вырабатывает наилучшее решение. (Если бы у антилоп была линия технической поддержки, они бы позвонили туда именно в этот момент.) Тогда, когда она решит, что можно сделать наиболее безопасно, она делает.
Когда что-то происходит неправильно, сразу прекратите делать что бы то ни было. Не трогайте вообще никаких кнопок. Посмотрите на экран, заметьте все необычное и запомните или запишите это. Затем, может быть, начните нажимать «OK» или «Отмена», в зависимости от того, что кажется безопасней. Попробуйте выработать рефлекс — если компьютер делает что-то неожиданное — замереть.
Если вы справились с выходом из проблемы либо путем закрытия программы, либо перезагрузкой компьютера, хорошо бы попробовать сделать так, чтобы эта проблема возникла опять. Программисты любят проблемы, которые они могут воспроизвести более чем один раз. Счастливые программисты исправляют ошибки быстрее и эффективнее.
«Я думаю, что тахионная модуляция, должно быть, плохо поляризована»
Не только непрограммисты пишут плохие сообщения об ошибках. Некоторые из самых худших ошибок, которые я видел, написаны программистами и даже хорошими прогаммистами.
Однажды я работал с другим программистом, который находил ошибки в собственном коде и пытался их исправить. Также достаточно часто он обнаруживал ошибку, которую он не смог исправить и звал меня на помощь. Я спрашивал «Что случилось?» Он отвечал, рассказывая мне свое мнение о том, что должно быть исправлено.
Это хорошо работало, когда его мнение было правильно. Это значило, что он уже сделал часть работы, и мы можем закончить ее вместе. Это было полезно и эффективно.
Но довольно часто он ошибался. Мы некоторое время работали, пытаясь разгадать, почему какая-то конкретная часть программы производила неправильные данные, и, в конце концов, обнаруживали, что она этого не делала, что мы полчаса исследовали превосходный кусок кода, а настоящая проблема была где-то еще.
Я уверен, что с врачом он бы так не поступал. «Доктор, мне нужен рецепт Гидройойодина.» Люди знают, что это не надо говорить врачу: они говорят симптомы, свои неудобства, боли, сыпь и жар, и вы позволите врачу сделать диагноз, что это за проблема и что с ней делать. Иначе, врач объявит вас ипохондриком или сумасшедшим, и это будет правильно.
То же самое и с программистами. Иногда полезно сообщить собственный диагноз, но всегда излагайте симптомы. Диагноз - это необязательное дополнение и не альтернатива предоставлению симптомов. В равной степени, посылка изменений в коде для исправления проблемы это полезное дополнение к сообщению об ошибке, но не адекватная замена ему.
Если программист просит у вас дополнительной информации, не выдумывайте ее! Однажды некто сообщил мне об ошибке и я попросил его попробовать команду, про которую я знал, что она не работает. Причина, по которой я его просил — я хотел знать, какое из двух сообщений об ошибке она выдаст. Знание того, какое сообщение программа выдала — было ключевым. Он не попытался это сделать, он просто написал мне «Нет, это не будет работать» Потребовалось некоторое время, чтобы убедить его попробовать.
Превосходно, что вы пользуетесь интеллектом, чтобы помочь программисту. Даже если ваши дедукции неправильны, программисты будут благодарны вам за то, что вы, по крайней мере, попытались сделать их жизнь легче. Но сообщите также и симптомы, а то вместо этого вы можете сделать их жизнь еще труднее.

«Забавно, оно делало так секунду назад»
Скажите «неустойчивый сбой» любому программисту и посмотрите как погрустнеет его лицо. Простые проблемы это те, для воспроизведения которых достаточно выполнить простую последовательность действий. Программист может повторить эти действия в хорошо наблюдаемых тестовых условиях и детально посмотреть, что случилось. Слишком много проблем так не делают: это программы, которые сбоят раз в неделю или очень редко, или никогда не сбоят, когда вы пытаетесь это сделать перед программистом, но всегда сбоят, когда у вас подходит крайний срок сдачи работы.
Большинство неустойчивых сбоев не являются истинно неустойчивыми. У большинства из них есть какая-то логика. Некоторые могут возникать, когда заканчивается память, некоторые могут возникать, когда другая программа пытается изменить критический файл в неподходящий момент, и некоторые могут возникать только в первую часть каждого часа! (Я на самом деле такое видел.)
Также, если вы можете воспроизвести ошибку, а программист не может, это может быть потому, что ваш компьютер и его компьютер в чем-то различаются и это различие приводит к ошибке. Однажды у меня была программа, которая сворачивалась в маленький шарик в верхнем левом углу экрана, и сидела там и дулась. Но она это делала только при разрешении 800×600; все было хорошо на моем 1024×768 мониторе.
Программист захочет узнать все, что вы можете выяснить о проблеме. Попробуйте, например, на другой машине. Попробуйте дважды или трижды и посмотрите, как часто она сбоит. Если ошибка происходит, когда вы делаете серьезную работу, но не происходит, когда вы пытаетесь ее демонстрировать, причиной может быть большое время запуска или большие файлы. Попытайтесь запомнить как можно больше деталей того, что вы делали с программой, когда она засбоила и, если вы видите какие-то закономерности, отметьте их. Все, что вы можете сообщить, может помочь. Даже если это только предположения (такие как «Есть тенденция к тому, что она падает более часто, когда запущен Emacs»), это может не дать прямых улик к нахождению причины проблемы, но это может помочь программисту воспроизвести ошибку.
Наиболее важно, что программист захочет убедиться в том, имеет ли он дело с настоящим неустойчивым сбоем или это сбой, характерный для машины. Он захочет узнать множество деталей о вашем компьютере, так, что сможет сделать вывод о том, чем он отличается от его компьютера. Множество этих деталей зависит от конкретной программы, она одна вещь, которую вы определенно должны быть готовы сообщить — номера версий. Номер версии программы, номер версии операционной системы и, возможно, номера версий других программ, связанных с проблемой.

«Тогда я загрузил диск в свой Windows . . .»
Существенно, чтобы сообщение об ошибке было написано ясно. Если программист не сможет понять, что вы имели в виду, вы могли бы с таким же успехом вообще ничего не говорить.
Я получаю сообщения об ошибках со всех концов мира. Многие из них от людей, для которых английский язык не является родным, и многие из них извиняются за свой плохой английский. Вообще говоря, сообщения об ошибках с извинениями за плохой английский на самом деле очень ясные и полезные. Большинство неясных сообщений приходит от людей, для которых английский родной, которые полагают, что я пойму их, даже если они не будут делать никаких усилий для того, чтобы быть ясными или точными.
•   Будьте конкретны. Если вы можете сделать что-то двумя способами, укажите, каким вы воспользовались. «Я выбрал Загрузить» может значить «Я щелкнул по кнопке Загрузить» или «Я нажал Alt+З». Скажите, что вы сделали. Иногда это имеет значение.
•   Будьте многословны. Лучше дать больше информации, чем меньше. Если вы сказали слишком много, программист может игнорировать какие-то части. Если вы сказали слишком мало, он должен вернуться и задать еще вопросы. Одно из сообщений об ошибке, которое я получил, состояло из одного предложения. Каждый раз, когда я просил больше информации, сообщивший отвечал мне одним предложением. Получение полезного объема информации заняло у меня несколько недель, поскольку прибавлялось каждый раз по одному небольшому предложению.
•   Будьте осторожны с местоимениями. Не используйте слов вроде «это» или «окно» когда неясно, что они означают. Рассмотрим вот это: «Я запустил приложение Foo. Оно выкинуло окно с предупреждением. Я попытался закрыть его, и оно упало». Неясно, что пользователь пытался закрыть. Пытался ли он закрыть окно с предупреждением или приложение Foo целиком? Это большая разница. Вместо этого вы можете сказать «Я запустил приложение Foo, которое выкинуло окно с предупреждением. Я попытался закрыть окно с предупреждением, и приложение Foo упало». Это длиннее и с повторениями, но, также, яснее и его труднее неправильно понять.
•   Прочитайте то, что вы написали. Сами прочитайте сообщение, и посмотрите считаете ли вы сами, что оно ясное. Если вы привели последовательность действий, приводящую к сбою, попытайтесь выполнить ее сами чтобы убедиться в том, что вы не пропустили какой-нибудь шаг

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

Copyright © 1999 Simon Tatham.
« Последнее редактирование: Июня 25, 2007, 01:46:17 am от ONK »

Оффлайн warlock

  • Администратор
  • Гуру
  • *****
  • Сообщений: 675
  • Пол: Мужской
Re:Это может быть полезно всем (Часть 2)
« Ответ #1 : Августа 29, 2007, 11:07:35 pm »
Спасибо за поддержку, коллега! Материал действительно интересный и заслуживает внимания - за что отдельное спасибо ;-)

Также хотел обратить внимание на аналогичный труд, подготовленный одним из наших инженеров, посвященный теме обращений за технической поддержкой:
http://rd.natec.ua/Help/DialExpert/help-de-support.htm

Но факт остается фактом - руководство пользователю читают только когда телефон техподдержки недоступен, спросить у знакомых невозможно и все попытки решить проблему "с наскока" не увенчались успехом ;-)