Перевод статьи «Five tips to ask better questions».
Всем нам временами случается «застрять» в поисках нужного решения. Когда такое происходит, мы начинаем гуглить, а также задавать вопросы на Stackoverflow, форумах и в сообществах.
Последние пару лет я старался активно помогать «застрявшим» людям в решении их проблем. Постепенно я начал замечать, что умение задавать вопросы не всем легко дается.
Сегодня я хотел бы поделиться пятью советами, которые должны помочь вам научиться лучше формулировать ваши вопросы (а это, в свою очередь, позволит вам получать лучшие ответы).
1. Предоставляйте контекст
Спрашивая о чем-то у людей, помните, что они не настроены на одну волну с вами и вполне могут не знать, о чем вы вообще говорите. Возможно, вы обращаетесь к коллеге, работающему над другой частью функционала, возможно, к интернет-собеседнику, который вообще ничего не знает ни о вас, ни о вашем проекте. В любом случае, вам нужно ввести человека в курс дела.
Мне случалось видеть вопросы в стиле «Почему у меня уведомления не работают?» и «Как исправить баг в макете?». Не имея контекста, на такие вопросы очень сложно отвечать. Поэтому будет полезным написать короткое вступление, где пояснялось бы, какой результат вам нужен и над чем вы вообще работаете. Например, вместо
«Почему у меня уведомления не работают?»
можно написать
«Я работаю над приложением, где реализованы уведомления. Я запрашиваю разрешение пользователя на получение уведомлений и проверяю, что они включены в настройках, но когда я пытаюсь запланировать уведомления, они не доставляются. Есть идеи, почему это может происходить?»
Вторая версия вопроса предоставляет куда больше информации, чем первая, так что любой человек, который захочет вам помочь, сможет понять, о чем вообще речь. Небольшое введение в контекст играет большую роль при постановке вопросов.
2. Расскажите, что вы уже испробовали
Очень часто случается видеть, что автор вопроса довольно хорошо его сформулировал, но последовательно отвергает предлагаемые идеи и решения, потому что уже испробовал их.
В программировании зачастую бывает больше одного способа попасть из точки А в точку Б, поэтому, задавая вопрос, особенно важно упомянуть, какие способы вы уже пробовали. Это сэкономит много времени людям, пытающимся вам помочь, ведь им не придется излагать заведомо неподходящие идеи.
Кроме того, возможно, ваша проблема имеет отношение к какому-нибудь из уже испытанных вами решений.
Представьте, что вы пытаетесь декодировать ответ JSON и вам никак это не удается. Вы вряд ли получите хороший ответ, если зададите вопрос следующим образом:
«Я беру данные из сети и пытаюсь декодировать их в структуру. С получением данных все в порядке, но как мне декодировать JSON?»
Ведь вы уже пытались декодировать ответ! Этот вопрос можно сформулировать иначе:
«Я беру данные из сети и пытаюсь декодировать их в структуру. С получением данных все в порядке, но я не могу декодировать JSON. Я уже попробовал написать custom CodingKeys, но все равно вижу ошибки декодирования».
В этом вопросе по-прежнему недостает некоторой информативности (об этом — в следующем совете), но любой читатель поймет, что человек, задавший вопрос, знает о JSONDecoder и CodingKeys. Другими словами, людям, готовым вам помочь, будет понятно, что речь идет о помощи в поисках бага, а не о том, чтобы научить вас декодировать JSON.
3. Расскажите, какие ошибки вы получаете
Если вы предоставляете людям контекст и сразу говорите, какие решения уже испытаны, вы молодец. Но зачастую желающим помочь все равно нужна будет еще кое-какая информация: сообщение об ошибке. Если человек, помогающий вам, не знает, с какими ошибками вы столкнулись, ему будет сложно помочь вам справиться с проблемой.
Аналогично, если никаких сообщений об ошибках не вылетает, но результат получается не таким, как планировалось, нужно поделиться этим результатом. Представьте, что вопрос сформулирован следующим образом:
«Я пытаюсь декодировать данные JSON в структуру, но получаю ошибку. Есть идеи?»
Первое, что спросит любой желающий помочь, —
«Что за ошибка?»
Чтобы ускорить процесс и повысить качество потенциальных ответов, сразу включите текст сообщение об ошибке в свой вопрос:
«Я пытаюсь декодировать данные JSON в структуру, но получаю следующую ошибку:
Swift.DecodingError.dataCorrupted(Swift.DecodingError.Context(codingPath: [], debugDescription: «The given data was not valid JSON.», underlyingError: Optional(Error Domain=NSCocoaErrorDomain Code=3840 «Invalid value around character 0.» UserInfo={NSDebugDescription=Invalid value around character 0.})))
Есть какие-нибудь идеи, с чем это может быть связано?»
Теперь любой читатель сразу поймет, что проблема НЕ в логике парсинга JSON. Дело в данных, которые вы пытаетесь декодировать. А это очень важная информация, когда вы пытаетесь помочь кому-то. Сообщения об ошибках в консоли Xcode часто содержат важные кусочки информации, указывающие на причины проблемы.
4. Покажите код (и, пожалуйста, в текстовом виде!)
Этот совет применим не всегда, но довольно часто. Если ваша ошибка, вопрос или проблема связаны с уже написанным вами кодом, будет очень полезно приложить этот код к своему вопросу.
Имейте в виду, что люди, читающие ваш вопрос, не горят желанием изучать всю вашу кодовую базу только для того, чтобы понять, о чем вы говорите. Не выкладывайте весь свой код: выделите часть, напрямую имеющую отношение к вопросу. В идеале, нужно прилагать минимальное количество кода, необходимое для воспроизведения проблемы. Иногда сам процесс выделения минимально необходимого количества кода помогает самостоятельно разобраться в проблеме.
Когда делитесь кодом, совершенно нормально заменить какие-то имена, если не хотите выдавать, над чем работаете. Главное, выбирайте хорошие имена. Foo, Bar и Baz это распространенные варианты для примеров кода, но читать код с такими именами просто ужасно.
Также, по возможности, не делитесь кодом в виде картинки. Когда вы прилагаете код, читатель может скопировать его и вставить в своем редакторе, чтобы протестировать или как-то отредактировать. Если вы поделитесь скриншотом, человек ничего подобного сделать не сможет и, скорее всего, не захочет возиться с вашим вопросом.
5. Держитесь ближе к теме
Если вы последовали всем предыдущим советам, у вас уже есть хороший вопрос. Но важно не переборщить, чтобы он не стал слишком длинным и многословным. Не нужно чрезмерно отягощать его подробностями и длинной подводкой. Ваш вопрос должен легко читаться и быть максимально коротким (насколько это возможно без ущерба для информативности). Рассмотрим следующий пример:
«Я получил проект от нашего дизайнера, и в нем есть некоторые странные компоненты пользовательского интерфейса. Если вы посмотрите на прикрепленное изображение, вы увидите панель навигации, картинку, кнопку и текст. Когда я нажимаю на кнопку, текст должен исчезнуть, а затем должна появиться следующая страница. Панель навигации также должна сдвигаться вверх. Все это должно происходить плавно. Как мне сделать нажатие кнопки и переход, предусмотренный дизайнером?»
Может показаться, что я преувеличиваю, но мне встречались вопросы, сформулированные подобным образом. Приведенный выше вопрос можно написать иначе:
«Мой дизайнер предусмотрел анимацию, которая должна запускаться при нажатии на кнопку. У меня есть функция, которая вызывается нажатием кнопки, но я не уверен, как запустить анимацию внутри этой функции. Прилагаю код анимации и button handler».
Во втором варианте вопрос более конкретный и при этом достаточно информативный, чтобы читатель мог понять, из чего вы исходите и какой результат вам нужен.
Итоги
Задавать вопросы может быть непростой задачей, особенно, если английский ваш второй язык. Но я уверен, что советы из этой статьи помогут любому человеку научиться лучше это делать. Чем более продуманно вы сформулируете свой вопрос, тем вероятнее (и быстрее!) получите хороший ответ. Не каждый вопрос требует применения всех пяти советов, но в большинстве случаев вы так или иначе сможете ими воспользоваться.
[customscript]techrocks_custom_after_post_html[/customscript]
[customscript]techrocks_custom_script[/customscript]