개발자에서 아키텍트로 #1 소프트웨어 아키텍트가 되다

1장 소프트웨어 아키텍트가 되다

- 아키텍트는 시스템의 품질 속성을 정의할 뿐만 아니라 소프트웨어 아키텍처가 정해진 방향으로만 갈 수 있도록 제약과 기능을 꾸준히 해야함.

- 아키텍트는 소프트웨어 시스템을 여러 조각으로 나누고 조각마다 품질 속성과 요구사항을 달성하도록 전략을 구성

- 데이터를 읽는 작업과 쓰는 작업을 분리해서 더 신뢰성 있고 가용성 높은 소프트웨어 시스템을 구축

- 시스템을 작게 나누면 원인, 테스트, 설계가 쉽다. 단, 시스템을 작게 나눈만큼 다시 모아서 제대로 동작하게 하는 작업도 필요하다.

- 아키텍트는 작은 설계 결정 사항이 가져올 미래도 예측하면서 넓은 의미의 시스템 관점도 가져야 한다.

- 기술 부채는 소프트웨어 시스템의 현재 설계와 소프트웨어가 지속적으로 가치를 창출하기 위해 가져야만 하는 바람직한 설계 사이의 간극이다. 

- 기술 부채를 전략으로 활용해서 빠른 릴리스를 달성하면서도 정기적으로 부채를 갚아서 꾸준히 더 나은 가치를 만들어낸다.

- 구조를 만드는 일은 곧 요소들끼리 관계를 만드는 일

- 요소와 관계를 세 가지 타입(모듈, 컴포넌트와 커넥터, 자원 할당)  구조 중 선택해 설계 

- 모듈은 설계 시점에 의미 있는 요소이며 컴포넌트는 런타임 시점에 의미 있는 요소

- 품질 속성을 묻지 않으면 시스템을 잘못 설계할 수 있다.

- 품질 속성은 해당 소프트웨어 시스템의 이해관계자들이 소프트웨어를 평가하는 데 도드라지는 특성들을 말함

- 품질 속성은 크게 확장성, 가용성, 유지 보수성, 테스트 가능성 등이 대표적인 예

- 훌륭한 소프트웨어를 만들기 위한 방법은 6가지 방법이 있다.

   1. 소프트웨어 아키텍처는 큰 문제를 작게 나누고 관리하기 쉽게 만듦

     : 크고 복잡하고 동적으로 변하는 여러 개의 조각으로 이루어진다.

   2.소프트웨어 아키텍처는 사람들이 협업하는 방법을 보여줌

     : 기술보다 사람 간의 커뮤니케이션이다.

   3.소프트웨어 아키텍처는 복잡한 아이디어를 설명할 때 사용하는 사전

      : 설명을 상대방이 이해하지 못하면 협업은 불가능하다

   4.소프트웨어 아키텍처는 기능과 스펙 너머로 시야를 넓혀줌

       : 비용, 제약, 일정, 리스크, 팀의 역량, 확장성, 가용성, 성능, 유지 보수성 등의 품질 속성까지 고려해야 한다.

   5.소프트웨어 아키텍처는 값비싼 실수를 줄여줌

        : 마틴 파울러는 소프트웨어 아키텍처에 대해 "뭐가 되었든 중요한 것" 

   6.소프트웨어 아키텍처는 예자일을 가능하게 함

         : 소프트웨어도 장애물을 만날 떄 쉽게 변경할 수 있어야 함.