提问的智慧（How To Ask Questions The Smart Way）

站务管理 公告与规则 / Announcements & Rules
1

Оригинал: How To Ask Questions The Smart Way

Перевод: Ван Ган<yafrank at 126 dot com>
Время: 26 октября 2013
Содержание

Оглавление

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

Отказ от ответственности

На сайтах многих проектов в разделе «Как получить помощь» есть ссылка на этот текст — это нормально и именно то, чего мы хотим. Но если вы администратор, который добавил такую ссылку, пожалуйста, разместите рядом заметное предупреждение: МЫ НЕ ПРЕДОСТАВЛЯЕМ ПОДДЕРЖКИ ЭТОГО ПРОЕКТА!

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

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

Введение

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

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

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

Хакеры также славятся враждебностью или высокомерием к простым вопросам. На самом деле мы просто безапелляционно игнорируем тех, кто не желает думать и делать домашнюю работу. Такие люди — бездонная яма времени: они только берут, не отдавая ничего взамен. Мы зовём их лузерами (по традиции иногда пишем lusers).

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

Мы (почти все) — волонтёры, отрываемся от своей работы, чтобы помочь. Поэтому безжалостно фильтруем вопросы, особенно похожие на лузерские, чтобы оставить время для «победителей».

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

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

Если всё-таки решили спросить, не будьте лузером. Лучший способ получить быстрый и полезный ответ — выглядеть умным, уверенным и мыслящим человеком, который случайно запнулся на одном конкретном шаге.

(Поправки и предложения присылайте на [email protected] или [email protected]. Это не универсальный этикет: мы отклоняем советы, не связанные с получением технически полезных ответов.)

Перед тем как задать вопрос

Перед публикацией вопроса в почте, новостях или форуме:

  • Поищите в архивах форума.
  • Поищите в интернете.
  • Прочитайте руководство.
  • Прочитайте FAQ.
  • Попробуйте отладить или поэкспериментировать.
  • Спросите знающего друга.
  • Если вы программист — гляньте исходники.

Упомяните, что вы сделали всё вышеперечисленное: это покажет, что вы не паразит. Расскажите, что вы уже узнали — мы любим тех, кто учится на ответах.

Поищите текст ошибки в Google (и в группах Google, и в вебе) — часто сразу находится решение. Даже если нет, фраза «я гуглил вот это, но ничего полезного не нашёл» показывает, где поиск не сработал, и поможет следующим.

Не ждите, что пара секунд поиска решит сложную проблему. Прочитайте FAQ, подумайте. Мы видим, сколько усилий вы вложили: чем больше, тем выше шанс на ответ. Не сыпьте сразу все вопросы — если первый поиск не дал результата.

Лёгкий вопрос получит лёгкий ответ или игнор. Покажите, что думали и старались.

Не задавайте вопроса с ложной посылкой: хакер пошлёт вас лесом, дав «ответ на тот вопрос, который вы задали», а не на тот, который вам нужен.

Никогда не считайте, что вам положен ответ. Вы не платите. Заработайте его: сформулируйте вопрос так, чтобы он стал полезен всему сообществу.

Покажите готовность участвовать: «Куда копать?», «Чего мне не хватает?», «Какой раздел документации читать?» — получают ответы чаще, чем «Напишите пошаговую инструкцию».* Английский — не мой родной язык, извините за возможные орфографические ошибки.

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

Отправляйте вопрос в легко читаемом и стандартном файловом формате

