남의 숙제(고통?)가 나의 취미(기쁨?)일 수도 있기 때문에 숙제 질문에 대해 관대(나는 이런 거 모른 적이 없다. ㅋㅋ???)한 편입니다만, 이런 건 물어보면 난감합니다.
1. 직접 해 보아야 할 때.
예를 들면, 숙제 제출 파일 형식. 이런 건 과제 내 주시는 분들이 다들 알아서 말해 줄 겁니다. 안 해 줬다면, 직접 물어봐야죠. 질문자 컴, 과제 받는 분 컴, 컴파일 종류 기타 등등에 감점요인까지 겹치면 해 줄 수 있는 대답은 오직 하나입니다. 직접 해 보세요. 다른 예로는 무한루프 질문이 있었던 걸로 기억하는데 그냥 while(true) {} 돌리면 되는 건데, 처음이 컴 나갈까봐 겁나는 건 이해가 가긴 하는데(?), 이것도 결론은 돌려보는 수 밖에 없다는 거죠. 그러다 진짜로 컴 고장 나면 어쩔 수 없는 거구요. 무책임하게 보일 수도 있지만, 진짜 컴이 그 모양이면 그 컴으로 프로그램 짜면 안 되는 거고, 그걸 답변자가 어떻게 알겠습니까? 컴 분해해 봐도 모를텐데.
뭔가 해 봐야되는데 결과가 겁이 나는 경우, 물어보시면 대답은 정해져 있습니다. 해 보세요. 문제 생기면 어쩔 수 없습니다.
(물어보는 글 작성 시간이 돌려보는 경우보다 짧을 경우.. 질문하고 스스로 대답하고 지우시는 분들이 있었슴. 내가 왜 이리 잘 알지?)
2. 질문이 난해할 때
긴 코드 던져주고 뭐가 문제인지 모르겠어요.. 이러면 정말 난감합니다. 도와주는 입장에서는 공부에 도움이 되라고 정성스럽게 대답해 주고 싶은데(그것도 모르다니 나는 알지라고 말하고 싶다 ㅋㅋ), 코드만 보고 답 해 주기 진짜 어렵습니다. 솔직히 실제 프로그램 하다보면 IDE의 도움으로 문제해결하는 경우가 많지 코드 쭉 읽고 뭐가 문제인지 알아서 고치는 경우는.. 저는 없습니다. 코드 정리(refactoring) 같은 거 할 때도 버그 찾는 거와는 경우가 틀려서 읽는 자세가 많이 다릅니다. IDE를 이용하는 법부터 가르쳐줄 수도 없고, 디버깅 방법은 필수입니다. 긴 코드 짜면서 디버깅을 못 한다면 디버깅부터 공부해야 됩니다만, 디버깅부터 공부하세요하면 욕 먹겠죠? 그래서 저는 긴 코드면 보지도 않습니다.
3. 질문을 여러 개로 나눌 수 있을 때
나눠서 질문해 주시기 바랍니다. D&C 나눠서 정복하라. 철칙입니다. 컴퓨터는 세상과 달라서 전부 나눠집니다. 그리고, 나눠져야 합니다. 철칙입니다. 함수? 그거 나눠보자는 거잖아요? 오브젝트, 그것도 세상을 본 떠서 나누면 편하드라.. 뭐 이런 거고 프레임? 이것도 사실 거대해 보이지만 나눠져 있습니다. 컴포넌트? 자체가 그냥 커다란 부품입니다. 프로그램은 나누는 것부터 시작인데, 안 나누고 질문하면 솔직히 좀 그렇습니다.
4. 재밌는 질문, 문제 환영
질문도 재밌는 경우가 있습니다. 제가 요즘 쓰는 건 unity인데 관련 질문 들어오면 자연스럽게 키보드에 손이 가게 됩니다. 관련 분야면 자연스럽게 돕고 싶은 게 사람 마음 아니겠습니까? (그것도 모르다니 초짜군 ㅋㅋ, 난 절대 그런 적이 없었다!!! ???)
답변자 입장에서 한 번 생각해 주세요. 알고있다고 쉽게 대답해 줄 수 있는 재밌는 질문을 기대하겠습니다.(시간이 애매할 때 한 번은 봐 주겠다. ..??)
p.s. 가뜩이나 새글도 없는 게시판에 숙제(떡밥)도 없으면 재미가 없지요.
