Как задавать вопросы программистам

Независимо от того, занимаетесь ли вы программированием несколько лет или думаете о том, чтобы заняться программированием, важно научиться решать многие проблемы, возникающие при кодировании. Проблема большинства программистов заключается в том, что мы склонны к лени, и, потратив время на документирование вашего кода с понятными комментариями, тем легче нам не только вернуться и исправить свой собственный код, но и помочь другим понять наш код. слишком. Лучший совет по написанию комментариев — это писать комментарии, которые поймет ваше прошлое «я», чтобы ваше будущее «я» через 10 лет тоже поняло!

Признайте, что бороться – это нормально! Бороться — это хорошо, потому что это означает, что мы чему-то учимся. Итак, в следующем разделе мы поговорим о некоторых советах по отладке, которые помогут нам справиться с нашими проблемами. Однако мы не хотим, чтобы вы застряли! Поэтому, если вы уже знаете, как выполнять отладку, и все еще боретесь с этой ошибкой в ​​течение последних 2 часов, вы можете перейти к следующему разделу под названием Как задавать вопросы.

Отладка собственного кода

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

0. Задайте себе вопросы: чего вы ожидали? Что происходит на самом деле? Были ли ваши предположения о вашем коде правильными? Что сообщение об ошибке пытается сказать нам? (если есть)

  1. ПРОЧИТАЙТЕ СВОЙ КОД! Во многих случаях при отладке обычно встречаются опечатки или две, которые просто нарушают функциональность нашего кода, а также, перечитывая наш код вслух, мы можем уточнить, что происходит и почему это происходит, а не ожидаемый результат. Классический метод «Прочитай другу» работает для писателей, так как повторение слов про себя в нашей голове может звучать по-разному, и, поскольку мы печатаем большую часть времени, это тоже может помочь нам. Самый популярный пример — метод резиновой уточки, когда вы можете читать свой код так, как будто пытаетесь объяснить его другу.
  2. Проведите исследование! Существуют сотни, если не тысячи книг по программированию и в 10 раз больше онлайн-ресурсов. Очень вероятно, что кто-то сталкивался с той же проблемой, что и вы, или работал над аналогичным приложением, как и вы. НЕ ПРОСТО КОПИРУЙТЕ, но поймите это и то, как вы можете применить те же самые концепции к своему собственному коду. Если вы будете копировать и вставлять, вы не только ничего не узнаете, но и не узнаете. быть в состоянии понять свой собственный код, в котором вы должны быть экспертом!

Использование панели поиска:

Гугл наш друг! и понимание того, как использовать панель поиска, может помочь нам быстрее находить нужные результаты! А что лучше было узнать, чем закинуть ютуб.

Как задавать вопросы

Но что, если мы не можем решить нашу проблему? Что, если мы все еще боремся? Что ж, если вы застряли на своей проблеме с программированием на несколько часов, пришло время обратиться за помощью. Помните, что программирование — это командный вид спорта! И, несмотря на некоторую конкурентную атмосферу, мы являемся сообществом, помогающим друг другу расти. Лично я люблю помогать людям, когда у меня есть на это время. Однако время — самая важная часть этого предложения. Я вижу во многих формах, сколько вопросов полностью игнорируется из-за размера вопроса, и в большинстве случаев эти вопросы страдают от NIE и TL; DR. Чтобы правильно написать вопрос, должен быть один ответ! Ваша цель как автора вопросов — помочь нам помочь вам! Итак, как вы можете это сделать?

Будьте ясны