Если вы специально делаете вопрос трудным для чтения, его, скорее всего, проигнорируют. Люди охотнее читают то, что понятно:

  • Используйте обычный текст, а не HTML (отключить HTML несложно).
  • Вложения в формате MIME обычно допустимы, если в них действительно есть содержимое (например, исходный код или патч), а не просто шаблон, сгенерированный почтовой программой (например, дубль письма).
  • Не присылайте письма, где каждое предложение — одна строка, но перенесённая много раз (так трудно цитировать отдельные части). Представьте, что читатель смотрит в терминал шириной 80 символов; устанавливайте перенос строки короче 80 колонок.
  • Но и не форматируйте данные фиксированным переносом (например, лог-файлы или записи сессий). Данные должны идти как есть, чтобы отвечавший был уверен, что видит то же, что и вы.
  • В англоязычных форумах не используйте кодировку «Quoted-Printable» MIME. Она нужна для не-ASCII языков, но многие почтовые клиенты её не поддерживают. Когда она ломается, рассыпанные по тексту «=20» выглядят уродливо, отвлекают и могут исказить смысл.
  • Никогда не рассчитывайте, что хакеры будут читать документы в закрытых проприетарных форматах вроде Word или Excel. Большинство реагируют так же, как если бы кто-то вывалил горячее свиное дерьмо у вашей двери. Даже если могут открыть, делать это ненавидят.
  • Если пишете с Windows, отключите «умные кавычки» (Tools → AutoCorrect → AutoFormat as you type → снимите галку «Straight quotes» с «smart quotes»), иначе в письме повсюду появятся мусорные символы.
  • В форумах не злоупотребляйте смайликами и HTML (если они доступны). Пара смайликов — нормально, но пёстрый цветной текст наталкивает на мысль, что вы неспособны. Избыток смайликов, цвета и шрифтов заставляет выглядеть как хихикающая девчонка. Обычно это плохая идея, если вы хотите получить полезный ответ, а не секс.
  • Если используете графический почтовый клиент (Netscape Messenger, Outlook и т. д.), проверьте, что по умолчанию он шлёт чистый текст без мусора. У большинства есть меню «View source» — используйте его, чтобы убедиться, что в исходнике письма нет лишнего.

Описывайте проблему точно и по существу

  • Тщательно и ясно опишите симптомы.
  • Опишите окружение (железо, ОС, приложения, всё релевантное) с точными версиями («Fedora Core 7», «Slackware 9.1» и т. д.).
  • Расскажите, что вы уже изучили и как это поняли.
  • Перечислите диагностические шаги, которые вы уже предприняли.
  • Укажите любые недавние изменения в конфигурации.
  • Если возможно, дайте способ воспроизвести проблему в контролируемых условиях.
  • Постарайтесь предугадать, что спросят, и подготовьте ответы.

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

Саймон Тэтхэм (Simon Tatham) написал отличное эссе «Как эффективно сообщать об ошибках» — настоятельно рекомендую прочитать.

Краткость — сестра таланта

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

Три причины:

  1. Вид ваших усилий повышает шанс получить ответ.
  2. Упрощённая задача даёт более полезный ответ.
  3. В процессе сведения к минимуму вы можете сами найти решение.

Не спешите кричать «баг!»

Когда сталкиваетесь с проблемой, не объявляйте «я нашёл баг», пока не будете очень уверены. Подсказка: если у вас нет патча или теста регрессии, вы, скорее всего, не уверены. Для документации то же: если нашли «баг», будьте готовы предложить исправленный текст.

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

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

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

Унижение не заменяет домашнюю работу

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

Не тратьте время примитивными приёмами; чётко опишите контекст и суть вопроса — это гораздо лучше.

Если форум имеет раздел для новичков — пишите туда, но всё равно не унижайтесь.

Описывайте симптомы, а не догадки

Говорить «вот что вызвало проблему» бесполезно (если бы вы знали, зачем спрашивать?). Приводите только исходные симптомы, пусть другие диагностируют. Если всё же хотите изложить теорию, чётко отметьте, что это лишь догадка.

Глупо:

При сборке ядра постоянно вылетают SIG11, подозреваю обрыв дорожки на материнке, как лучше найти?

Умно:

Самопальный ПК (K6/233, FIC-PA2007 чипсет VIA Apollo VP2, 256 Мб Corsair PC133) через ~20 мин после включения при сборке ядра выдаёт SIG11, первые 20 мин — никогда. Перезагрузка не сбрасывает часов, ночная выключение — да. Память менял — не помогло, лог прилагаю.

Помните: «Все диагносты из Миссури». Им нужно увидеть исходные данные, а не ваши выводы. Покажите.

Излагайте события по хронологии

Что происходило прямо перед сбоем — главная подсказка. Точно опишите, что делали вы, комп и ПО. Для командной строки полезен лог (например, script), приведите 20 строк вокруг сбоя.

Если у программы есть ключ отладки (-v), включите его. «Много» ≠ «хорошо». Если лог велик, сначала кратко опишите проблему, затем изложите хронологию.

Описывайте цель, а не шаги

