- 소프트웨어를 올바르게 만드는 일은 어렵다. 소프트웨어를 제대로 만들려면 적정 수준의 지식과 기술이 겸비해야 한다.
- 소트웨어를 제대로 만들면 아주 적은 인력만으로도 새로운 기능을 추가하거나 유지보수할 수 있다.
- 변경은 단순해지고 빠르게 반영할 수 있따.
- 결함은 적어지고 잦아든다.
설계와 아키텍처란#
- 설계와 아키텍처 사이에는 차이가 없다.
- 아키텍처는 고수준의 무언가를 가리킬 떄 흔히 사용되는 반면, 설계는 저수준의 구조 또는 결정사항 등을 의미할 떄가 많다.
- 저수준의 세부사항과 고수준의 구조는 모두 소프트웨어 전체 설계의 구성요소다. 이 둘을 구분 짓는 뚜렷한 경계는 없다. 고수준에서 저수준으로 향하는 의사결정의 연속성만 있다.
- 소프트웨어 아키텍처의 목표: 필요한 시스템을 만들고 유지보수하는 데 투입되는 입력을 최소화한다.
- 개발자가 속는 나쁜 거짓말
- 코드는 나중에 정리하면 된다. 당장은 시장에 출시하는게 먼저다.
- 지저분한 코드를 작성하면 단기간에는 빠르게 갈 수 있고, 장기적으로 볼 때만 생산성이 낮아진다.
- 결론: 어떤 경우라도 개발 조직이 할 수 있는 최고의 선택지는 조직에 스며든 과신을 인지하여 방지하고, 소프트웨어 아키텍처의 품질을 심각하게 고민하기 시작하는 것이다.
두 가지 가치에 대한 이야기#
- 소프트웨어 시스템이 이해관계자에게 주는 가치 두 가지: 행위와 구조
- 소프트웨어 개발자는 이 두 가지 가치를 모두 반드시 높게 유지해야되는 책임이 있다.
- 행위: 이해관계자가 기능 명세서나 요구사항 문서를 구체화할 수 있도록 돕는다. 그리고 이해관계자의 기계가 이러한 요구사항을 만족하도록 코드를 작성한다.
- 아키텍처: 이해관계자가 기능에 대한 생각을 바꾸면, 이러한 변경사항을 간단하고 쉽게 적용할 수 있어야 한다. 이러한 변경사항을 적용하는 데 드는 어려움은 변경되는 범위(scope)에 비례해야하며, 변경사항의 형태(shape)와는 관련이 없어야한다.
- 아이젠하워 매트릭스에서 우선순위를 다음과 같이 매길 수 있다. 업무 관리자와 개발자가 흔하게 저지르는 실수는 세 번쨰에 위치한 항목을 첫 번쨰로 격상시켜 버리는 일이다.
- 긴급하고 중요한
- 긴급하지는 않지만 중요한
- 긴급하지만 중요하지 않은
- 긴급하지도 중요하지도 않은
- 아키텍처가 후순위가 되면 시스템을 개발하는 비용이 더 많이 들고, 일부 또는 전체 시스템에 변경을 가하는 일이 현실적으로 불가능해진다.