Если есть что-то, что я хочу, чтобы вы вынесли из этой статьи, так это вот что. NIE означает "недостаточно информации", и я вижу, что этот тип вопросов чаще всего игнорируется! Это связано с тем, что большинство проблем кодирования запутаны и сложны. Таким образом, высказывание чего-то вроде «У кого-нибудь есть опыт работы с Javascript» или «Почему моя функция не работает» не дает достаточно информации для того, чтобы кто-то мог вам помочь, и даже если есть ответ, это обычно будут короткие ответы, такие как «да» или «Какой язык вы используете?». NIE создает длинные потоки вопросов, чтобы решить одну простую проблему, и отнимает много времени как у вас, так и у людей, которые пытаются вам помочь. Вместо этого мы хотим быть конкретными в отношении вещей, которые мы спрашиваем, и включать в наши вопросы:

  1. Технологии, которые вы используете. Включая номера версий и. версию операционной системы.
  2. Что ожидалось, чего вы пытаетесь достичь — что вы ожидаете, если все сработает.
  3. Релевантные фрагменты кода помогают нам увидеть, что происходит, и даже обнаружить синтаксические ошибки или опечатки, ставшие причиной вашей ошибки. Обратите внимание, что человек, к которому вы обращаетесь за помощью, поскольку, скорее всего, никогда раньше не видел ваш код и, возможно, у него нет времени на сортировку, выбросил всю доску, поэтому хорошо документируйте его! Также может быть полезно связать ваш репозиторий с маршрутом доступа к вашему файлу ("github.com/UserName/Example_Project/App/index.json, строка: 46"). Это не всегда вариант, и вы можете захотеть сделать свой проект более закрытым, но при этом вы можете помочь тем, кто пытается помочь вам, получить прямой взгляд на ваш код и на то, что в нем может быть не так. .
  4. Сообщения об ошибках (если они есть) очень важны для процесса отладки.
  5. Что вы пробовали,объясните, что получилось в результате, и какие ресурсы вы использовали, но это не помогло. Это помогает нам не повторять то, что вы уже пробовали, и найти альтернативное решение.

Редактирование вашего вопроса

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

  1. Профессионализм играет важную роль во многих вещах, которые мы делаем. И это включает в себя уважение времени других людей и то, что они должны прочитать. Мы хотим убедиться, что отправляемый нами вопрос практически не содержит опечаток и имеет смысл. Кроме того, (насколько это очевидно, я думаю, это должно быть) мы должны убедиться, что вещи, которые мы отправляем, подходят для семьи и подходят! Если вы работаете над проектом, который может содержать контент, неподходящий для этих условий, либо пользовательская цензура, либо дайте четкое предупреждение, чтобы те, кто не хочет его видеть, не должны были! Это также может привести к тому, что ваша электронная почта будет помещена в спам, или вы можете быть занесены в черный список, так что просто будьте уважительны. Мы хотим уважать и принимать всех людей в сообществе программистов.
  2. Название разделов и подразделов нашего электронного письма может помочь разбить большое сообщение, которое мы пытаемся отправить. Если ваш вопрос очень сложный, возможно, потребуется выделить разделы полужирным шрифтом, подчеркиванием и курсивом, чтобы помочь читателю быстро просмотреть все, что вы хотите сказать. Людям обычно требуется 15 секунд, чтобы решить, хотят ли они сохранить электронное письмо или удалить его, поэтому четко объясните, чего вы хотите, чтобы, когда у них будет больше времени, они могли по-настоящему взглянуть на вашу проблему и попытаться вам помочь. .
  3. Удалите ненужныеслова и фразы, которые могут сделать ваше сообщение намного длиннее, чем оно должно быть.
  4. TLDR. Как бы мы ни хотели, чтобы это не было отправлено в качестве ответа, мы можем, в свою очередь, отправить TLDR человеку, у которого мы просим помощи. Это должно быть в начале вашего сообщения и давать краткий обзор всего, о чем ваше письмо. Ваш первый абзац, как правило, будет тем, что люди прочитают первым, и он может привлечь или отвлечь внимание людей.

Следующие шаги

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

В конце концов вы должны получить электронное письмо с некоторыми предлагаемыми решениями вашей проблемы. Однако эти решения не всегда работают. Итак, настало время сотрудничества!

If: the proposed solutions don’t work for you, simply show them that you tried what they suggested, any error messages, and anything you were inspired by since you posted the questions.

Else: their solution worked. Victory! Make sure that you respond to the answer saying that “it worked”, so that we can recognize that your problem no longer needs solving.

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

Ресурсы:

https://www.youtube.com/watch?v=R0DQfwc72PM

https://docs.microsoft.com/en-us/visualstudio/debugger/debugging-absolute-beginners?view=vs-2019

https://www.propublica.org/nerds/how-to-ask-programming-questions

https://codingkilledthecat.wordpress.com/2012/06/26/how-to-ask-for-programming-help/

https://codereview.stackexchange.com/help/how-to-ask

https://mattgemmell.com/what-have-you-tried/

https://www.cyberdefinitions.com/definitions/NEI.html#:~:text=NEI%20means%20%22Not%20Enough%20Information, желает%20to%20уточнить%20a%20point.

https://exclusive.multibriefs.com/content/5-ways-to-avoid-the-tldr-curse#:~:text=1., они%20просматривают%20%20заголовок%20.