추상화와 구상화?

 몇일전 아는 지인과 대화중에 깨닭은 점인데,

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

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

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

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

는 이야기라 볼수있다.

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

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

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

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