Если спрашиваете «как сделать», сначала скажите, чего хотите достичь, потом — какие шаги уже предприняли.

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

Глупо:

Как заставить цветопикер выдавать hex-RGB?

Умно:

Хочу заменить палитру картинки своими цветами; единственный способ, который я знаю — редактировать слоты вручную, но цветопикер не выдаёт hex-RGB.

Второй вариант позволяет предложить более подходящий инструмент.

Не требуйте ответа в привате

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

Запрос «ответьте мне в личку» прерывает этот процесс. Не требуйте — пусть решает отвечающий. Если он уходит в приват, обычно считает вопрос слишком плохим.

Исключение: если уверены, что вопрос вызовет лавину однотипных ответов, напишите: «Пишите мне в личку, я подведу итог». Главное — сдержите обещание.

Будьте конкретны

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

Чётко скажите, чего хотите (указать направление, прислать код, проверить патч и т. д.) — тогда шанс получить полезный ответ выше. Это задаёт верхнюю границу времени, которое эксперт потратит.

Представьте: много знаний, мало времени. Чем меньше времени вы просите, тем больше вероятность ответа.

Не «объясните X», а «подскажите, где найти хорошее описание X». Если код не работает, попросите указать, где ошибка, а не исправьте за меня.

Вопросы о коде

Не просите отладить сотни строк, не указав, с чего начать. Пост с «вот 300 строк, не работает» проигнорируют. Выложите 30 строк и уточните: «после строки 7 ожидалось , а выводится ».Очень вероятно, что вы получите ответ.

Наиболее точный способ описать проблему в коде — предоставить минимальный воспроизводимый пример. Что такое минимальный воспроизводимый пример? Это демонстрация проблемы, содержащая ровно столько кода, сколько необходимо для воспроизведения нежелательного поведения. Как создать минимальный воспроизводимый пример? Если вы знаете, какая именно строка или фрагмент вызывает проблему, скопируйте её и добавьте минимум окружающего кода, достаточного для создания полного примера (достаточно, чтобы исходный код был принят компилятором, интерпретатором или любой другой программой, которая его обрабатывает). Если вы не можете локализовать проблему до конкретного фрагмента, скопируйте весь исходный код и удалите те части, которые явно не связаны с проблемой. Чем меньше минимальный воспроизводимый пример, тем лучше (см. «Краткость — сестра таланта»).

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

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

Не задавайте вопросы в стиле «сделайте за меня домашку»

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

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

Убирайте бессмысленные просьбы

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

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

Не помечайте вопрос как «срочный», даже если он для вас таковым является

Это ваша проблема, а не наша. Утверждение «срочно» скорее всего сыграет против вас: большинство хакеров просто удалят такое сообщение, посчитав его грубым и эгоистичным попыткой получить приоритетное внимание. Кроме того, слово «срочно» может активировать спам-фильтры, и потенциальные помощники даже не увидят ваш вопрос!

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

Конечно, это рискованно: то, что вас взволнует, может не произвести впечатления на хакеров. Например, вопрос с МКС будет воспринят нормально, но попытка привлечь внимание к «спасению пушистых тюленят» вызовет лишь раздражение.

Если вам кажется, что это невероятно, прочитайте остальной текст ещё несколько раз, прежде чем что-то публиковать.

Вежливость всегда к месту

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

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

Тем не менее, если вы уже чётко описали техническую проблему, вежливость увеличит шансы на полезный ответ.

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

После решения проблемы добавьте краткое резюме

Когда проблема решена, отправьте короткое сообщение всем, кто помогал, с описанием, как всё получилось, и снова поблагодарите. Если вопрос обсуждался в публичном списке рассылки или форуме, туда же и добавьте.

Лучше всего ответить в ту же ветку, с темой «[РЕШЕНО]» или «[ГОТОВО]». Это поможет другим понять, что вопрос закрыт.

Сообщение не обязано быть длинным. Даже просто: «Привет — оказалось, что кабель был повреждён! Спасибо всем!» — уже лучше, чем ничего.

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

Такое сообщение поможет другим найти решение в архивах и даст ощущение завершённости тем, кто помогал.

Как интерпретировать ответы

«RTFM» и «STFW»: как понять, что вы облажались

Если вам ответили «RTFM» («Читай, чёрт возьми, мануал»), это значит, что вы должны были самостоятельно прочитать документацию. И, скорее всего, вы действительно должны.

