뛰어난 아키텍트는 복잡도를 최소한으로 줄일 수 있어야 하며, 단단한 기본 구조를 취하면서도 급변하는 상황에 적절히 대처할 수 있는 실용적인 해결책들을 설계할 수 있어야 합니다.

위대한 아키텍트는 고립된 소프트웨어 모듈에서뿐만 아니라 사람과 사람사이, 시스템과 시스템 사이에서 일어나는 변화의 충격을 이해해야 합니다.

변화는 다양한 형태로 나타날 수 있습니다.

  •  기능 위주의 요구 사항 변경
  •  확장성 요구의 진화
  •  수정된 시스템 인터페이스들
  •  팀원의 변동
  •  그리고 리스트(해야 할일)의 계속적인 발생

소프트웨어 프로젝트 변화의 광범위함과 복잡함을 미리 추측하는 것은 불가능하며, 변화가 발생하기 전에 모든 잠재적 어려움을 수용하는 시도는 헛된 일입니다.  그러나 아키텍트는 이러한 어려움들이 프로젝트를 망칠지 또는 완수할지를 결정하는 중요한 역할을 해야합니다.  

아키텍트의 역할이 반드시 변화를 관리하기 위한 것은 아니지만, 오히려 변화가 관리될 수 있음을 보장해야 합니다.   

계속 읽기

제가 이글을 쓴 이유는  저의 아이디와 패턴의 남용에 대해서 같이 언급하셔서, 큰 상처를 받았습니다. 제가 패턴쪽으로 많은 활동을 하고 있었는데요.

직접 대화를 나누어 오해를 풀었습니다.

저를 향한 글인줄 알았습니다.  직접 대화를 통해 그것이 아니었음을 알았습니다.  제가 너무 민감하게 대했던것 같습니다.

toby님에게 모욕을 당했다는 말은 정중히 사과하겠습니다.

다행히 toby님과 대화는 매우 산뜻하게 끝나고, 심지어 여러가지 mission을 주셨습니다. 🙂

이번 논쟁은 결국 몇분이 말씀해주신것 처럼, 각자가 느낀 도메인의 경험의 차이 그리고 생각의 차이라고 이해해 주셨으면 합니다.

디키 님의 말처럼 반론을 다는것 보다는 다시 저의 의견을 말씀 드리는 것이 올바른 글쓰기라고 생각하여 다시 글을 씁니다.

Ripple Effect (파문효과)에 대한 생각들..

계속 읽기