[클린 아키텍처] 설계? 아키텍처?

설계(design)와 아키텍처(architecture)

설계와 아키텍처에는 아무런 차이가 없다. 단지..
아키텍처는 저수준의 세부사항과는 분리된 고수준의 무언가를 가리킬때 흔히 사용되며
설계는 저수준의 구조 또는 결정사항 등을 의미할 때 많이 사용된다.

좋은 소프트웨어 설계의 목표?

소프트웨어 아키텍처의 목표는 필요한 시스템을 만들고 유지보수하는 데 투입되는 인력을 최소화하는데 있다.

좋은 아키텍처? 좋은 소프트웨어? 왜 좋은 소프트웨어를 만들어야 하는가?라는 질문이 거창한 대답을 요구할 것 같지만 결론은 유지보수 비용을 줄이기 위함이다. 아무리 복잡한 프로젝트여도 말이다.

생각해봐야 할 점

• 소프트웨어 제품이 잘 팔린다 -> 엔지니어링 직원 수를 뽑아 제품을 개발한다 -> 시간이 지날수록 코드 라인당 비용이 늘어난다??
• 사람을 뽑았는데 수정 비용이 늘어나는 것이 이해가 되지 않는다. 이런 경우라면 초기 개발자 생산성은 100%에서 시작했지만 결국에 0으로 수렴하게 될 것이다.
• 하지만 모든 개발자는 열심히 일하고 있다. 초인적인 노력을 기울이고, 잔업을 하며 헌신한다.
  • 개발자의 노력은 기능 개발보다는 엉망이 된 상황에 대처하는 데 소모되기 시작한다.
  • 사소한 기능을 추가하는 일도 엉망이 된 코드를 이곳 저곳 살펴보며 검증한 후 추가한다. (결국 노력의 가치가 보잘 것 없게 된다.)

무엇이 잘못 되었을까?

• 코드는 나중에 정리하면 돼. 당장은 시장 출시가 먼저야!!
  • 나중에 코드를 정리하는 경우는 없다. 시장의 압박은 절대로 수그러들지 않기 때문이다.
  • 생산성을 유지할 수 있다고 자신의 능력을 과신한다. 엉망진창인 코드가 서서히 쌓이면 개발자 생산성은 차츰 낮아지고, 코드가 엉망이 되는 추세는 저랟 멈추거나 수그러들지 않는다. 결국 생산성 0으로 수렴하게된다.
• 지전분한 코드를 작성하면 단기간에는 빠르게 갈 수 있고, 장기적으로 볼 때만 생산성이 낮아져!!
  • 엉망으로 만들면 깔끔하게 유지할 때보다 항상 더 느리다.
    • TDD를 적용해서 개발하면 더 느릴 것 같지만 실상 더 빠르게 작업이 완료된다.
  • 소프트웨어의 단순한 진리 빨리 가는 유일한 방법은 제대로 가는 것 이다.

결론

• 조직에 스며든 과신을 인지하여 방지하고, 소프트웨어 아키텍처의 품질을 심각하게 고민해보자
• 좋은 소프트웨어 아키텍처가 무엇인지 이해해야 심각하게 고려할 수 있다.
  • 비용은 최소화, 생산성은 극대화할 수 있는 설계와 아키텍처를 가진 시스템은 어떻게 만들 수 있을까?