아주 작은 단위로 일을 쪼개고, 막히는 걸 질문하기 전에 스스로 검증해보자.

요새 켄트백의 테스트주도개발이란 책과 제프앳우드의 코딩호러의 이펙티브 프로그래밍을 보고 있는데,

모두 다 읽지는 않았지만 중요한 이야기를 하고 있어 우선 적어봅니다.

- 테스트를 아주 작은 단위로 작성해나가라.
   일의 단위를 아주 작게 쪼개라는 말을 TDD책을 읽기 전에, 스터디중인 형이 제게 해주었었는데. 근래에 TDD보면서 엄청 공감하고 있습니다. 실제로 업무할 때에도 덤비기 전에 쪼개는 연습을 하려고 하는데 그렇게 하니 막막해보이던 업무들도 정리되는 기분이고 일 자체를 컨트롤 할 수 있더군요.

  - 질문을 하기 전에 그 질문을 잘 정리해보자.
     돈받고 프로그램을 작성한지 3년, 사실 지금도 전 질문을 모호하게 하는 경우가 있습니다. 질문을 받는 사람들이 당혹스러워 하는 경험을 접한적이 있죠. 질문 자체가 핵심을 다른 문장들로 가리고 있어서 말이죠. 헌데 코딩 호러의 이펙티브 프로그래밍에선 고무오리를 얘기하면서 질문전에 스스로에게 검증하는 걸 말하더군요. 사실 질문을 정리하다가 갑자기 해답을 찾는 경우는 종종 경험을 하실겁니다. 보통 전 구두로 질문을 할 때보다 이메일같이 텍스트를 작성하면서 질문과정에서 해답을 얻는 경우가 많습니다.

프로그래밍을 할 때, 우리는 아키텍트를 고려해서 작업을 진행합니다.

꽤 큰 단위로, (보통 기능단위) 업무를 잘라나가면서 작업을 진행하는데

일을 잘게 쪼개지 않으면 이러한 기능단위 자체에 대해서 막막해 하는 경우가 있습니다.

그리고 그 일에 대해 심리적으로 불안하게 접근하죠.

결국 시야가 좁아지게 되는 경우도 생기고, 그러면서 막연히 피하려고 하는 경우도 생깁니다.

그리고 경력이 적고 주변에 마음편히 질문을 할 사람이 생기면 그런 기능 자체에 대한 문의를 하여

아직 코드도 접해보지 않았을테고 문제의 인식 자체를 하지 않은 사람이 곤란하게끔 만드는 경우도 생깁니다.

일을 잘게 쪼개나가면서, 막히는 부분에 대해서는 잠시 쉬면서, 문제에서 한 발자욱 물러나 스스로가 검증하는 시간을 가져보세요. 스스로에게도 뿌듯해할 시간이 생기고, 주변 동료들에게도 좋은 평판을 얻을 수 있겠다 싶네요.

이렇게 적어놓고 전 이제부터라도 좀 실천할 수 있도록 노력해야겠어요. 으으...