Waterbear

좋은 질문은 어떻게 하나요? (How do I ask a good question?) 본문

스크랩

좋은 질문은 어떻게 하나요? (How do I ask a good question?)

노간 2019. 8. 19. 11:55

원문링크

https://stackoverflow.com/help/how-to-ask

 

How do I ask a good question? - Help Center

Stack Overflow | The World’s Largest Online Community for Developers

stackoverflow.com

(이 글은 스텍오버플로우 Help Center의 좋은 질문 하는 법에 대한 답변글입니다.)

 

How do I ask a good question?


We’d love to help you. To improve your chances of getting an answer, here are some tips:

> 우리도 당신을 돕고 싶습니다. 답변을 얻을 가능성을 높이기 위해서 몇 가지 팁이 있습니다.

Search, and research

> 검색하고, 또 검색하세요.

 

...and keep track of what you find. Even if you don't find a useful answer elsewhere on the site,

> 그리고 당신이 찾는것을 파악하세요. 만약 사이트 다른 곳 어디에서도 당신이 찾는 유용한 답변이 없어도

including links to related questions that haven't helped can help others in understanding how your question is different from the rest.

> 도움이 안된 비슷한 질문의 링크를 첨부하세요. 다른 사람들이 당신의 질문이 나머지와 어떻게 다른지 이해하는데 도움이 됩니다.

 

Write a title that summarizes the specific problem

> 구체적인 문제를 요약한 제목을 쓰세요.

 

The title is the first thing potential answerers will see, and if your title isn't interesting, they won't read the rest. So make it count:

제목은 답변자들이 잠재적으로 처음 보게 되는 것입니다. 그리고 만약 당신의 제목이 흥미롭지 않다면 그들은 나머지를 읽기 원하지 않을겁니다. 그래서 의미있게 만드세요.

 

  • Pretend you're talking to a busy colleague and have to sum up your entire question in one sentence: what details can you include that will help someone identify and solve your problem? Include any error messages, key APIs, or unusual circumstances that make your question different from similar questions already on the site.

  • > 바쁜 동료에게 말한다고 상상하고 당신의 모든 질문을 한 문장으로 요약해야 합니다: 어떤 세부사항을 포함시키는게 누군가가 당신의 질문을 식별하고 해결하는데 도움이 될까요? 어떤 에러 메세지, 중요 API 또는 비 정상적인 상황들을 포함시키는게 당신의 질문을 이미 사이트에 올라온 비슷한 질문들과 다르게 만듭니다.
  • Spelling, grammar and punctuation are important! Remember, this is the first part of your question others will see - you want to make a good impression. If you're not comfortable writing in English, ask a friend to proof-read it for you.

  • > 철자, 문법 그리고 구두점은 중요합니다! 기억하세요, 이건 당신의 질문에서 다른이들이 보는 첫번 째 부분입니다 - 좋은 인상을 남기고 싶다면. 만약 당신이 영어로 글을 쓰는게 불편하다면 친구에게 검토를 해달라고 부탁하세요.
  • If you're having trouble summarizing the problem, write the title last - sometimes writing the rest of the question first can make it easier to describe the problem.
  • > 만약 질문을 요약하는데 문제가 있다면, 제목을 가장 나중에 쓰세요 - 때로는 나머지 질문을 먼저 쓰는게 문제를 묘사하는걸 쉽게 만들기도 합니다.

Examples:

  • Bad: C# Math Confusion
  • Good: Why does using float instead of int give me different results when all of my inputs are integers?
  • Bad: [php] session doubt
  • Good: How can I redirect users to different pages based on session data in PHP?
  • Bad: android if else problems
  • Good: Why does str == "value" evaluate to false when str is set to "value"?

 

Introduce the problem before you post any code

> 어떤 코드를 올리기 전에 문제를 설명하세요.

 

In the body of your question, start by expanding on the summary you put in the title.

> 질문의 내용을 쓸때는, 당신이 제목에서 요약했던 내용을 확장하는걸로 시작하세요.

Explain how you encountered the problem you're trying to solve, and any difficulties that have prevented you from solving it yourself.

> 당신이 해결하려는 문제에 어떻게 직면했고, 스스로 해결하는걸 막는 어려움들이 무엇인지 설명하세요.

The first paragraph in your question is the second thing most readers will see, so make it as engaging and informative as possible.

> 질문의 첫번째 문단은 답변자들이 두번 째로 보게되는 것입니다, 그렇기 때문에 가능한 흥미롭고 유익하게 만드세요.

 

Help others reproduce the problem

> 다른사람들이 재현할 수 있게 하세요.

 

Not all questions benefit from including code.

> 모든 질문이 코드를 포함한다고 좋은 건 아닙니다.

But if your problem is with code you've written, you should include some.

> 그러나 당신의 문제가 스스로 작성한 코드에 있고, 그것을 포함해야만 한다면.

But don't just copy in your entire program! 

> 전체 프로그램을 그냥 복사해놓지 마세요!

Not only is this likely to get you in trouble if you're posting your employer's code, it likely includes a lot of irrelevant details that readers will need to ignore when trying to reproduce the problem. 

> 이게 당신 고용주의 코드를 올려서 당신을 곤란에 빠트리게 할 공산이 있을 뿐만 아니라, 읽는사람이 프로그램을 재현 해보려 할 때 무시해야 할 필요가 있는 관계 없는 세부사항을 포함 할 가능성이 있습니다.

 

Here are some guidelines:

