TDD

꽤 진부하면서도, 논쟁거리가 될수도 있지만, 개인적인 경험과 고민 끝에 글을 나누고자 한다. 꽤 스타트업을 기술적, 아키텍팅 쪽을 컨설팅하면서 지켜보아 왔던 경험치를 가지고 말씀 드리는 겁니다.  (물론 삼성이라는 대기업만 다닌 니가 스타트업을 얼마나 잘 알아? 라고 물어보실수 있지만 말랑 스튜디오, 빙글, 이노피아 테크 등 꽤 많은 업체들을 컨설팅하고 이야기를 나누고, 그들을 지켜보온 경험치라고 생각을 해주시면 될듯 합니다)

개발자들에게 TDD의 도입을  물으면 찬반이 매우 명확한 편입니다. 특히 큰 규모의 라이브 시스템을 운영한  웹 개발자 분들은 TDD를 통해 조기에 많은 문제를 잡고, 찐한 경험 이야기를 해주십니다. 100%로 동의합니다. 많은 유저들이 동시에 모여서 나가는 서비스라면 품질이 매우 중요해지고,  돌다리도 두들기고 건너가는 것이 맞습니다.  큰 웹서비스를 경험하신 분 입장에서는 TDD 가 큰 보험이 되며, 그 다음 Step을 넘어가는 좋은 보험이 되죠.

은총알은 없다.

특정 방법론, 전략이 A 상황에서는 좋은 약이 될수 있지만, 모든 상황에  항상 옳다고 할수 있을까요?

어떤 방법론이든, 기법이든 항상 장단이 있습니다. 전달을 할때 꽤 신중하게 전달을 해야 한다고 봅니다. “TDD는 좋다!” , “내가 해본 경험으로서는 정말 보험이 되고 든든한 녀석이다!!”  라고 말을 하지만, 모든 상황에서 적절한 방법인지는 정말 고민을 해봐야 합니다. 정말 크게 이슈가 되었던 Joel과 Bob 삼촌의 TDD 논쟁 사건을 보더라도, Joel쪽에 공감하는 사람도 제법있습니다.  이 논쟁에서 Bob 삼촌의 이야기를 지지하는 사람도 있지만, 아닌 사람도 꽤 많다는 것이죠..

정말 공감가는 글이 있는데,  바로 TDD역시 비용의 문제라는 것이다.  미물님께써 적은신 글을 보고 크게 공감을 하고 있습니다.   바로 비용이라는 측면에서 바라보아야 한다는 것입니다. 또한 지금 xper 에서 논의되고 있는 “TDD 는 죽었다.”  라는 글을 보면 공감할 부분이 꽤 있습니다.

계속 읽기

지난 Rebecca Wirfs-Brock의 Nature of Order I를 이어 그 다음 이야기를 진행하고자 합니다.  혹시 이전 내용을 못 읽으신 분은 링크를 따라  한번 읽어보시길 권해드립니다.

워낙 방대한 내용이라, 섣불리 글이 써지지 않더군요. 철학과 생명체, 사물 (Thing)의 구성 원칙들을 기술하는 것이다 보니, 농업 / 생명 / 건축등 다양한 것을 예로 들어 설명하고 있습니다.  게다가 너무 철학적이어서, 개발자가 읽기에는 지루할수도 있죠. 아직 책을 다 읽지 못했지만, PLoP에서 정리한 노트내용과 NOO를 SW 설계에 빚대어 설명한 논문들 그리고 저의 부족한 경험을 합쳐서 용기를 내어 써 봅니다.

항상 경청하는 자세로 여러분의 피드백을 받겠습니다. 부족한 부분은 말씀해주시고, 더  좋은 의견을 주시면 관련 자료를 더 찾고 공부해서 NOO 데이터를 계속 업데이트할 욕심은 있습니다.

계속 읽기