좋은 아키텍쳐는 어떤 문제에도 대응할 수 있어야 한다.
아키텍쳐 설계를 가지고 며칠이나 몇 주를 씨름하고 나면, 아키텍트는 문제를 너무나 잘 다뤄서 다른 사람들이 그 아키텍쳐를 보고는 "명쾌합니다. 이것보다 더 좋은 방안은 없죠"라고 할 만한 아키텍처를 완성해야 한다.
Harlan Mills는 이러한 아키텍쳐 품질을 '심오한 간결성(deep simplicity)'이라고 표현을 했다. 복잡한 아키텍쳐는 더 나은 아키텍쳐가 아니라 훨씬 못한 아키텍쳐인 것이다.
P. 200
아키텍쳐 설계를 가지고 며칠이나 몇 주를 씨름하고 나면, 아키텍트는 문제를 너무나 잘 다뤄서 다른 사람들이 그 아키텍쳐를 보고는 "명쾌합니다. 이것보다 더 좋은 방안은 없죠"라고 할 만한 아키텍처를 완성해야 한다.
Harlan Mills는 이러한 아키텍쳐 품질을 '심오한 간결성(deep simplicity)'이라고 표현을 했다. 복잡한 아키텍쳐는 더 나은 아키텍쳐가 아니라 훨씬 못한 아키텍쳐인 것이다.
P. 200
deep simplicity는 "심오한 간결성"으로 책에는 해석이 되었다.
minimalism을 좋아하는 나로서는 무척이나 반가운 말이다.
deep이라는 말은 extreme이라는 단어로 대치해도 의미적으로 맞아보인다.
"극단적인 단순함" 아키텍쳐를 만들때 어떠해야 하는지에 대한 이야기를 한 것이다. 너무 많은 내용을 담아서도 안되고, 중요한 부분을 심플하게 표현을 할 때 정말 필요한 아키텍처가 될 것이다.
그리고, 최소주의를 적용해서 아래와 같이 서브시스템 간에는 정말 필요한 의사소통만을 해야겠다. 소통이 많을 수록 유지보수나 운영도 어렵고, 버그의 가능성을 커질 것이다.
좋은 아키텍처는 서브시스템 간에 일어나는 의사소통을 최소화한다.
아키텍쳐의 목표가 복잡함을 감소시키는 데 있다는 것을 인식하고 나면, 아키텍트가 소프트웨어 내에 어떤 것을 포함할지에 집중하는 만큼 어떤 것을 제외시켜야 하는지에도 초점을 맞추어야 한다는 것이 명확해진다.
성공적인 아키텍쳐의 주요한 특징 중의 하나는 변경 가능성이 높은 프로그램부분을 식별하는 것이다.
제대로 아키텍쳐라면 아직 개발되지 않은 부분에 얽매지 않고도 상세설계를 할 수 있을 것이다.
http://blog.naver.com/jeong_jaehun/90022080910
코딩하지 않는 아키텍쳐는 아키텍쳐라고 말을 할수 없을 것입니다. 일단, 설계를 한번해보세요~ 아주 깔끔하게 잘 나옵니다. 자기 만족도가 엄청 높습니다. 그 설계로 코딩을 시작해보세요~ 설계가 수십번은 바뀌게 됩니다. 이게 바로 소프트웨어 개발입니다. 한번 수준 높은 설계를 할수 있을지는 몰라도 완벽한 설계를 할수가 없습니다. 설계단에서 코딩도 병행해서 해야 더 나은 설계가 가능합니다.
