"완벽한 설계에 의해 완벽하게 그려진 UML 하에서 완벽한 문서화와 함께 프로그래밍을 한다.. 그리고 테스트를 한다.. 테스트를 해보니 뭔가 버그가 났다.. 그 버그를 위주로 코드를 수정하고 필요에 따라선 기본 설계를 변경하고 UML 문서도 수정한다.. 무언가 확장해야 할 일이 있을때? 걱정하지 마시라.. 이미 처음의 완벽한 설계에서 이럴 줄 알고 확장가능성을 염두해두고 기본 베이스 클레스를 디자인했거덩.. 우린 이 완벽한 설계에 의해 구조적으로 깔끔하고 모듈화 하여 협업가능한 아름답고 이상적인 프로젝트를 진행하고 있다................"
반면 현실에서는 어떨까?
"처음에 완벽하다고 여겨지는 설계에 의해 UML 을 그리다 보면 일단 시간이 오래 걸린다.. 남들도 이해시키기 위해 친절한 문서화는 필수다.. 테스트를 해보니 시시한 버그야 그냥 고치면 되지만.. 이건 좀 구조적으로 구리다.. 하지만 처음 설계를 엎어버리기에는 좀 꺼림직 해서 그냥 가기로 했다.. 땜빵으로 그 부분을 매우면 전체적으로 바뀔건 별로 없을듯 하다.. 나중에 기획자에게 추가 스팩이 왔다.. 하하 이럴줄 알고 베이스 클레스를 통해 확장가능하도록 미리 생각을 해두었지.. 기획자랑 다른 대화 없이 그냥 스팩문서만을 찬찬히 검토해 보니.. 이건 머 처음 설계했던거랑 딴판이다.. 베이스 클래스는 말 그대로 "아무 이유없이~!" 그냥 거기 존재할 뿐이다.. 구현을 위해서는 "전체 설계"를 유지하기 위해 추가적인 코드가 덕지덕지 붙어나간다.. 현실의 코드는 이상사회가 아니라.. 시궁창같은 현실일 뿐이고 이를 뒤엎으려면 혁명이 필요하다...... 완벽한 설계를 할 수 있는 사람은 정말 전지전능한 The One 만이 가능했던거 같다..라고 후회를 한다.. 우린 The One 이 아니다.... "
그래서 앞으로 이렇게 해보려고 한다......
"기획자와 먼저 커피를 마신다.. 친해진다.... 일어서면 바로 기획자의 모니터가 보인다.. 괜히 가서 말도 걸고 놀기도 한다.. 스팩문서가 만들어질때면 그 스팩에 대해 수시로 이야기를 한다.. 스팩회의때는 요구사항을 명확히 정의하고 그 부분에 관한 구현만 최우선으로 신경쓴다.. 내가 생각하는 확장가능성은 우선 무시한다.. 확장가능성에 대비한 코딩을 하기 보다는 요구사항에 관한 구현이 제대로 이상없이 동작하는것에 신경을 쓴다.. 그리고 항상 구현의 끝에는 어떤 결과물이 버그없이 튀어나오리라는 기대를 한다.. 요구사항을 분석하여 간단한 설계를 한다.. 설계에 맞추어 내가 짜려고 하는 클래스를 가혹하게 테스트 해볼 수 있는 테스트 프로그램을 먼저 작성한다.. 처음에 컴파일 오류가 나던 말건.. 이미 내가 짜려고 하는 클래스가 있다고 가정하고 무자비하게 가혹한 테스트를 먼저 작성해 본다... 버퍼를 넘겨주는것이 있으면 일부러 오버해서 넘겨주기도 하고 값이라면 일부러 이상한 값을 넣어준다.. 척박한 환경이 다 만들어 졌으면 그 곳에서 적응할 수 있는 클레스를 슬슬 짜기 시작한다.. 일단 컴파일 오류먼저 없애기 위해 빈 클래스라도 만들어서 컴파일 오류를 없애보자.. 처음에 짠 테스트를 모두 통과하는 클래스가 만들어졌다면.. 당분간 안심해도 될것 같다.. 우선 버그가 없음직한 하나의 빌드가 완성된 것이다...."
만약 추가 기획이 날아오면 어떻게 될까?.........
"기획자가 새로운 스팩에 관한 이야기를 꺼내기 시작한다... 불안해 하지 않는다...! - . -.. 처음과 마찬가지로 스팩문서를 검토하고 요구사항을 적어놓은 다음 그에 맞추어 기존 코드를 변경한다.. 기존 스팩과 신규 스팩을 아우를 수 있는 클래스 디자인이 요구될 것이다.. 포함관계에서 상속관계로 바꾸고.. 새로운 인터페이스를 추가하고.. 등등.. 새로운 스팩을 포용할 수 있는 새로운 디자인이 만들어지며 그에 맞추어서 코드도 수정된다.. 버그없는 결과물이 어떻게 나오냐고?.... 기존에 만들어 두었던 가혹한 테스트 환경.... 그 척박한 환경에서 새로 짠 클래스가 돌아갈 수 만 있으면 오케이다... 또 하나의 새로운 빌드를 릴리즈하고 별다른 테스트 없이도 쉽게 퇴근할 수 있다!... 퇴근하기 전 릴리즈 했던 버젼은 불과 몇 분 전에 모든 클레스에 관한 풀 테스트를 마친 안정적인 버젼이다..!!"
지금까지 언급했던 내용은 애자일 개발 방법론에서 언급하는 몇몇 요소가 포함된 시나리오이다..
- 디자인 도큐먼트 보다는 서로간의 커뮤니케이션의 가치을 중시하는 사상..
- 테스트 주도적인 개발 방법
- 일일 빌드.. 자동화된 테스트
- 리펙토링..
빠진 개념도 많지만 요즘 그 중에 테스트 주도적인 개발방법의 훈련을 해보고 있다..
생각보다 적응하기 쉽지는 않지만 나름 재미있다..
물론 자신의 코드를 끊임없이 채찍질 해야 하는.. 코더의 변태적인 성향이 한 몫할 수도 있다..
이 글과 관련있는 글을 자동검색한 결과입니다 [?]
