클린 아키텍처 2장

두 가지 가치를 모두 높게 유지해야 하는 책임이 있음

행위(behavior)

구조(structure)

일반적으로, 한 가지 가치에만 집중하고, 나머지 가치는 배제하고는 한다.

행위

기계가 요구사항을 만족하도록 코드를 작성한다. 요구사항을 기계에 구현하고 버그를 수정하는 일이 자신의 직업이라고 믿는다. 슬픈 일이지만 그들은 틀렸다.

소프트웨어는 soft ware로 부드러운 제품. 부드러운 이유는 기계의 행위를 쉽게 변경할 수 있도록 하기 위해서다. 기계의 행위를 바꾸는 일을 어렵게 만들고자 했다면, 우리는 소프트웨어가 아니라 하드웨어라고 불렀을 것이다.

→ 아키텍처는 형태에 독립적이어야하고, 그럴수록 더 실용적이다.

기능인가? 아키텍처인가?

→ 일반적으로 기능이 더 중요하다고 할 것이다.

→ 그러나 이것은 잘못된 태도이다. 극단적인 예를 들어보자

→ 완벽하게 동작하지만 수정이 아예 불가능한 프로그램을 내게 준다면, 이 프로그램은 요구사항이 변경될 때, 동작하지 않게 되고, 결국 이러한 프로그램은 거의 쓸모가 없다.

→ 동작은 하지 않지만, 변경이 쉬운 프로그램을 준다면, 프로그램이 돌아가도록 만들 수 있고, 변경사항이 발생하더라도 여전히 동작하도록 유지보수할 수 있다. 따라서 이러한 프로그램은 계속 유용한 채로 남는다.

현실성 없을 수 있지만, 변경에 필요한 비용이 수익을 초과하게 되면, 결국 쓸모없는 프로그램

긴급, 중요

긴급한 문제는 중요하지 않으며, 중요한 문제는 절대 긴급하지 않습니다.

소프트웨어의 첫 번째 가치인 행위는 긴급하지만 매번 높은 중요도를 가지는 것은 아니다.

소프트웨어의 두 번째 가치인 아키텍쳐는 중요하지만 즉각적인 긴급성을 필요로 하는 경우는 절대 없다.

1.긴급하고 중요한

2.긴급하지는 않지만 중요한

3.긴급하지만 중요하지 않은

4.긴급하지도 중요하지도 않은

세 번째에 위치한 항목을 첫번째로 처리할 필요가 없는 데, 아키텍처를 무시한 채 중요도가 떨어지는 기능을 선택하게 된다.

업무 관리자는 보통 아키텍처의 중요성을 평가할 만한 능력을 겸비하지 못하기 때문에 개발자는 딜레마에 빠진다. → 아키텍처의 중요성을 설득하는 일은 소프트웨어 개발팀이 마땅히 책임져야 한다.

개발팀은 회사에서 가장 중요하다고 스스로 믿는 가치를 위해 투쟁하고, 관리팀도 자신만의 가치를 위해 투장하며, 다른 팀들도 마찬가지.

소프트웨어를 안전하게 보호해야 할 책임이 있음므로 당신 역시도 이해관계가 있다. 소프트웨어 아키텍트라면 두배로 중요해 진다.