클린아키텍쳐를 읽고..

감명깊게 읽은 부분을, 간략히 또는 자세히 정리한 내용입니다.

<br/>

1부

<br/>

1장 - 설계와 아키텍쳐란?

설계와 아키텍쳐의 차이점은 무엇인가?
둘 사이에는 아무 차이가 없다.

아키텍쳐는 흔히 고수준에서 무언가를 바라볼때 사용하며,
설계는 저수준의 구조 또는 결저사항을 의미할 때 사용한다.

소프트웨어 설계는 저수준의 세부사항과, 고수준의 구조 모두 소프트웨어 전체 설계의 구성요소이다.
이 둘은 개별로 존재 할 수 없으며, 실제로 이둘의 경계 지을 수 없다.

그러면 소프트웨어 아키텍쳐의 목표는 무엇인가

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

<br/>

2장 - 두 가지 가치에 대한 이야기

모든 소프트웨어는 이해관계자에게 2가지의 가치를 제공하는데 행위(기능)와 구조(유연성)이다.

이 2가지의 가치중 어느것이 더중요한가?

• 완벽하게 동작하지만, 변경이 불가능한 프로그램 (행위 > 구조)
• 동작하지는 않지만, 변경이 가능한 프로그램 (구조 > 행위)

전자를 보자, 요구사항이 변경된다면 사용할 수 없는 프로그램이된다.
후자를 보자, 변경가능한 프로그램은 쉽게 고칠 수 있으며, 새로운 요구사항에도 쉽게 대응 할 수 있다.

구조는 행위보다 중요한 가치이다

소프트웨어를 위해 투쟁하라.
개발팀, 관리팀, 기획팀은 자신이 믿는 가치에 스스로 투쟁한다.
소프트웨어 개발자도 이해관계자임을 명시하라.
개발자는 소프트웨어를 안전하게 보호해야할 책임을 가지고 있다

<br/>

2부

<br/>

3장 - 패러다임의 개요

• 구조적 프로그래밍 - 제어의 흐름의 직접적인 전환
• 객체지향 프로그래밍 - 제어의 흐름의 간접적인 전환
• 함수형 프로그래밍 - 할당문에 대한 규칙

이 세가지 패러다임은 10년동안 나왔으며, 그 이후에 어떤 패러다임도 발생하지 않았다.

<br/>

4장 - 구조적 프로그래밍

goto문의 해롭다.
순차, 분기, 반복 세가지의 제어구조는 프로그래밍을 더 쉽고 단순하게 만들었다.
구조적 프로로그밍을 통해 모듈을 더 작은 단위로 구성할 수 있게 되었다.
거대한 기술문제를 고수준으로, 고수준은 또 저수준으로 구현할 수 있게 되었다.

테스트는 버그가 있음을 보여준다, 버그가 없음을 보여주지는 않는다.
다시말해 테스트는 프로그램이 잘못되었음을 테스트하는것이지, 프로그램이 맞다고는 증명할 수 없다.
마치 과학과 유사하다.

구조적 프로그래밍은 프로그램을 증명 가능한 세부 기능의 집합으로 재귀적으로 분해할 것을 강요한다.
그리고 테스트를 통해 세부기능을 거짓인지를 증명하려고한다.

구조적 프로그래밍이 오늘날까지 가치 있는 이유는,
프로그래밍에서 반증 가능한 단위를 만들어 낼 수 있기 때문이다.

가장 작은 기능에서부터, 가장 큰 컴포넌트에 이르기까지 모든 수준에서 소프트웨어는 과학과 같고,
따라서 반증가능성에 주도된다.

소프트웨어의 아키텍트는 모듈, 컴퓨넌트, 서비스가 쉽게 반증 가능하도록(테스트 하기 쉽도록) 만들이 위해 분주히 노력해야한다.

<br>

5장 - 객체 지향 프로그래밍

객체지향 프로그래밍은 무엇인가?
실세계를 빗대어 소프트웨어로 풀어낸 것인가?

객체지향을 말할때 세 가지에 대해서 얘기한다.

• 캡슐화
• 상속
• 다형성

캡슐화는 객체지향언어가 아닌 C에서도 충분히 구현가능하다.
상속 또한 C언어에서도 구현가능하지만, 객체지향은 이를 좀더 쉽게한다. 0.5점의 점수를 줄 수 있겠다.

중요한것은 다형성이다.

다형성은플러그인 아키텍쳐를 가능하게한다.

Client -> FoodMarket

class Client

기존의 소프트웨어 코드의 흐름은 고수준에서 저수준의 호출을 사용하도록 하였다.
소프트웨어의 흐름은 Client는 FoodMarket 호출하여 구현하였다.

다형성은 제어의 흐름을 역전 시킨다.

Client -> Seller

Seller <|-- FoodMarket
Seller <|-- Caffee

Interface Seller

Client -> FoodMarket 의 흐름이 아닌
Client -> Seller <- FoodMarket의 흐름으로 바뀐것이다.

Client는 Seller를 호출한다.
Seller는 FoodMarket이 될수도, Caffee가 될 수도 있다.
이를 플러그인(PlugIn) 아키텍쳐가 가능하게 함을 보여준다.

그럼 이런 의존성의 역전 현상, 플러그인 아키텍쳐 이것의 힘은 무엇인가?

우리가 시스템의 제어 흐름에 절대적인 권한을 갖음을 의미한다.
우리는 의도한 곳에 마음대로 제어 흐름을 바꿀 수가 있다.

예를 들어보자.
Client는 Seller를 호출하는 흐름을 가지고 있다.
그리고 이 모듈을 누군가에게 제공한다.

이 모듈을 누군가에게 제공함에 집중하자.

누군가는 이모듈을 받아 Seller를 구현하여,
FoodMarket, Caffee, Restraunt 등 다양한 구현체를 만든다.

이렇게 모듈 별로 독립하여 배포되며, 서로 다른누군가가 독립된 구현이 가능하다.

이는 모두 객체지향이 가진 다형성의 힘이다.

Client -> FoodMarket의 일반적인 흐름을 가진 모듈을 공유했다면,
누군가는 이 흐름에 맞추어 어느 독립된 구현도 불가 할 것이다.

객체지향은 아키텍쳐 관점에서 명확하다.
객체지향이랑 다형성을 이용하여, 모든 소스코드의 절대적인 권한을 흭득할 수 있는 능력이다.

<br/>

6장 - 함수형 프로그래밍

함수형 프로그래밍을 설명하지 않는다.
하지만 함수형 프로그래밍의 중요한 포인트는
변수가 변경되지 않는다는 것이다.

불변은 중요하다.
불변은 왜중요한가?
왜 변수의 가변을 염려하는가?

경합조건, 교착상태, 동시업데이트 우리가 가장 많이 겪는 이 문제가
모두 변수의 가변에서 오기 때문이다.

어떠한 변수도 갱신되지 않는다면, 이런 문제는 발생 하지 않는다.

그럼 불변성은 정말 실현가능한가?
그렇지는 않을것이다. 그리고 우리는 타협을 해야한다.

불변성과 관련하여 가장 중요한 타협은
가변되는것과 불변되는것을 구분하는것이다.

불변A --> 가변
불변B --> 가변
불변C --> 가변

class 불변A

그리고 불변된 컴포넌트가, 가변된 컴포넌트에 의존하게 하는것이다.

여기서 불변된 컴포넌트를 순수하게 함수형 방식으로 처리되며,
가변변수는 허용되지 않는다.

가능한한 많은 처리를 불변 컴포넌트로 이동해야한다.
가변 컴포넌트의 코드는 최소한으로 빼내야한다.