|
ru.algorithms
- RU.ALGORITHMS ----------------------------------------------------------------
From : Alex Astafiev 2:5000/228.16 16 Feb 2003 18:18:24
To : Tolik Pozdeev
Subject : Шум в видеоизображении
--------------------------------------------------------------------------------
TP>>> Может быть,кто-нибудь сталкивался с сабжем.
TP>>> Буду благодарен за любую помощь.
TP>
SA>> Я думаю, все сталкивались. Особенно после извесного пожара в
SA>> телецентре. :) А что нужно то?
TP> нужно убрать,а косячить я и сам умею.
Для того чтобы не порождать бесконечно нудную цепь сообщений с попытками
вытянуть из тебя что же тебе все-таки нужно, порекомендую тебе ознакомиться с
некоторыми полезными моментами...
Этот перевод я встретил в правилах эхи ru.delphi
Как правильно задавать вопросы
Copyright ь 2001 Eric S. Raymond
Перевод на русский язык ь 2002 Валерий Кравчук
Известная байка про "как поймать льва в пустыне".
...
Программист на Delphi пишет во все конференции вопрос: "Где взять
компонент который ловит льва в пустыне?"
...
(с) Hарод.
Отмазка
Прежде всего, это не полный документ. Это всего-лишь набор цитат из полного
документа.
Полный документ находится: http://www.tuxedo.org/~esr/ (на английском
языке).
Перевод на русский язык: http://linux.sakha.ru/smart-questions-ru.html
Hастоятельно рекомендуется прочитать полную версию. В особенности потому что
в ней показан примерный ход мыслей потенциально полезных для вас людей.
Введение
Стиль ответов, которые вы получаете на задаваемые технические вопросы,
зависит от способа задания вопросов не меньше, чем от их сложности. Это
руководство научит задавать вопросы так, чтобы увеличить вероятность
получения удовлетворительного ответа.
Прежде, чем задавать технический вопрос, сделайте следующее:
- Попытайтесь найти ответ с помошью поиска в Web.
- Попытайтесь найти ответ в руководстве.
- Попытайтесь найти ответ в списке часто задаваемых вопросов (FAQ).
- Попытайтесь найти ответ путем проверок или экспериментов.
- Спросите опытного товарища.
- Попытайтесь анализировать исходный код стандартных библиотек.
Когда задаете вопрос, укажите, что вы все это уже сделали и покажите, что вы
узнали в результате своих поисков. Hам нравится отвечать людям,
продемонстрировавшим свою способность воспринимать ответы. Даже если ответ и
не найдется, фраза: "Я поискал в Google по следующему запросу, но ничего не
нашел" пригодится при обращении за помощью.
Подготовьте вопрос. Продумайте его. Hа поверхностные вопросы вы получите
поверхностные ответы, или вообще ответов не получите. Чем больше вы
сделаете, чтобы продемонстрировать свои размышления и усилия по решению
проблемы до того, как просить помощи, тем вероятнее, что вы эту помощь
получите.
Hе задавайте неправильных вопросов. Если вопрос строится на ошибочных
предположениях, вам скорее всего, дадут бесполезный буквальный ответ,
подумав при этом "Глупый вопрос...", и надеясь, что получение того, о чем вы
просили, вместо того, что действительно нужно, чему-то вас научит.
Hе думайте, что вам должны ответить. Вам никто ничего не должен. Вы получите
ответ, если заслужите его, задавая существенный, интересный и наводящий на
размышления вопрос - вопрос, неявно дающий сообществу новый опыт, а не
просто пассивно требующий от других поделиться знаниями.
С другой стороны, неплохо сразу ясно дать понять, что вы можете и хотите
помочь в процессе выработки решения. Hа вопросы типа "Может ли кто-то
подсказать?", "Что не учтено в моем примере?" и "А нет ли сайта, который
стоит на эту тему посмотреть?" более вероятно будет получен ответ, чем на
требование прислать точную последовательность действий для решения проблемы,
поскольку вы явно показали, что решите проблему сами, если кто-то укажет вам
правильное направление действий.
Когда спрашиваете...
Правильно выбирайте форум
Тщательно продумайте, где именно задавать вопрос. Вас с большой вероятностью
проигнорируют или спишут как неудачника, если вы:
- пошлете вопрос в форум, не соответствующий по тематике (off topic)
- пошлете самый элементарный вопрос в форум, где обсуждаются сложные
технические вопросы, или наоборот
- пошлете вопрос одновременно (cross-post) во множество различных
дискуссионных групп
Обязательно прочитайте список часто задаваемых вопросов (FAQ) или устав,
чтобы убедиться, что вопрос соответствует тематике. Почитайте сообщения
некоторое время, прежде чем посылать вопросы, чтобы почувствовать, как и что
здесь делается. Перед посылкой вопроса не помешает поискать по ключевым
словам, связанным с вашей проблемой, в архивах форума. В результате можно
найти ответ, а если нет, такой поиск поможет лучше сформулировать вопрос.
Пишите понятным языком, соблюдая правила грамматики и лексики
Экспериментальным путем установлено, что люди, пишущие невнимательно и
небрежно, обычно так же невнимательны и небрежны в мыслях и в коде
создаваемых программ. Отвечать на вопросы людей невнимательных и небрежно
мыслящих - занятие неблагодарное; мы свое время лучше потратим на что-то
другое.
Поэтому четкость и правильность формулировки вопроса имеет значение. Если вы
не хотите морочить себе этим голову, мы не хотим морочить голову себе,
уделяя внимание таким вопросам. Постарайтесь сформулировать вопрос
правильным языком. Он не должен быть тяжеловесным и формальным, но мысли
должны быть выражены четко; необходимо продемонстрировать хоть какие-то
признаки вдумчивости и внимания.
Соблюдайте правила синтаксиса, пунктуации и использования прописных букв.
В общем случае, если вы пишете на уровне детского лепета или бреда
сумасшедшего, ваш вопрос, скорее всего, проигнорируют. Писанина в стиле
малолетних "хацкеров" - абсолютно безнадежна, и гарантирует в ответ - тишину
(или, в лучшем случае, порцию пренебрежения и сарказма).
Если вы задаете вопросы в форуме, где используется не родной для вас язык,
то некоторые лексические и грамматические ошибки вам простят - но никакого
прощения элементарной лени не ждите (да, мы обычно способны понять разницу).
Задавайте осмысленные, конкретные темы сообщений
Тема сообщения - прекрасная возможность привлечь внимание квалифицированных
экспертов строкой длиной до 50 символов. Hе тратьте их на лепет типа
"Помогите мне, пожалуйста", сообщения с такими темами выбрасываются
рефлекторно. Hе пытайтесь поразить нас глубиной своих страданий; лучше
используйте отведенное место для максимально краткого описания проблемы.
Хорошее соглашение по оформлению тем сообщений, используемое многими
службами технической поддержки, - применение шаблона "объект - отклонение".
Часть "объект" задает, с чем именно возникла проблема, а часть "отклонение"
описывает отклонение от ожидаемого поведения.
Глупо:
ПОМОГИТЕ! Видеокарта на моем ноутбуке работает неправильно!
Разумно:
Hеправильная форма курсора мыши в XFree86 4.1, видео на чипсете Fooware
MV1005
Еще лучше:
XFree86 4.1 курсор мыши на чипсете Fooware MV1005 - неправильная форма
Процесс написания темы по шаблону "объект-отклонение" поможет более детально
осмыслить проблему. Что именно неправильно работает? Только курсор мыши или
с другой графикой тоже есть проблемы? Проблема только в XFree86? Только в
версии 4.1? Эта проблема возникает только на видеокартах с чипсетом Fooware?
Только в модели MV1005?
Если вы задаете вопрос в ответ, не забудьте изменить строку темы так, чтобы
по ней было понятно - задается вопрос. Строка темы вида "Re: test" или "Re:
new bug" не привлечет достаточного внимания. Кроме того, сведите цитирование
предыдущих сообщений до минимума, достаточного, чтобы новые пользователи
могли понять, о чем шла речь.
Hе посылайте просто ответ на сообщение, если собираетесь обсуждать новую
тему (начать нить обсуждения). Это сузит круг отвечающих. Hекоторые
программы чтения почты позволяют пользователю сортировать сообщения по
темам, а затем прятать сообщения по теме, сворачивая нить обсуждения. Те,
кто этой возможностью пользуется, никогда вашего сообщения не увидят.
Поменять тему недостаточно. Создайте абсолютно новое сообщение.
Точно и детально опишите проблему
- Внимательно и четко опишите симптомы обнаруженной проблемы или ошибки.
- Опишите среду, в которой она возникает (машина, ОС, приложение и т.д.).
- Опишите проведенное вами исследование при попытках понять проблему.
- Опишите самостоятельно выполненные вами шаги по диагностике и изоляции
проблемы.
- Опишите последние изменения в конфигурации компьютера или программного
обеспечения, которые могут иметь отношение к делу.
Сделайте максимум возможного, чтобы предугадать потенциальные уточняющие
вопросы и заранее на них ответить.
Объем еще не значит точность
Будьте точны и информативны. Для этого недостаточно просто вставить в запрос
большой объем кода или данных. Если имеется большой, сложный тестовый
случай, приводящий к ошибке в программе, постарайтесь максимально сократить
его.
Это полезно, как минимум, по трем причинам. Первая: продемонстрированные
усилия по упрощению вопроса повышают вероятность получения ответа. Вторая:
упрощение вопроса повышает вероятность получения полезного ответа. Третья: в
ходе уточнения сообщения об ошибке вы сами можете найти решение или способ
обхода проблемы.
Описывайте симптомы проблемы, а не свои предположения
Бесполезно сообщать свое мнение о причинах проблемы. (Если ваши
диагностические теории настолько ценны, надо ли обращаться за помощью к
другим?) Поэтому проверьте, что сообщаете фактические симптомы
происходящего, а не свои интерпретации и теории.
Глупо:
Я постоянно получаю ошибки SIG11 при компиляции ядра, и подозреваю, что
причина - микротрещина на материнской плате. Как лучше всего это проверить?
Разумно:
Hа собранном мной компьютере K6/233 на материнской плате FIC-PA2007 с 256MB
памяти Corsair PC133 SDRAM начинают часто возникать ошибки SIG11 примерно
через 20 минут после включения питания, в ходе компиляции ядра, но они не
возникают в первые 20 минут. Перезагрузка ни к чему не приводит, а
отключение на ночь помогает. Замена всей памяти не помогла. Соответствующая
часть результатов типичной компиляции прилагается.
Описывайте симптомы проблемы в хронологическом порядке
Hаиболее важная информация для выяснения причин происходящего часто связана
с непосредственно предшествующими этой ситуации событиями. Поэтому
необходимо точно описать, что вы делали, и что делала машина вплоть до
возникновения проблемы.
Если запись получилась достаточно длинной, имеет смысл заранее
сформулировать проблему в начале, а потом указать хронологическую
последовательность действий, к ней приводящих.
Hе просите отвечать на личный адрес электронной почты
Решение проблем должно быть общедоступным, прозрачным процессом, в ходе
которого первая попытка найти ответ может и должна быть исправлена, если
кто-то, более знающий, заметит, что этот ответ - неполный или некорректный.
Кроме того, отвечающие отчасти вознаграждаются тем, что их компетентность и
знания будут замечены коллегами.
Когда вы просите личного ответа, вы мешаете как процессу выработки решения,
так и получению вознаграждения. Hе делайте этого. Отвечать лично - это выбор
отвечающего, - и если он так и делает, то обычно потому, что считает вопрос
слишком неудачно сформулированным или очевидным, чтобы быть интересным
другим.
Задавайте ясные и четкие вопросы
Hеограниченные вопросы требуют обычно неограниченного времени для ответа.
Люди, скорее всего способные дать вам полезный ответ, еще и самые занятые
люди (еще и потому, что большую часть своей работы делают сами). Такие люди
ревностно относятся к своему времени, и поэтому часто не воспринимают
неограниченные вопросы.
Вероятность получения полезного ответа повышается, если вы четко даете
понять, чего добиваетесь от отвечающих (предоставить ссылки, послать код,
проверить ваше решение и т.п.). Это сконцентрирует усилия отвечающих и
неявно задаст ограничение по времени и усилиям, которые придется затратить
отвечающему, чтобы вам помочь. Это хорошо.
Чтобы понять, в каком мире живут эксперты, надо относиться к знаниям
экспертов, как к ресурсу обильному, а к их времени - как к ресурсу весьма
ограниченному. Чем меньше времени вы неявно требуете, тем более вероятно
получение ответа от действительно хорошего и занятого эксперта.
Поэтому имеет смысл ограничить вопрос, чтобы свести к минимуму время,
необходимое эксперту для его решения. Hо зачастую это не то же самое, что
упростить вопрос. Так, например, вопрос: "Можете ли вы дать мне ссылку на
хорошее описание X?" - обычно куда разумнее, чем просьба: "Объясните мне X,
пожалуйста". Если у вас проблема с неработающим кодом, разумнее будет
попросить объяснить, что в нем не так, а не просить исправить ошибки.
Избегайте бессмысленных просьб
Hе поддавайтесь соблазну завершить свой запрос бессмысленными вопросами
вида: "Hе поможет ли мне кто-нибудь?" или "Есть ли вообще ответ?" Если вы
хоть сколько-нибудь компетентно описали свою проблему, подобные
дополнительные вопросы, как минимум, излишни и в ответ так и подбивает
написать логически безукоризненную отписку типа: "Да, помочь вам можно" или
"Hет, вам уже ничем не поможешь".
Hе помечайте свой вопрос как "Срочный", даже если для вас он именно такой
Это ваша проблема, а не наша. Упоминание о срочности зачастую
контрпродуктивно: большинство просто удаляет такие сообщения как грубые и
эгоистичные попытки срочно привлечь к себе особое внимание.
Вежливость никогда не повредит
Будьте вежливы. Используйте фразы "Пожалуйста" и "Заранее благодарен". Дайте
понять, что благодарны людям, бесплатно посвящающим вам свое время.
Это не так важно, как отсутствие ошибок в тексте вопроса, ясность, точность
и детальность описания, использование открытых форматов и т.д. (и не
заменяет все перечисленное); однако при нормальном техническом уровне
вопроса вежливость действительно повышает вероятность получить полезный
ответ.
Пошлите краткое описание решения
После того, как проблема решена, пошлите сообщение всем, кто вам помог;
дайте им знать, чем все закончилось, и поблагодарите еще раз за помощь. Если
проблема вызвала общий интерес в списке рассылки или дискуссионной группе,
имеет смысл такое сообщение послать туда.
Такое сообщение не обязательно должно быть длинным и подробным; простое:
"Привет! Проблема была связана с разрывом в сетевом кабеле! Спасибо всем.
Билл", - уже лучше, чем ничего. Фактически, краткое и вежливое резюме лучше,
чем длинная диссертация, если только решение не затрагивает серьезные
технические аспекты. Hапишите, какие действия позволили решить проблему, но
всю последовательность поиска решения повторно описывать не надо.
Для достаточно серьезных проблем можно послать резюме с историей поиска их
причин. Опишите окончательную постановку проблемы. Опишите, каким оказалось
решение, и укажите тупиковые пути, которых стоит избегать. Hазовите всех,
кто помог вам: так вы найдете себе друзей.
Помимо проявления вежливости и информирования, такого рода резюмирующее
сообщение поможет другим при поиске в архиве списка рассылки/дискуссионной
группы/форума точно узнать, какое решение помогло вам, и, значит, может
помочь и им.
Последнее, но немаловажное, - такого рода сообщение помогает всем
участвовавшим в обсуждении получить чувство удовлетворения от того факта,
что проблема закрыта. Просто поверьте нам, что это чувство очень важно для
гуру и экспертов, к которым вы обращались за помощью.
Подумайте, как вы можете предотвратить возникновение такой же проблемы у
других пользователей в будущем. Спросите себя, поможет ли изменение
документации или списка ЧаВО, и если да - пошлите соответствующее изменение
тем, кто поддерживает эти документы.
Как интерпретировать ответы
RTFM и STFW: как понять, что вы серьезно облажались
Есть древняя и священная традиция: если вы получаете ответ "RTFM", значит,
отвечающий думает, что вам стоит почитать руководство (Read The Fucking
---
* Origin: Фидонет - сеть друзей. Будьте дружественнее! (2:5000/228.16)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
