Younghoe.Info (final edition)

세미나 혹은 강의중에 TDD(Test Driven Development)를 배우면서 익힌 교훈은 비단 프로그래밍에서만 효과를 발휘하지 않는다고 주장했다. 두서없이 일하는 모습을 감지했을 때 내 말을 부메랑으로 사용해서 Test-driven development cycle 을 적용해보았다. 무슨 소리냐? 작업범위에 대한 합의를 하기 위해 문서작업을 하려고, 진행 전에 구글 카렌더에 일정을 등록하며 목표와 작업 시간을 설정했다. 그런데 이전에 작업했던 파일을 찾기가 힘들었다. 디렉터리 관리를 엉망으로 해두었기 때문이다. 자연스럽게 디렉터리를 바꿔두려던 나에게 제동을 걸었다. Test-driven development cycle 을 떠올렸다. 지금 당장 목표한 작업(Test case)을 완수(Green Bar)하기 위한 일을 빠르게 먼저 수행하고, 업무 효율을 높이기 위한 일종의 리팩터링에 대항하는 디렉터리 변경은 그 후에 즐기기로 했다. 앗! 이 글도 빠르게 생각을 메모하려고 중간에 치고 들어온 행위(Interrupt)인데, Sepration of concerns의 위력을 믿기로 하자.

(진행중.. 생각의 흐름이 정결하지 못하고, 몸에 뵌 중복처리 습관 잠념 탓에... 인단 무지막지하게 어렵다.)