SW 아키텍처는 코드로부터 시작한다.

구조적 프로그래밍

• 최초로 적용된 패러다임
• 무분별한 goto문은 해롭다.
  • if/then/else , do/while/until 로 대체
• 제어 흐름의 직접적인 전환에 대해 규칙을 부과한다*

객체 지향 프로그래밍

함수 호출 스택 프레임을 Heap으로 옮기면, 호출이 반환된 이후에도 함수에서 선언된 지역 변수가 오랫동안 유지됨을 발견
이러한 함수가 클래스의 생성자가 되었고, 지역변수는 인스턴스 변수, 중첩함수는 메서드가 되었다.
제어흐름의 간접적인 전환에 대해 규칙을 부과한다

함수형 프로그래밍

최근에 들어 인기있고 사용되는 패러다임
세 패러다임 중 가장 먼저 만들어졌다.
람다 계산법의 기초가 되는 개념 = 불변성 즉, 심볼의 값이 변경되지 않는다는 점이다.
할당문에 대해 규칙을 부과한다

각 패러다임은 프로그래머에게서 권한을 박탈한다.
어느 패러다임도 새로운 권한을 부여하지 않는다.
규칙을 부과한다. 즉, 무엇을 하면 안되는 지를 알려준다.

결론

패러다임의 역사로부터 얻을 수 있는 교훈은 아키텍처와 어떤 관계가 있는가?
-> 모두 관계있음.

아키텍처 경계를 넘나들기 위한 메커니즘으로 다형성을 이용한다.
우리는 FP를 이용하여 데이터의 위치와 접근 방법에 대해 규칙을 부과한다.
우리는 모듈의 기반 알고리즘으로 구조적 프로그래밍을 사용한다.

함수, 컴포넌트 분리, 데이터 관리가 어떻게 서로 연관되는 지 주목하자.

두가지 가치에 대한 이야기

모든 SW 시스템은 이해관계자에게 두가지 가치를 제공한다.
행위와 구조
개발자는 두 가치를 반드시 높게 유지해야 하는 책임을 진다.
불행히도 대부분의 개발자는 한가지에만 집중하고, 다른 하나는 배제하곤 한다.

행위

SW의 첫 가치는 행위다
프로그래머를 고용하는 이유는 이혜관계자를 위해 기계가 수익을 창출하거나 비용을 절약하도록 만들기 위해서다

아키텍처

SW의 두번째 가치는 'SW' 라는 단어와 관련이 있다.
Soft, Ware = 부드러운 제품
SW를 만드는 이유는 기계의 행위를 쉽게 변경하기 위해서다(유연성?)

SW는 부드러워야 한다. 즉 변경하기 쉬워야 한다.
요구사항이 바뀌면 변경사항이 생긴다.
이러한 변경사항을 적용하는 데에 어려움은 범위에는 비례해야 하며, 변경사항의 형태와는 관련이 없어야 한다.

이해 관계자는 비슷한 변경사항을 제시하지만, 개발자 입장에서는 어려운 지시로 느껴진다.
새로운 요청사항이 발생할 때마다 바로 이전의 변경사항을 적용하는 것보다 조금 더 힘들어진다.
-> 시스템의 형태와 요구사항의 형태가 서로 맞지 않기 때문이다.
(병에 네모난 뚜껑을 닫으라는 것)

문제는 아키텍처다. 아키텍처가 특정 형태를 다른 형태보다 선호할수록, 새 기능을 해당 구조에 맞추기는 어렵다.
(이미 정형화된 구조가 있는 상태에서는 어렵다)
아키텍처는 형태에 독립적이어야 하고, 그럴수록 실용적이다

더 높은 가치

기능 vs 아키텍처 어떤 것의 가치가 더 높은가?

• 기능
  • 시스템이 동작하도록 만드는 것
• 아키텍처
  • 시스템을 더 쉽게 변경할 수 있도록 하는 것

예를 들어보자

1. 상황(1)
   • 완벽하게 동작하지만 수정이 불가능
   • 요구사항이 변경될 때, 동작하지 않는다
   • 결국 프로그램은 쓸모가 없어진다
2. 상황(2)
   • 동작을 하지 않고 변경이 쉬운 프로그램
   • 개발자는 프로그램을 동작하게 할 수 있다
   • 변경이 발생해도 유지보수할 수 있다

불가능한 기능은 없다.
하지만 변경이 없는 서비스/시스템은 없다.

우선수위

긴급함 과 중요도로 나눠보자.

동작시키는 것은 긴급: o, 중요: 기능마다 다름
아키텍처 긴급: x, 중요: o

아키텍처는 언제든 항상 중요도가 가장 높다.

아키텍처를 위해 투쟁하라

이러한 책임(깔끔한 아키텍처를 유지하려는 책임)을 다하려면 ㅅ투쟁해야 한다.
디자인, 관리, 운영, 기획 등 각각의 팀은 각팀의 책임을 다한다.
개발팀도 SW를 안전하고 유연하게 유지해야 하는 책임이 있다.

설계와 아키텍처란?

설계(Design)과 아키텍처(Architecture) 사이에는 많은 혼란이 있었다.
어떤 차이가 있는가?

