어떻게 우리 팀의 XP가 실패했는가?

115708 어떻게 우리 팀의 XP가 실패했는가? 125303 2007-08-10T18:01:28Z http://reiot.springnote.com/pages/115708 2007-04-11T09:40:35Z <div id="toc" style="border: 1px solid tan; padding: 2px 10px 0px; background-color: rgb(255, 255, 250);"><strong>목차</strong> <hr /> <ol> <li style="margin-left: 1em;"><a href="#toc_1" title="toc_1" class="external">잘못된 테스트 프로젝트 설정</a></li> <li style="margin-left: 1em;"><a href="#toc_2" title="toc_2" class="external">중복 코드의 미제거</a></li> <li style="margin-left: 1em;"><a href="#toc_3" title="toc_3" class="external">UnitTest 라이브러리의 기능 부족</a></li> <li style="margin-left: 1em;"><a href="#toc_4" title="toc_4" class="external">PairProgramming 의 실패</a></li> <li style="margin-left: 1em;"><a href="#toc_5" title="toc_5" class="external">귀차니즘</a></li> </ol> </div> <p>붐붐차차 프로젝트는 처음부터 “XP를 한번 연습해본다”라는 기치를 내걸고 시작했다. 개발 초기 3-4개월동안은 별 문제없이 흘러갔지만, 7-8 개월이 지난 이후부터 지금까지, 테스트 코드는 더이상 유지보수되지 않고 있다. 과연 무엇이 문제였을까? 그리고 다음번 프로젝트에서도 XP 를 성공적으로 도입할 수 있을까?</p> <p> </p> <h2>잘못된 테스트 프로젝트 설정<sup class="tocAnchorContainer"><a href="#toc_1" title="toc_1" class="anchor" id="toc_1">#</a></sup></h2> <ul> <li>요약 : unittest 의 링킹 시간이 너무 길었다.</li> <li>해결책 : DLL(?)</li> </ul> <p> </p> <p>unittest 라는 프로젝트에서 다른 모든 라이브러리를 테스팅하도록 프로젝트를 구성했다. 테스팅 코드가 적을 때에는 unittest 만 통과하면 OK 이었기 때문에 편리했지만, 점차 테스팅 코드가 많아지면서 링킹해야 할 라이브러리의 개수와 크기가 늘어나게 되었고, 결국 컴퓨터가 버벅거리며 링킹할 동안 인터넷 서핑하는 습관이 생겨버렸다. 작업 효율이 떨어진 것은 당연지사.</p> <p> </p> <h2>중복 코드의 미제거<sup class="tocAnchorContainer"><a href="#toc_2" title="toc_2" class="anchor" id="toc_2">#</a></sup></h2> <ul> <li>요약 : TestingCode 의 중복이 너무 심해서 컴파일 시간이 너무 길어졌고, 리팩토링을 할 때에는 죽어났다</li> <li>해결책 : 중복 코드가 제거되기 전까지는 테스트가 완료된 것이 아니다.</li> </ul> <p> </p> <p>어느 날 소스를 조사해보니, (2만라인이 채 안되는) ProductionCode 보다 TestingCode 가 8배 정도 더 많다는 사실을 발견했다. 물론 이게 문제라는 것은 깨달았지만 아무도 이 부분을 고치지 않고 그냥 지나가버렸다. 시간이 나면 고치겠다는 프로그래머의 전형적인 회피술과 함께. 그리고, 언젠가부터 ‘’시스템 사양이 좀 떨어지는'’ 한 개발자가 점점 UnitTest 를 회피하기 시작했으며, 그다음 체크아웃을 한 개발자가 깨진 UnitTest 를 복구해야 하는 일이 종종 발생하게 되었다. 덕분에 서로가 서로에게 짜증을 내게 되었는데… 그 개발자는 시스템 업그레이드 타령과 함께, 굳이 간단한 건 하지 않아도 무방하지 않느냐..라고 하고, UnitTest 를 복구해야 했던 개발자는 왜 자신이 그걸 대신 복구해야 되느냐고 화를 냈기 때문이다. (물론 이때가 팀웍이 흐트러지고 사기가 저하된 타이밍이기도 했다)</p> <p> </p> <p>그러다가 대규모 리팩토링이 필요해진 시점이 있었다. 그러나, 이미 테스트 코드들이 더이상 손쓸수 없이 거대해졌기 때문에, ProductionCode 를 수정을 하는 시간에 비해 TestingCode 를 리팩토링해나가는 시간이 훨씬 더 많이 들게 되었다. 리팩토링을 완료하고 나자, 다들 UnitTest 라면 손사래를 치며 도망가버렸다.</p> <p> </p> <p>웃긴 것은, Kent Beck 의 TestDrivenDevelopmentByExample 책에서는 ‘'’중복 코드의 제거”’가 Iteration 의 필수 요소로 자리잡고 있었다. 왜 ExtremeProgrammingInstalled 번역서에서는, 이걸 더 강조해주지 않았을까? 쳇!</p> <p> </p> <h2>UnitTest 라이브러리의 기능 부족<sup class="tocAnchorContainer"><a href="#toc_3" title="toc_3" class="anchor" id="toc_3">#</a></sup></h2> <ul> <li>요약 : 특정 테스트를 선택하기 위해서는 항상 재컴파일이 필요했다. 결국, 테스트 시간을 더 길어졌고, 개발자들은 UnitTest 와 더 멀어졌다.</li> <li>해결책 : 선택적인 테스트가 편리한 라이브러리를 사용할 것</li> </ul> <p> </p> <p>CppUnit 과 BoostTest 중, BoostTest 를 선택한 이유는 Visual Studio 7.1 과의 호환성 문제였다. (당시 CppUnit 의 경우 VC 7.1 과 호환되지 않았다) 그러나, 이넘은 내가 원하는 코드만을 테스트한다는 것을, 즉 GUI 방식의 테스트를 지원하지 않았기 때문에, 결국 매 테스트마다 코드를 수정해야 했다. 문제는 특정 테스트를 수동으로 추가/삭제하는 파일이 다른 헤더 파일을 모두 include 하는 main 이라서, 약간만 수정하더라도 컴파일 -> 링킹을 다시 해야 했다는 데 있다.</p> <p> </p> <h2>PairProgramming 의 실패<sup class="tocAnchorContainer"><a href="#toc_4" title="toc_4" class="anchor" id="toc_4">#</a></sup></h2> <ul> <li>요약 : 관용의 부족으로 인한 불화(?)</li> <li>해결책 : 정신을 뜯어고쳐야지!</li> </ul> <p> </p> <p>이 부분은 솔직히 [레이옷]에게 원인이 있다. [레이옷]의 후배이자 동료인 프로그래머와 Pair를 할 때마다 티격태격 했던 것 때문이다. 조금씩 서로의 코드에 대한 관용의 마인드를 키워나가기도 했고, 관계 개선 - 후배에서 동료로 생각을 고쳐먹기 - 을 해보려고 했지만, 잘 되지 않았다. 여전히 지금도 반말 90% 존대말 10% 에다가 틈만 나면 큰소리치고 강압적으로 밀어붙이기를 해대고 있다. ㅡㅡ;</p> <p> </p> <h2>귀차니즘<sup class="tocAnchorContainer"><a href="#toc_5" title="toc_5" class="anchor" id="toc_5">#</a></sup></h2> <ul> <li>요약 : 4-5개월 이후부터 CRC 카드라든지 스토리, 일정 추정, 기립 회의 같은 걸 하지 않았다</li> <li>해결책 : XP 관리자의 마인드가 중요하다.</li> </ul> <p> </p> <p>이 부분 역시 XP 관리자였던 [레이옷]에게 원인이 있다. 처음에는 다들 열정적으로 해나갔지만, 프로젝트가 길어지면서 XP의 핵심 요소들을 하나 둘씩 빠져나가고 마지막까지 남았단 UnitTest 마저도 어쩌다보니 개발자들로부터 폐기처분 당해버렸다. 중간에 문제가 있을 때마다 추스리고 나가야 했지만, 그러질 못했다.</p> <p> </p> <p>see also:</p> <ul> <li><a href="http://xper.org/wiki/xp/_b7_b9_c0_cc_bf_ca">이 글에 대한 김창준씨의 분석</a></li> </ul> http://reiot.com/ http://reiot.com/ 10