소개
•
모든 소프트웨어 시스템은 두 가지 가치를 제공하는데, 행위와 구조다.
•
보통의 개발자는 둘 중 하나의 가치에만 집중한다.
◦
안타까운 것은 대체로 개발자가 덜 중요한 것에 집중하여 결국에는 소프트웨어 시스템을 망친다는 사실이다.
행위
•
소프트웨어의 첫 번째 가치는 행위다.
•
프로그래머를 고용하는 이유는 이해관계자를 위해 기계가 수익을 창출하거나 비용을 절약하도록 만들기 위해서다.
◦
즉 이해관계자의 기계가 요구사항을 만족하도록 코드를 작성하는 것이다.
아키텍처
•
소프트웨어의 두 번째 가치는 소프트웨어라는 단어와 관련이 있다.
•
소프트웨어라는 단어는 부드러운과 제품이라는 단어의 합성어다.
◦
소프트웨어는 부드러움을 지니도록 만들어졌다. 소프트웨어를 만든 이유는 기계의 행위를 쉽게 변경할 수 있도록 하기 위해서다.
◦
소프트웨어가 가진 본연의 목적을 추구하려면 소프트웨어는 반드시 부드러워야 한다, 아키텍처는 형태에 독립적이어야 하고 그럴수록 더 실용적이다.
더 높은 가치
•
둘 중 어떤 것의 가치가 더 높을까?
•
극단적으로 예시를 들면 완벽하게 동작하지만 수정이 불가능한 프로그램 vs 동작을 하지 않지만 변경이 쉬운 프로그램으로 비유할 수 있을 것이다.
◦
극단적이진 하지만 무엇을 고르는 가가 어떤 것이 더 높은 가치를 가지는 지 가늠해볼 수 있는 길이다.
아이젠하워 매트릭스
•
아이젠하워 미국 대통령이 고안한 중요성과 긴급성에 대한 매트릭스다.
내겐 두 가지 유형의 문제가 있습니다. 하나는 긴급하며, 다른 하나는 중요합니다. 긴급한 문제는 중요하지 않으며, 중요한 문제는 절대 긴급하지 않습니다.
•
긴급한 문제가 중요할 문제일 경우는 드물고 중요한 문제가 몹시 긴급한 경우는 거의 없다.
◦
행위는 긴급하지만 매번 높은 중요도를 가지는 것은 아니다.
◦
아키텍처는 중요하지만 긴급하진 않다.
•
우선 순위는 다음과 같이 매길 수 있다.
1.
긴급 O / 중요 O (아키텍처, 행위)
2.
긴급 X / 중요 O (아키텍처)
3.
긴급 O / 중요 X (행위)
4.
긴급 X / 중요 X
•
우선순위 3순위를 1순위로 격상시키지 말자, 기능의 긴급성이 아닌 아키텍처의 중요성을 설득하는 일은 소프트웨어 개발팀이 책임져야 한다.
아키텍처를 위해 투쟁하라
•
회사 안의 모든 팀은 자신들만의 가치를 위해 투쟁해야 한다.
•
아키텍처의 우선순위를 낮춰 시스템 변경이 힘들어졌다면 충분히 투쟁하지 않았다는 뜻이다.
