'구상화'에 해당되는 글 2건

  1. 2007.12.08 추상화와 구상화2
  2. 2007.12.07 추상화와 구상화?

추상화와 구상화2

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

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


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

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

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

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


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

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

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

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

..계속..
Trackback 0 : Comment 0

추상화와 구상화?

Trivia 2007.12.07 00:32
 몇일전 아는 지인과 대화중에 깨닭은 점인데,

추상화와 구상화의 범위에 대한 이야기였다.

...omitted...
최상의 아키텍쳐가 걍 그림만 그리는것이 아니다. 오히려 그런 사람들에게는 말단의 코딩 실력까지
상당한 수준이 되어야만 한다. 자신의 선 하나가 실제로 구현될 것 까지 예상을 하며 큰 그림을 머리속에
수행시키고 디버깅하고 검증할 수 있는 사람만이 전체 그림을 그릴 수 있다.
...omitted...


(*겐도사마의 재림:코드를 잘뽑아내고싶은가 그럼 컴퓨터를버려라 에서 6번째 단락)

 즉 어느 아키텍쳐는 추상화 수준을 자신이 구현하고자 하는 기능의 동작코드까지 단숨에 끌어 내릴수 있어야 한다.

는 이야기라 볼수있다.

 하지만 반대로 그 지인은 전체 프로젝트에서 아키텍트가 커버할수 있는 범위가 있다고 했다.
예를 들면 프로젝트란 현실세계의 비지니스 및 구현대상을 적절히 추상화시켜 구상화하는 작업이라
볼 수 있다.  하지만 프로젝트에서 한사람이 감당 할 수 있는 추상화 범위의 한계가 있기 때문에 추상화의
레이어를 나누어 담당하게한다.
 그 중에서 가장 윗부분의 추상화 레이어를 담당하는사람이 아키텍트가 되고, 그 가장 아랫부분을 담당하는
사람이 실제 코딩을 담당 한다는 말이다.

 내 생각에도 인간이 감당할 수 있는 추상화의 범위가 있어서 프로젝트가 일정 규모를  넘어선다면
실제 구현되는 코딩까지 생각하는것은  무리라고 생각된다 , 때문에 큰 프로젝트의 경우에는 데이타베이스
전문가, 분산시스템 전문가, 비지니스분석 전문가 등등의 역활에 맞는 전문 분야의 사람들이 모여 하나의
시스템을 설계한다. 이러한 레이아웃에 따라 대상을 구현하는 사람들이 있고 이 안에서(정해진 기능의 안에서)
적절한 추상화를 통해 패턴화된 코딩을 만들어내는 등의 범위가 정해지게된다.
 즉 한사람이 모든것을 그려가며 설계하는 것은 불가능에 가깝다.

p.s1 물론 이러한 추상화에서도 하위 레이어와 맞지않는 구멍이란게 존재할수있는데, 어느 올바른 추상화를
       이끌어 내느냐는 그사람의 능력이되고 또 그 능력은 하위 시스템에 대한 구현경험이 도움이 될 수 있겠다.

p.s2  연구 결과에 의하면 밀러의 매직 넘버라고 해서 인간이 평균적으로 한번에 기억할수 있는
        최대개수가 7개라고 한다.때문에 이에 맞추어 클래스의 메소드 수는 7개를 넘어서지 말아야한다라든지
        파라메터 ,변수의 개수를 7이하로  조절하는 구현 지침이 있다.
Trackback 1 : Comment 0