제목 | 원하는 답을 얻는 방법. | ||
---|---|---|---|
글쓴이 | 전상민 | 작성시각 | 2016/09/26 12:10:27 |
|
|||
10년쯤? 전에 처음 읽어봤던 글인데 생각나서 올립니다. 한 번 읽어보고 질문하면 더 좋은 답변을 얻을 수 있지 않을까 싶어요. 출처 : KLDP http://www.gamecodi.com/board/zboard-id-GAMECODI_Advice-no-29-z-17.htm
0. 명심할것 - 질문하는 상대는 선배입니다. 가끔, 반말이나 통신체등으로 질문하는걸 보는 경우가 있는데, 이것은 예의에 어긋나는 행동입니다. 친근함을 표현하고 싶을지 모르겠지만 보는 사람에겐 기분나쁜 태도가 될 수도 있는겁니다. - 대답하는 사람이 시간이 남아돌아서 대답해주는게 아닙니다. 질문하기 전에 내가 충분히 노력했는지에 대해 다시 생각해보세요. 답변자의 시간의 가치는 상상을 초월하는 가격입니다. - 답변자는 돈을 받고 답변해주는게 아닙니다. 숙제 해결을 묻거나 코드 분석을 의뢰하지 마세요.
1. 제목 짓기. - 질문에 관련된 제목을 적으세요. 간혹, '도와주세요', '살려주세요' 등의 제목을 보는데, 이런건 119게시판에 적으세요.답변자가 클릭해서 본문을 읽는 시간조차 상당한 값어치를 한다는 점을 명심하세요.제목은 짧되 한눈에 무엇에 관한 내용인지에 대해 적어야 합니다. - 답변자가 흥미를 느낄 수 있게끔 적으세요. 답변자가 답변을 적는 경우는 '그 항목에 정통했을때' 와 '그 항목에 관심이 있을때' 입니다. 제목이 모호하거나 제대로 된 문장이 아닐경우엔 무시당할 수 있습니다. - 예시 잘못된 예) '질문좀 할께요', '궁금한게 있어요' 등... 잘된 예) 'float a = 1e-10f가 의미하는 것이 무엇인지 궁금합니다.', '[OpenGL ES] VBO로 교체하고나서 glDrawElements에서 크래시가 납니다.' 등...
2. 상황 설명하기 - 자신이 지향 하는 결과를 적으세요. 대뜸, '여기 모양이 이상한거 같은데 왜 이렇죠?' 등의 질문을 보게 됩니다. 질문자의 입장에서 잘못된 부분이라도 답변자는 전혀 이상하게 생각하지 않을 가능성이 있어요. 자신이 원했던 장면이라던지 기능을 먼저 알려줘야 정확한 답변을 얻을 확률이 높아집니다. - 개발 환경을 서술하세요. 볕이 잘드는지 책상이 너저분한지에 대해 설명하라는게 아닙니다. OS는 무엇을 사용하고, 개발툴은 무엇을 사용하는지, 필요하다면 사양이 어떻게 되는지도 적어줍니다. 특정 개발엔진을 사용한다면, 같은 엔진을 사용하는 사용자가 훨씬 답변하기 쉬워질 거에요.
3. 코드를 보여라! - 프로그래머는 내용보다 코드를 우선 봅니다. 50%에 육박하는 오류의 진실은 오타에 있습니다. 혹은 메서드의 잘못된 사용이 이유가 될 수도 있어요. 이런걸 확인하려면 코드를 보는게 최선입니다. - 의문시 되는 코드를 잘라서 보여주세요. 전체 코드를 다 올려봐야 그것을 읽는 사람의 짜증만 불러올 뿐입니다. 대부분은 코드량에 질려서 되돌아가기를 누를지도 몰라요.한 페이지 내에 한눈에 볼수 있는 양이면 적당할 것 같아요. - 보안상 공개가 불가하다면, 셈플을 작성하세요.코드가 회사 소유라거나, 보안에 관련된 내용이 있을시에는셈플 코드를 작성해서라도 보이세요.다시 말하지만, 프로그래머는 코드가 더 눈에 잘 들어오거든요.
4. 결과도 보여야 한다. - 자신이 실행한 결과 화면을 보여주세요. 그게 숫자가 되었든, 이미지가 되었든 일단 보여보세요. 이는 답변자가 직접 코드를 타이핑하거나 잘못된 점을 찾는 시간을 줄여줍니다. 우리는 답변자를 고생시키려는게 목적이 아니라 답변을 빠르고 정확하게 얻는게 목적인걸 기억하세요. - 에러가 났다면 출력창의 에러를 그대로 복사해서 붙이세요. 대부분의 에러는 출력창의 내용만 가지고도 상황을 알 수 있습니다. 그렇지 않더라도 에러코드를 가지고 해결법을 찾을 수도 있어요.
5. 자신의 노력을 어필하라. - 자신이 검색한 키워드를 나열하세요. 답변자가 동일한 키워드로 검색하는 시간을 줄여줍니다. 혹시 알아요? 마음씨 좋은 선배가 해결을 위한 더 좋은 키워드를 제시해 줄지. - 자신이 시도했던 방법들을 적으세요. 위와 마찬가지로 답변자의 동일한 시도를 줄여줍니다. 간혹 '이렇게 해보세요' 라는 답변에 '이미 시도했었는데요' 등의 되물림 글이 달리는데,그것만큼 낭비가 어디있을까요! - 답변자가 질문자의 노력에 감동할 만큼 적으세요. 질문자가 나열한 노력을 보고는 '아, 저사람은 이것만 알면 잘 할수 있겠다' 라고 생각될때답변이 달릴 확률이 커집니다.
6. 답변에 감사하라. - 원치 않는 답변에도 감사하세요. 질문자의 글을 읽고 답변을 적었다는것 만으로도 답변자는 귀중한 시간을 할애한거에요. 그것이 설령 원하는 답이 아니었더라도 '감사합니다만, 제가 원한건 그게 아니라 ---입니다. 더 좋은 방법이 없을까요?'라는 답변을 달아둔다면, 답변자는 다시한번 시간을 할애해 줄지도 모릅니다. - 키워드만 적어두더라도 감사하세요. '그건 구글신에게 ----로 검색해보세요.' 라는 짧은 답변에 실망할 수도 있습니다만,답변자가 직접 해당 키워드로 검색해보고 답변을 얻을 수 있다고 판단해서 적은것일 확률이 높습니다. 본인도 직접 검색해보고 판단하세요. 그래도 못찾겠다면, 어떤글을 봤는지, 원하는 내용과 어떻게 다른지를 댓글로 남겨두세요. - 무조건 감사하세요. 어떤 글이 달리던지 '감사합니다.' 라는 말을 빼먹지 마세요.
7. 자신의 글을 계속해서 업데이트 하라. - 답글로 계속해서 진행 상황을 적어나가세요. 이는 질문자가 자신의 질문을 항상 모니터링 하고 있으며, 어느정도까지 해결되었는지를 알리는 수단이 됩니다. 답변자는 본 게시글이 아직 유효한지 알수 없기 때문에,아는 내용이라도 질문자가 보지 않을 가능성이 높다고 판단하여 답글을 달지 않을 수 있습니다. - 해결된 문제라면, 해결 방법을 적으세요. 같은 문제로 고민하는 동료에게 도움을 줄 수도 있고,그게 본인이 될 수도 있다는 사실을 상기하세요.(대체로 한번 걸린 함정에 또 걸리기 마련입니다.) 그것이 본인 스스로 해결한 상황도 마찬가지 입니다. 질문이 완료되었다는 표시도 되며,선량한 답변자가 답변을 더 달아야 할까 말까 고민할 필요가 없게 해줍니다. |
|||
태그 | 질문법 | ||
관련링크 |
https://wiki.kldp.org/wiki.php/DocbookSgml/Beginner_QA-KLDP |
||
kaido
/
2016/09/26 14:02:09 /
추천
0
|
변종원(웅파)
/
2018/03/23 10:57:38 /
추천
0
답변자는 질문자가 기술한 내용만 가지고 판단을 할 수밖에 없는데 기본적으로 어디서 왜 그렇게 됐는지 판단하기 위해선 소스와 에러메세지가 필수입니다. 아주 일반적인 상황에선 필요가 없을 수 있으나 대부분의 개발 질문에선 소스와 에러메세지는 필수입니다. 거기에 개발환경과 내가 했던 노력과 지향점이 추가되면 최고의 질문이 되고 적절한 답변을 빨리 얻을 수 있게 됩니다. 시간 날때 남들 질문도 보세요. 댓글이 많이 달리는 것은 다 이유가 있습니다. (거의 99%) |
CI3newbi
/
2022/06/12 23:20:26 /
추천
0
넵
|
- 개발 환경을 서술하세요.
- 자신이 시도했던 방법들을 적으세요.
- 자신이 지향 하는 결과를 적으세요.
그중에서 베스트 3 뽑아보았습니다.
사실 이중에서 3번이 제일 중요한 지도 모릅니다.
간혹 그런 질문도 있어요.
분명 이상하게 문제를 풀려고 하는게 보이는데도, 꼭 그런 방법으로 해결 하려고 질문 하는 경우이죠.
물론 순수한 호기심을 푸는것도 중요하죠.
다만 원하는 결과에 따라서는 현재 만드는 방법보다 더 쉽고 좋은 방법을 제시해 줄수 있는 질문도 더러 보입니다.
업계에선 고집을 버리면 새로운 세계가 열린다고 하죠.