refactoring 과 Unit Test .. 그리고 TDD

이제 조금 있으면 Visual Studio 2005 버젼이 발표되기 때문에, 요즘 C# 전체 Product Unit은 다음 버젼을 위한 준비 작업이 한창이다.

준비 작업은 여러 가지가 있지만, 요즘 가장 스포트 라잇을 받는건 refactoring과 Unit Test 그리고 TDD이다. 3개가 다른거 같지만 사실 하나로 이어진다.

TDD란 Test Driven Development  라는 프로그랭 방법이다. 쉽게 말해, 개발자가 코딩 하는 모든 코드는 우선 테스트 부터 작성 해야 한다는 방법이다. 이렇게 작성하는 테스트를 Unit Test라고 부른다. 뭐 조금 너무 간소하게 요약한것 같긴 하지만. 하여간...

일단 이렇게 Test를 작성하고 나면, 디자인 이나 효율성은 무시 하고 일단 그 Test가 Pass 하도록 코딩을하고, 일단 Test가 pass 하면, Refactoring을 이용해서 디자인을 잡아 나간다는 방식이다.

이 방법은 기존의 프로그램 방법과 많이 달라서, 기존 프로그램밍 방법에 익숙한 개발자들로 붙어 많은 의구심<?>을 자아내게 하는 방법인데, 무엇이 그리 다르냐 하면

일단, 기존은 일단 function 코딩을 먼저 한후에 디버깅을 하고 작동을 하면 테스트를 작성하는 식이 었는데, 이 방법은 그것에 완전 반대다, 우선 테스트를 작성 하고 테스트가 fail 하면, 그 fail을 pass 하게 만들어 가는 방식이다.

둘째는 기존 프로그램밍 방식은 디자인을 먼저 하고, 디자인이 모습을 갖추면 코딩을 하는 방식이었다면, 이 방법은 처음 디자인이 어차피 완벽할수가 없고, 요구 사항은 항상 변하기 마련이므로, 처음에는 기본적인 디자인 - 대충 모습만 갖추는 - 만 하고 TDD로 개발을 시작한 다음 Test가 pass 하는 단계가 되면 (디자인 효율성 다 무시 하고 일단 pass만 되도록),  refactoring을 통해 디자인을 나중에 잡아 가는 방식이다.

세째는 보통 개발자들이 코드를 optimize 하는 방식이 실제 코드를 할때 눈에 띄는 부분에 대해 상시 optimize하는 방식이었다면, 여기서는 refactoring 하는 그 순간까지도 코드의 효율성을 무시 하고 일단 코드가 관리하고 쉽고 판독하기 쉽게 refactoring 한 다음 profiler를 통해 실제 성능이 저하 되는 부분만 optimize 시키는 방식이다.

넷째는 테스트 코드가 실제 코드와 거의 같은 라인 만큼 있어야 된다는건데, 많은 개발자들이 가뜩이나 실제 프로그램을 위한 코딩만 하기도 시간이 벅찬데, 어떻게 그 많은 테스트를 다 코딩해야 하나 때문에 염려를 많이 한다.

하여간, 이런 많은 저항에도 불구 하고, TDD, Unit Test, Refactoring이 스포트 라잇을 받는 이유는 개발 초기 단계에는 기존 보다 시간이 많이 들지 모르나, 일단 테스트들과 코드들이 어느정도 자리 잡히기 시작하면, 기존에 비해 개발 속도가 현저히 빨라진다는것과 버그가 현저히 줄어 든다는것, 끝에 가서는 전체 코드의 디자인이 기존에 비해 훨씬 높다는것이다.

다시 말하면, 개발 방법이 기존 방식과 정 반대 이듯이 효과도 정반대로 나타난다는 것이다, 기존 방법은 개발 초기에는 디자인이 좋으나 시간이 지나감에 따라 디자인이 망가지는데 비해 이와 반대의 효과가 있고, 기존 방법은 개발 초기에는 개발 속도가 빠르나, 시간이 지나감에 따라 개발 속도가 현저히 떨어지는데 이에 반대의 효과가 있고, 기존 방법은 시간이 지남에 따라 라인당 버그 갯수가 현저히 늘어나나, 이방법은 시간이 지남에 따라, 라인당 버그 수가 점점 준다는데 있다.

그럼 실제 TDD를 사용해서 개발된 프로젝트가 있느냐? 일단 우리 PU내에선 MSBuild가 이 방법을 사용해서 실제 위에 말한 효과를 봤다. 아마 그 효과가 꽤 좋아서 요즘 전체 팀으로 푸쉬 하는것 같다.

하여간 그리 하여 요즘 TDD와 Unit Test와 Refactoring에 대해 공부 하는 중이다.

뭐.. 공부 함에 따라 여기에 대해 조금씩 쓸가 한다

그럼 수고.