1부 소개
1장 설계와 아키텍처란?
아키텍처: 저수준의 세부사항과는 분리된 고수준의 무언가를 가리킬 때 흔히 사용됨
설계: 저수준의 구조 또는 결정사항 등을 의미할 때
- 설계와 아키텍처가 하는 일을 살펴보면 이러한 구분은 무의미하다.
- 이러한 저수준의 세부사항과 고수준의 결정사항은 집의 전체 설계의 구성요소가 된다.
- 고수준에서 저수준으로 향하는 의사결정의 연속성만 있을 뿐
목표는?
소프트웨어 아키텍처의 목표는 필요한 시스템을 만들고 유지보수하는데 투입되는 인력을 최소화 하는데 있다.
사례 연구
- 실제 사례로 엔지니어링 직원 수는 증가하지만 생산성은 점점 늘지 않고 코드 라인당 비용이 굉장히 커진 사례
- 코드를 깔끔하게 유지하는 잘 알려진 수련법 중 하나 테스트 주도 개발(TDD)를 통해 적용하지 않은 날보다 적용한 날이 대략 10% 빠르게 작업이 완성됐다는 사례
- 엉망으로 만들면 깔끔하게 유지할 때보다 항상 더 느리다
- 빨리 가는 유일한 방법은 제대로 가는 것이다.
결론
소프트웨어 아키텍처를 심각하게 고려할 수 있으려면 좋은 소프트웨어 아키텍처가 무엇인지 이해해야 한다.
2장. 두 가지 가치에 대한 이야기
소프트웨어 시스템은 이해관계자에게 서로 다른 두가지 가치를 제공하는데 행위(behavior)와 구조(structure)가 바로 그것이며, 두 가지 가치를 모두 반드시 높게 유지해야 하는 책임을 진다.
행위
- 이해관계자들을 위해 기계가 수익을 창출하거나 비용을 절약하도록 만들기 위해서
- 많은 프로그래머가 이러한 활동이 자신이 해야 할 일의 전부라고 생각하지만 틀렸다.
아키텍처
- 아키텍처의 가치는 소프트웨어(software)라는 단어와 관련이 있다. '부드러운 - soft'과 '제품 - ware'의 합성으로 soft가 아키텍처의 가치와 관련이 있다.
- 기계의 행위를 쉽게 변경할 수 있도록인데 소프트웨어는 하드웨어와 달리 반드시 변경하기 쉬워야 한다.
- 소프트웨어 개발비용의 증가를 결정짓는 주된 요인은 변경사항의 범위와 형태의 차이에 있다.
- 새로운 요청사항이 발생할때마다 바로 이전의 변경사항으 적용하는 것보다 조금 더 힘들어지는데 시스템의 형태와 요구사항의 형태가 서로 맞지 않기 때문이다.
- 이 문제는 당연히 시스템 아키텍처다. 형태에 독립적이어야 하고 그럴수록 더 실용적이다.
더 높은 가치
동작은 하지 않지만 변경이 쉬운 프로그램을 내게 준다면 돌아가도록 만들 수 있고 변경사항이 발생하더라도 유지보수 할 수 있다.
아이젠하워 매트릭스
- 소프트웨어의 첫 번째 가치인 행위는 긴급하지만 매번 높은 중요도를 가지는 것은 아니다
- 소프트웨어의 두 번째 가치인 아키텍처는 중요하지만 즉각적인 긴급성을 필요로 하는경우는 절대 없다.
업무관리자는 보통 아키텍처의 중요성을 평가할 만한 능력을 겸비하지 못하기 때문에 개발자는 딜레마에 빠리고 소프트웨어 개발자를 고용하는 이유는 바로 이 딜레마를 해결하기 위해서다.
아키텍처를 위해 투쟁하라
소프트웨어 개발팀은 다른 이해관계자들과 동등하게 논쟁한다.
클린 아키텍처 소프트웨어 구조와 설계의 원칙
로버트 C. 마틴 저
step by step