[클린 아키텍처] 5부. 아키텍처

🍎 테스트 경계

테스트는 시스템의 일부이고, 아키텍처에도 관여한다.

 

 

🍊 테스트의 특성

1) 테스트는 의존성 규칙을 따른다.

- 테스트는 세부적, 구체적인 것으로 의존성은 항상 테스트 대상이 되는 코드를 향한다.

- 실제로 테스트는 아키텍처에서 가장 바깥쪽 원으로 생각할 수 있다.

- 시스템 내부의 어떤 것도 테스트에는 의존하지 않으며, 테스트는 시스템의 컴포넌트를 향해, 항상 원의 안쪽으로 의존한다.

 

2) 테스트는 독립적으로 배포 가능하다.

- 대다수의 경우 테스트는 테스트 시스템에만 배포하며, 상용 시스템에는 배포하지 않는다.

 

3) 테스트는 시스템 컴포넌트 중 가장 고립되어있다. 

- 테스트가 시스템 운영에 꼭 필요하지 않다.

 

 

하지만, 그렇다고 해서 아키텍처 설계 시, 테스트를 설계 범위 밖에 있다고 여기면 안된다. 

 

🍊 이유

시스템에 강하게 결합된 테스트라면 시스템이 변경될 때 함께 변경되어야 한다.

- 시스템의 어떤 한 부분을 살짝 건드렸을 때, 약 1000개의 테스트를 수정해야 한다면?

- 변동 가능성이 높은 것들에 의존하지 말아야 한다.

 

🍊 테스트 API

결합을 없애기 위해 테스트용 API 를 만들면 된다. 

- 테스트 API의 역할은 애플리케이션의 구조를 테스트로부터 숨기는 데 있다.

- 이 것을 만들면, 상용 코드를 리팩토링하거나 진화시키더라도 테스트에는 전혀 영향을 주지 않는다.

 

 

 

🍏 클린 임베디드 아키텍처

---

소프트웨어는 닳지 않지만, 펌웨어와 하드웨어에 대한 의존성을 관리하지 않으면 안으로부터 파괴될 수 있다.

현실 : 하드웨어는 계속해서 발전하고, 이에 따라 임베디드 코드를 구조화할 수 있어야 한다. 

 

" 펌웨어를 수없이 양산하는 일을 멈추고, 코드에게 유효 수명을 길게 늘릴 수 있는 기회를 주어라"

 

🍊 왜 잠재적인 임베디드 소프트웨어가 펌웨어로 변할까? 

동작에 많은 주의를 기울이고, 유지보수되도록 구조화하는 데는 신경쓰지 않기 때문이다. 

 

 

🍊 클린 임베디드 아키텍처란?

1) 테스트하기 쉬운 아키텍처

• 소프트웨어와 펌웨어가 서로 섞이는 일(안티 패턴)은 변화에 저항한다.
• 변경하기 어려울 뿐 아니라 위험을 수반하여 때로는 의도치 않은 결과를 불러온다.
• 하드웨어는 세부사항이다.

 

 

2) HAL(하드웨어 추상화 계층) 사용자에게 하드웨어 세부사항을 드러내지 말라. 

• HAL을 제대로 만들었다면, 타깃에 상관없이 테스트할 수 있다.
• 프로세스는 세부사항이다.
• 운영체제는 세부사항이다.

 

3) 인터페이스를 통하고 대체 가능성을 높이는 방향으로 프로그래밍하라

• HAL, OSAL, 주요 계층 내부에 책에서 설명한 원칙들을 적용할 수 있, 아니 해야한다.
• 관심사를 분리시키고 인터페이스를 활용하여 대체 가능성을 높이는 방향으로 프로그래밍하자.

 

4) DRY 원칙 : 조건부 컴파일 지시자를 반복하지 말라.

• 코드를 반복하는 일은 반복하지 말라
• 하드웨어 추상화 계층을 사용하여 하드웨어 유형을 숨기자.
• 만약 이 HAL이 조건부 컴파일 대신 사용할 수 있는 일련의 인터페이스를 제공한다면, 우리는 링커 또는 어떤 형태의 실시간 바인딩을 사용해서 소프트웨어와 하드웨어를 연결할 수 있다.