이 책의 목적은 이러한 혼란을 없애고, 설계와 아키텍처가 무엇인지를 완전하게 정의하는 것이다.
'아키텍처'는 저수준의 세부사항과는 분리된 고수준의 무언가를 가르킬 때 주로 사용
'설계'는 저수준의 구조 또는 결정사항 등을 의미할 때가 많다.

하지만 아키텍처를 보고도 저수준을 알 수 있다.
결국 저수준의 세부사항과 고수준의 구조는 모두 전체 설계를 위한 구성요소이다.
이 둘을 따로 보는 것이 아닌 합쳐서 하나의 설계로 봐야한다.
고수준 -> 저수준으로 향하는 의사결정의 연속

목표는?

그렇다면 의사결정의 목표는?
좋은 소프트웨어 설계 목표는?

소프트웨어 아키텍처의 목표는 필요한 시스템을 만들고 유지보수하는 데 투입되는 인력을 최소화하는 데에 있다.

회사가 성장하면 직원이 많아진다.
직원이 많아지면 당연히 회사 입장에서는 비용이 많이 든다.
하지만 대부분의 회사들을 보면 작성되는 코드 라인 수는 그만큼 증가하지 않는다.
-> 회사 성장 -> 직원 더 뽑음 -> 코드 라인수 대비 비용 증가 -> 회사 입장 손실

엉망진창이 되어 가는 신호

시스템을 급하게 만들거나, 결과물의 총량을 순전히 프로그래머 수만으로 결정하거나
코드와 설계의 구조를 깔끔하게 만들지 않으면 비용 곡선은 파국으로 치닫는다.

개발자 입장에서는 초반에는 높은 효율을 내지만, 가면 갈수록 떨어져서 결국엔 사소한 기능을 추가하는 일도 이리저리 파일을 옮겨다니며 코드 작성에 애를 먹는다.

경영자의 시각

왜 직원들 월급은 더 나가는데, 진도가 늦어?

무엇이 잘못되었나?

이솝우화 중 토끼와 거북이 있다.

• 느려도 꾸준하면 이긴다.
• 급할수록 돌아가라

현대의 개발자도 비슷한 경주를 한다.
그렇다고 개발자가 자는 것은 아니다. 오히려 뼈 빠지게 일한다. 하지만 그들의 뇌는 잔다.
훌륭하고 깔끔하게 설계된 코드가 중요하다는 사실을 알고 있는 뇌가 잔다.

"이 코드는 나중에 정리하면 돼. 당장은 시장에 출시하는 게 먼저야"
-> 경쟁자가 뒤 쫓고 있고, 앞서 가려면 빠르게 출시해야 하기 때문이다.

하지만 개발자는 태세를 전환하지 않는다. 이전 코드들을 정리하는 일은 발생하지 않는다.
출시 후에는 다음 기능, 다음 기능 .....

엉망으로 만들면 깔끔하게 유지할 때보다 언제나 항상 더 느리다

결론

어떤 경우라도 개발 조직이 할 수 있는 최고의 선택지는 능력을 과신하지 않고, 소프트웨어 아키텍처의 품질에 대해 고민하는 것이다.
고민하기 위해서는 좋은 소프트웨어 아키텍처가 무엇인지 알아야 한다.
비용은 최소화, 생산성을 최대화 하는 시스템을 만들려면, 결국 아키텍처가 갖는 속성을 알아야 한다.

클린 아키텍처

프로그램이 동작하도록 만드는 데에는 사실 엄청난 수준의 지식과 기술이 필요하지 않다.
어린 고등학생도 가능하다 -> (맞는 것 같다... 특히나 요즘엔 더더욱 자료가 많으니 복붙하면서 보다보면 대충 이렇게 굴러가는 구나 할 수 있다)

이들이 작성한 코드는 그다지 깔끔하지 않을 순 있지만, 동작은 한다.

제대로 만드는 프로그램

하지만 프로그램을 제대로 만드는 일은 전혀 다르다
소프트웨어를 올바르게 만드는 일은 어렵다.
적정 수준의 지식과 기술을 겸비해야 하지만, 대다수의 젊은 프로그래머는 이 수준에 도달하지 못했다.
훈련과 헌신이 필요하지만, 위와 같다.

제대로 만든다면

소프트웨어를 제대로 만들게 되면 마법과도 같은 일이 벌어진다.
소수의 프로그래머만으로 프로그램을 지속적으로 관리할 수 있다.
거대한 요구사항 문서와 이슈가 수없이 등록된 이슈 추적 시스템도 필요가 없다.

적은 인력으로도 새로운 기능을 추가하거나 유지보수할 수 있다.
변경은 단순해지고 빠르게 반영할 수 있다.

(사실 지금 나로서는 크게 와 닿지는 않는다. 깔끔한 코드/아키텍처가 유지보수와 이후 관리 및 수정에 큰 도움을 준다는 것은 전적으로 동의하지만
언제쯤 그 수준에 도달할 지, 그리고 내 생각이 맞는지 틀린지, 왜냐면 다른 사람들은 또 다른 생각을 하니깐 등등)