추상화와 구상화2

     얼마전 쓴 글 추상화와 구상화에 대해 몇가지 더 떠오른 생각들이 있어서 쓴다.

언젠가 나도 생긴 버릇이지만 조금 짜고 컴파일 하고 돌려본다. 뭐 TDD(Test-Driven Development)에서는 좋은 것일지 모르겠지만 로직이 흐르고 정상적으로 동작함을 기계에게 의존하게 된다. 이것이 지속되다 보면 코드의 흐름을 머리속에서 놓쳐 버린다. 부분부분 분명 뭔가를 받고 뭔가를 토해내고는 있지만 이 시스템이 뭘 하고 있는지에 대한 감은 점점 놓친다.

 이 시스템이 뭘 하고 있는지에 대한 감을 놓치는 이유는 아마 코딩을 하면서 추상화의 수준을 내려갔기 때문에
애초 무엇을 하려고 했는지에 대한 높은 추상화수준의 감을 놓쳐버린게 아닐까?
 즉 정확히 말하면 구상화에 집중함으로서 추상화의 감을 놓쳐버린것이라 볼수있다.

 TDD의 목적은 전 코드의 실행 테스트라기보단 코드의 행위에 대한 테스트를 통해 개발을 주도한다는 말이다.
이러한 착각을 불러일으키는 테스트 주도 개발(TDD)란 이름을 최근 재정의해 BDD(Behavior driven development) 즉 행위 주도의 개발이란 이름으로 바뀌었다.
 무슨 뜻이냐 하면 각각 그 객체및 클래스가 해야할행동을 정의하고 그 행동의 달성을 테스트 함으로서
개발을 주도한다는것이다.
 이것을 인지하고 개발을 한다면 이 클래스가 무엇을 하려던 클래스인지에 대해 놓칠 우려는 적어들것이라
생각된다.

 그리고  몇일전 인용한 문장의

 최상위 아키텍쳐러가 걍 그림 그리는 것 아니다. 오히려 그런 사람들에게는 말단의 코딩실력까지 상당한 수준이 되어야만 한다

 이 부분에 대해 다른 예를 들어본다면 최고 건축 설계가가 건축에 사용되는 톱의 사용법에 대해 상당한 수준이  되어야 할까?

 내 생각은 추상화와 구상화의 관점에서 먼저 구현해야할 행동에 대한 전체적인 그림을 그려야한다. 이것은
높은 추상화의 상태에서 전체적인 틀을 보면서 작업해야한다. 그리고 완성된 각각의 부분에 대해 구상화를
들어감으로서 전체적인 그림이 망가지지 않은채로 자신의 작업 범위내에서 추상화및 구상화 작업에
들어가야한다.

 이것은 BDUF(Big Design Up Front)  과 bottom up의 관점의 이야기인데, XP의 점진적개선과 일반방법론의
큰 디자인으로 부터 시작하는 이야기와 연결된다.

 물론 둘다 장단점이 있겠지만 가장 큰 차이점은 프로젝트의 규모가 일정 범위를 넘어선다면 추상화의 범위를
축소하지 않고서는 전체적인 그림을 보기가 너무 힘들다는것이다.

..계속..