> 여기 가이드라인이 있습니다:

  • Include just enough code to allow others to reproduce the problem. For help with this, read How to create a Minimal, Complete, and Verifiable example.
  • > 다른사람이 프로그램을 재현할 수 있을 정도의 코드만 포함하세요. 이것을 도움받기 위해서, "최소화된, 완전한, 검증된 예제를 만드는 방법."(링크)을 읽으세요.
  • If it is possible to create a live example of the problem that you can link to (for example, on http://sqlfiddle.com/ or http://jsbin.com/) then do so - but also copy the code into the question itself.Not everyone can access external sites, and the links may break over time. Use Stack Snippets to make a live demo of inline JavaScript / HTML / CSS.
  • > 만약 링크로 라이브 프로그램을 만들수 있다면(예를 들어 sqlfiddle이나 jsbin같은 사이트) 그렇게 하십시오. 하지만 코드 또한 질문에 복사해 넣어야 합니다. 모두가 외부 사이트를 접속하지는 않습니다. 그리고 시간이 지나면 링크가 깨질 수도 있습니다. 내부에서 JavaScript, HTML, CSS의 라이브 데모를 만들려면 Stack Snippets를 사용하십시오.
  • DO NOT post images of code, data, error messages, etc. - copy or type the text into the question. Please reserve the use of images for diagrams or demonstrating rendering bugs, things that are impossible to describe accurately via text.
  • > 코드나 데이터 에러메세지의 이미지를 올리지 마십시오 - 텍스트를 질문에 복사하거나 타이핑 해서 넣으십시오. 이미지의 사용은 도표나 랜더링 버그를 입증하기 위해 유보하십시오. 이런것들은 텍스트를 통해서 정확하게 묘사하기 어려운 것들입니다.

 

Include all relevant tags

> 모든 연관있는 태그를 포함시키세요.

 

Try to include a tag for the language, library, and specific API your question relates to.

> 당신의 질문과 관계있는 언어, 라이브러리, 구체적인 API의 태그를 포함하도록 해보세요.

If you start typing in the tags field, the system will suggest tags that match what you've typed - be sure and read the descriptions given for them to make sure they're relevant to the question you're asking! See also: What are tags, and how should I use them?

> 태그 필드를 쓰기 시작하면, 시스템이 당신이 적은것과 일치하는 태그를 제안할 겁니다. - 명심하세요, 그것들이 당신이 물어본 질문과 관계가 있는지 확실히 하기위해 주어진 설명을 읽어보세요. "태그는 무엇이고 제가 어떻게 사용해야 합니까?"(링크) 또한 보세요.

 

Proof-read before posting!

> 게시하기 전에 검토하세요!

 

Now that you're ready to ask your question, take a deep breath and read through it from start to finish.

> 이제 질문을 할 준비가 되었습니다, 깊게 숨을 쉬고 처음부터 끝까지 꼼꼼히 읽어보세요.

Pretend you're seeing it for the first time: does it make sense? 

> 처음 읽어본다고 생각하세요: 말이 됩니까?

Try reproducing the problem yourself, in a fresh environment and make sure you can do so using only the information included in your question.

> 스스로 문제를 재현해 보려고 해보세요, 새로운 환경에서 그리고 오직 당신의 질문에 포함된 정보만을 사용해서 할 수 있는지 확실히 해보세요.

Add any details you missed and read through it again. Now is a good time to make sure that your title still describes the problem!

> 세부사항이나 당신이 놓친부분을 추가하고 다시 꼼꼼히 읽어보세요. 이제 당신의 제목이 여전히 문제를 잘 요약하고 있는지 점검하기 좋은 기회입니다!

 

Post the question and respond to feedback

> 질문을 게시하고 피드백에 응답하세요.

 

After you post, leave the question open in your browser for a bit, and see if anyone comments.

> 올린 이후에, 당신의 브라우져에 질문을 잠시 열어두고 누군가 코멘트를 남기는지 보세요.

If you missed an obvious piece of information, be ready to respond by editing your question to include it.

> 만약 명백하게 정보의 일부를 놓쳤다면 그걸 포함해서 수정할 준비를 하십시오.

If someone posts an answer, be ready to try it out and provide feedback!

> 누군가 답변을 올렸다면, 그걸 시도하고 답변에 대한 피드백을 할 준비를 하십시오!

 

Look for help asking for help

In spite of all your efforts, you may find your questions poorly-received.

> 당신의 노력에도 불구하고 당신의 질문의 평판이 좋지 않을수도 있습니다.

Don't despair! Learning to ask a good question is a worthy pursuit, and not one you'll master overnight.

> 절망하지 마세요! 좋은 질문을 하는법을 배우는것은 가치있는 일입니다. 그리고 하룻 밤 사이에 마스터하는 사람은 없습니다.

Here are some additional resources that you may find useful:

> 여기 당신이 유용하게 찾을만한 몇 가지 추가자료가 있습니다.

 

 

단어


keep track of 추적하다, 기록하다, 파악하다
rest 나머지
make it count 의미있게 만들어라
sum up 요약하다
unusual circumstance 드믄 상황
punctuation 구두점
proof-read 검토, 교정
prevent 막다
engaging 매력적인
reproduce 복사하다, 재현하다
is this likely to ~하기 쉽다, ~하기 십상이다
irrelevant 상관 없는
reserve 예약하다, 보류하다
accurately 정확히
via 통해서
be sure 명심해라
read through 꼼꼼히 읽다
a worthy pursuit
가치있는 일 (가치를 추구하는 일)
not one  아무도 (=no one)
overnight  밤 사이에, 하룻밤 동안

 

 

 

0 Comments
댓글쓰기 폼