마틴 파울러가 말합니다.
" 우리가 처음 개발할 때, 설계 아이디어에서 모듈화에 대해 크게 걱정하지 않고, 품질이 낮더라도 수 많은 기능 개선을 해 왔다면 여러분은 무조건 실패할 것입니다!"
저도 첫 프로젝트를 시작했을때 아키텍쳐를 고려하지 않고 기능구현에 좀 더 집중했던 것 같습니다.
나중에 조금 규모가 있는 프로젝트를 진행하면서 "반복되는 코드들을 정리할 무언가"가 필요했고, 그 과정에서 디자인 패턴을 알게 되었습니다.
디자인 패턴이란 정해져있는 규칙이 있는 건 아니지만, 대체로 자주 사용하는 디자인 패턴은 확인할 수 있습니다.
"우리는 우리의 전문적인 기준을 준수해야돼!"
"우리는 개발 장인이 되어야해!"
때로는 코드를 깎아서 좋은 기능을 만드는 장인정신도 중요합니다.
하지만 여러분이 왜 아키텍쳐가 중요한지 잘 말하고 싶다면 경제라는 개념을 주시해야 합니다.
" 우리는 어떤 것을 구매하는 모든 순간순간 이런 개념을 적용합니다. 차를 사거나, 옷을 사거나 우리는 품질과 비용을 트레이드오프 합니다.
하지만, 소프트웨어에서 품질이란 전혀 다른 것입니다.
그리고 중요한 점은 평가하는 사람이 자기 자신이 아닌 외부의 사람들이라는 것입니다.
그들은 품질을 볼 수 없습니다.
소프트웨어가 좋은 아키텍쳐를 가지고 있거나 좋은 모듈러, 디자인을 가지고 있다하더라도 그 모든것은 눈에 보이지 않습니다.
그리고 파울러는 소프트웨어는 두자기 형태의 품질을 가지고 있다고 말하는데,
외부적인 것과 내부적인 것입니다.
소프트웨어 아키텍처는 내부의 품질과도 관련되어 있습니다.
그리고 내부 품질은 직접적으로 보이지 않습니다.
만약, 누군가 완전 기능이 동일하지만 100달러 더 비싼 좋은 소프트웨어와
동일 기능의 품질이 낮은 소프트웨어 중에 고르라고 하면,
소비자는 분명 품질이 낮은 소프트웨어를 고를 것입니다.
똑같은 기능인데 100달러를 낼 필요는 없으니까요!
하지만 소프트 웨어의 내부 품질은 장기적인 관점에서 중요한 것입니다. "
마틴 파울러가 제시한 Design Stamina Hypothesis 입니다.
- 디자인 아키텍처에 대해 신경쓰지 않는 경우
- 시간이 지날수록, 새로운 기능을 추가하기가 엄청나게 어렵다.
- 왜냐하면, 소스코드를 바꾸는데 시간이 오래걸린다.
- 소프트웨어가 잘 컴포넌트화 되어있는 경우
- 어디를 변경해야 할 지 더 빨리 찾게되고, 그러면서 속도가 빨라진다.
예를들어,
같은 디자인과 같은 기능의 컴포넌트를 수정한다고 치면,
같은 기능, 같은 디자인의 컴포넌트의 수정사항을 일일이 변경해야하고,
기능 확장 시 같은 코드를 반복해서 입력해 확장도 어려울 뿐더러, 가독성이 좋지 못한 코드가 될 수 있습니다.
변경할 컴포넌트의 소스코드를 변경해주면, 해당 컴포넌트를 사용한 페이지의 모든 컴포넌트가 바뀔 것 입니다.
추가로, 서비스를 확장할 때 같은 컴포넌트들을 불러와 사용할 수 있다.
이렇게 좋은 디자인으로 설계된 소프트웨어는 짧은 기간에도 많은 기능이 추가되는 것을 볼 수 있습니다.