Младший брат RTFM — это «STFW» («Поищи, чёрт возьми, в вебе»). Это значит, что вы должны были самостоятельно воспользоваться поиском. (Более мягкая версия: «Google — твой друг!»)

Вас могут попросить также поискать в архивах форума. Не рассчитывайте на это — лучше сделайте это заранее.

Такие ответы означают:

  • Информация легко найдена.
  • Вы больше научитесь, если найдёте её сами.

Не обижайтесь. По меркам хакеров, тот, кто ответил, уже оказал вам уважение.

Если всё ещё непонятно

Не спрашивайте сразу: «А что это значит?» Сначала попробуйте разобраться самостоятельно с помощью тех же инструментов. Если не получается — покажите, что вы уже поняли.

Плохо: «Что такое X?»
Хорошо: «Я прочитал мануал, X упоминается только с ключами -z и -p, но не сказано, как его сбросить. Что я упустил?»

Как реагировать на грубость

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

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

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

Чего не стоит спрашивать

Примеры плохих вопросов и то, что о них думают хакеры:

  • Где найти программу X?
  • Как сделать Y с помощью Z?
  • Как настроить приглашение shell?
  • Можно ли конвертировать документы AcmeCorp в TeX через Bass-o-matic?
  • У меня не работает {программа, конфиг, SQL}
  • Помогите с Windows
  • У меня не работает программа, виноват системный инструмент X
  • Не устанавливается Linux
  • Как взломать пароль root / украсть права оператора / прочитать чужую почту?

Ответы:

  • Где найти программу X?

    Там же, где и я — в поисковике. Ты вообще умеешь в Google?

  • Как сделать Y с помощью Z?

    Если ты хочешь решить Y, не спрашивай про Z. Ты не понимаешь ни Z, ни Y. Разберись сначала.

  • Как настроить приглашение shell?

    Если ты умён enough, чтобы спросить, ты умён enough, чтобы RTFM.

  • Можно ли конвертировать…

    Попробуй. Если не получится — вернёшься.

  • У меня не работает {программа, конфиг, SQL}

    Это не вопрос. Я не телепат. Мне плевать.

  • Помогите с Windows

    Удали Windows, поставь Linux или BSD.

  • У меня не работает программа, виноват системный инструмент X

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

  • Не устанавливается Linux

    Мне нужен физический доступ к твоему компьютеру. Иди в местный LUG.

  • Как взломать…

    Ты мерзавец. А если ты хочешь, чтобы тебя этому научили — ты ещё и идиот.

Хорошие и плохие вопросы

Плохо: Где найти что-то про Foonly Flurbamatic?
Хорошо: Я гуглил «Foonly Flurbamatic 2600», но ничего не нашёл. Где можно найти документацию по программированию?

Плохо: Исходники не компилируются, всё говно!
Хорошо: Исходники не компилируются под Linux 6.2. FAQ не помог. Вот лог компиляции. Что я делаю не так?

Плохо: Помогите с материнской платой!
Хорошо: Я попробовал X, Y, Z на S2464 — не работает. Потом A, B, C. Вот странное поведение при C. Что ещё можно проверить?

Если не получается ответа

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

Как лучше отвечать

  • Будьте добры.
  • Новичкам — в личку.
  • Не уверены? Скажите это.
  • Не мешайте, если не помогаете.
  • Задавайте уточняющие вопросы.
  • Указывайте на документацию.
  • Давайте хорошие ответы, не костыли.
  • Отвечайте на вопрос, а не на тот, который вы придумали.
  • Помогите сообществу: улучшайте документацию.
  • Покажите процесс, а не только результат.### Соответствующие ресурсы

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

Когда вы выпускаете программное обеспечение или патчи, постарайтесь следовать Практике выпуска программного обеспечения.

Благодарности

Эвелин Митчелл (Evelyn Mitchell) предоставила несколько примеров глупых вопросов и вдохновила на написание раздела «Как лучше отвечать на вопросы», Михаил Рамендик (Mikhail Ramendik) внёс ряд особенно ценных предложений и улучшений.

1 лайк
基于STM32的同步整流Buck-Boost数字电源 开源
LCD1602 I2C模块无法显示字符
这样设计没问题吧，可以直接画PCB了吗？