"Задавайте правильные вопросы" (перевод статьи Dan Abramov)
Перевод статьи https://medium.com/@dan_abramov/asking-good-questions-421f08ee7e5c#.37s05wmy2
Я получаю вопросы по программированию в Twitter, GitHub, по электронной почте и другим каналам. Я пытаюсь ответить на них, как только смогу. В последнее время у меня не было возможности делать это достаточно хорошо, потому что я человек и не могу разорваться.
Для личных вопросов, я использую AMA. Если вы хотите узнать моего любимого покемона, то задайте вопрос или прочитайте мои ответы!
“As a kid I really liked Mewtwo. Now I prefer Ditto.”
Если у вас есть ко мне вопрос в области программирования, то читайте дальше.
Вопрос про “Привет, мир”
Если вы не можете воспроизвести в React пример “привет, мир” или ваш счетчик на Redux не обновляется, когда вы наживаете “+” и вы в замешательстве, вы можете написать мне непосредственно в Twitter.
Я по прежнему призываю вас задавать сначала вопросы на StackOverflow и Reactiflux Discord. Часто замечаю, что написание вопроса делает его более чистым в моей голове и решение его становится очевидным. Но если вы проделали эти шаги и остались в замешательстве, то я безусловно могу быстро взглянуть.
Пожалуйста, убедитесь в том, что вы поделились своими наработками в попытках на GitHub, Gist, или, еще лучше, fiddle перед тем как спросить. Таким образом, мы может сделать взаимодействие быстрым. В противном случае, это может занять много времени для обоих сторон, особенно учитывая разницу в часовых поясах.
У вас более сложный вопрос, чем “привет, мир”? Тогда читайте дальше.
Более сложные вопросы
Если у вас есть какой-то конкретный вопрос (например, что-то не работает) или более сложный, чем запуск “привет, мир”, пожалуйста, сперва опубликуйте его в StackOverflow. Я перестал отвечать на такие вопросы непосредственно в своих сообщениях, потому что все время я получаю тот же самый вопрос и жалею, что не имею ссылки на мой последний ответ на него.
Если вы мне пришлете вопрос в сообщении или упоминании на StackOverflow, я постараюсь взглянуть на него и ответить вам, если я знаю на него ответ. Что приводит меня к следующему пункту.
Как получить положительные голоса
Сложная часть в том, чтобы задать хороший вопрос, это соблюсти баланс между достаточностью и избыточностью деталей. Необходимо, чтобы формулировка вашего вопроса хорошо описывала проблему и звучала универсально, чтобы другие люди нашли его полезным. Просмотр популярных вопросов для любых тегов может дать хорошие идеи того, как это должно выглядеть. Это вызов! Но если вопрос сложно описать, то представьте как должен был бы звучать ответ на него.
Никто не будет тратить 5 минут, чтобы вникнуть в вопрос, только чтобы понять, что пропущена часть кода, которая критично важна для понимания проблемы. С другой стороны, одинаково неприятно вычитывать 500 строчек кода, большинство из которых не относятся к делу.
Для задания хорошего вопроса необходим опыт и внимательность. Со временем они будут становиться лучше. Сейчас достаточно того, что вы прилагаете усилие. Вот как я это делаю.
Изолируйте проблему
Возьмите код, в котором есть проблема, переключитесь на другую ветку и начинайте убирать части, которые не имеют отношения к проблеме. Видите проблему в конкретном компоненте? Отрисуйте только этот компонент на странице. Проблема до сих пор повторяется? Хорошо. Если нет, на начинайте шаг за шагом возвращать удаленные части до тех пор пока вы не увидите тот, который вызывает проблему. Затем изолируйте эту часть.
Далее удалите все несущественные детали из самого проблемного модуля. Убирайте стили, разметку и логику до тех пор, пока проблема повторяется. Ликвидируйте зависимости настолько, насколько возможно. Вы должны получить в итоге абсолютный минимум кода необходимый для воспроизведения проблемы.
Не забудьте регулярно сохранять версии (commit)! В противном случае вы можете удалить слишком много кода, который позволяет воспроизвести проблему (как откатиться назад? Именно). Убедитесь, что вы можете всегда откатиться назад по всей последовательности изменений.
Наконец, попробуйте воссоздать проблему в другом окружении. Удобно, когда вы имеете место для тестирования, наподобие “base fiddle”, где вы используете те же самые библиотеки, как и в основном проекте. Таким образом, вы можете быстро небольшие независимые фрагменты кода и вставить соответствующие части вашего проекта в них. Здесь несколько новых сервисов наподобие jsfiddle, но которые обеспечивают доступ к npm-модулям. В частности, я слышал хорошие отзывы о WebpackBin и ESNextbin. Опробуйте их!
Самое главное, не сдавайтесь слишком легко. Для возникновения каждого вопроса есть причина. Это может быть ошибка, опечатка или просто недоразумение. Утешайтесь мыслью, что проблема существует и отсеивайте возможные проблемы.
Эксперты часто не знаю проблему лучше, чем вы. Чему они научились, это не доверять себе. Они копают все глубже и выискивают тестовый случай даже если ничего очевидно не прыгает в течение нескольких часов. Они знают, что проблема есть и ищут ее скучным, утомительным, но обычно конечным процессом.
Если вы проводите отладку проблему поздно вечером, бросайте это дело и “переспите с проблемой”. Лишение сна повышает шансы сделать ошибки, такие как опечатки и им подобные.
Вы не должны загонять себя до степени отчаяния. Если вы встряли и исчерпали запасы своего терпения в попытках изолирования проблемы, то попросите помощи.
Указание на проекты на GitHub
Если вам не удалось воспроизвести проблему в “песочнице”, то хорошо указать проект на GitHub в вопросе на StackOverflow. Шанс, что вы получите хорошие ответ небольшой, но это стоит попробовать в качестве последнего средства.
Здесь несколько советов, чтобы повысить шанс получить хороший ответ:
- Удалите ненужные файлы из репозитория. Ваш проект должен собираться, но если здесь нужен только один экран, который вы хотите показать людям, то удалите все остальные. Вам еще необходимо подчистить код и удалить лишние части, которые не влияют на воспроизводимость проблемы, даже если вы поделились им на GitHub.
- Убедитесь, что все зависимости указаны в файле package.json. Представьте, что кто-то хочет помочь вам настолько, что готовы клонировать ваш проект, ждать 15 минут пока все зависимости загрузятся и, в итоге, не запустить проект, потому что есть неуказанные зависимости. Чтобы избежать этого, удалите node_modules, запустите npm install у себя и убедитесь, что проект запускается без помех. Если вы забыли какую-то зависимость, добавьте ее в package.json и попробуйте снова до тех пор, пока не заработает.
- Убедитесь, что по команде npm start ваш проект запускается. Вы можете контролировать, что запустится при команде npm start используя поле scripts в package.json. Это может быть просто “start”: “gulp”. Важной частью является то, что человек не должен угадывать ваш сборщик или диспетчер задач. Все эти инструменты должны быть указаны в package.json.
- Не предполагайте, что у других людей установлены глобально Grunt/Gulp/Webpack/Browserify. Вы могли запустить команду npm install -g grunt в какой-то момент, но многие не делают этого или используют другие версии. Используйте скрипты nom так, чтобы вам не пришлось просить людей устанавливать и запускать глобальные команды.
- Сделайте понятную инструкцию для воспроизведения проблемы в README. Это очень важно. Там не должно быть ничего вроде установить, запустить, открыть в браузере и далее не иметь понимания как воспроизвести проблему или что необходимо получить. Вместо этого, требуется указать точную последовательность шагов (например, “npm start, открыть ссылку в браузере, нажать на кнопку, я ожидал X, но получил Y”).
Так есть правильно хорошего этикета: не удалять репозиторий если вы его использовали ссылку на него в вопросе на StackOverflow.
Абстрактные вопросы
Наконец, есть несколько вопросов, на которые я не смогу дать хороший ответ.
“Что лучше, X или Y?”
Если я использовал оба решения (что маловероятно), то я не имею права отвечать на этот вопрос. Даже если я использовал их обоих, максимум, что я могу сделать, это поделиться забавной историей, а не суждением. Мой опыт будет очень специфичным для проекта, над которым я работал. Некоторые вещи, скорее всего, устарели и возможно не могут быть применены к вашему проекту, потому что мы имели разные ограничения и требования.
Другая проблема заключается в том, как вопрос сформулирован. Я всегда чувствую, что человек, который его задает его, пытается избежать технического решения, переложив его на плечи другого (меня в данном случае). Я отказываюсь быть авторитетом и не хочу нести ответственность за выбор других людей. Люди могут сильно переоценить мои знания. Я не сведущ в широком диапазоне вопросов.
“Что вы думаете о X?”
Если я никогда не использовал Х, то у меня нет никакого мнения об этом, кроме “мне нравится” или “мне не нравится”. Ни один не будет полезен для вас и мое мнение может сбить вас с толку при выборе хорошего решения для вашего случая. Ведь в этом случае, у вас имеется больше знаний в данном вопросе, чем у меня.
Если я использовал Х, то у меня больше впечатлений, чем я могу вместить в твит. Я не совсем понимаю, как ответить на такой вопрос в Twitter. Я мог бы написать эссе в ответ, но это быстро превращается в полноценную работу.
Если вы хотите вовлечь меня в дискуссию о Х, то я буду счастлив поучаствовать в ней. Но давайте говорить о чем-то конкретном, а не “мое мнение”.
Мое мнение не интересно. Вместо этого, я хотел бы услышать о вашем опыте его использования.
Наконец, возможно вы создали Х. Это прекрасно! Помогите мне и другим понять, что это и почему вы это создали. Объясните не только как выглядит API, но как и почему вы его используете.
README хорошее место для этого. Ваши твиты для меня потеряются завтра. Как бы я ни хотел помочь, я не понимаю ваш случай достаточно хорошо, так мое мнение не будет сильно полезным для вас. Вместо этого, ищите людей с подобными проблемами и спросите их мнение.
Заключение
Попробуйте поставить себя на место человека, который отвечает на вопрос. Вы можете обнаружить, что на некоторые вопросы невозможно ответить или, что вы могли бы потратить больше усилий на создание вопроса, чтобы получить ответ лучше.
Anton Kanby
Инженер.
Изучаю JavaScript
Нравится React (Redux).
Твиты пользователя @KANBYStudio
