‘클린 아키텍처’ 기술 서적에 대해 학습했던 내용을 정리하기 위한 목적의 TIL 포스팅입니다.🙆♂️
소프트웨어는 닳지 않지만, 펌웨어와 하드웨어에 대한 의존성을 관리하지 않으면 안으로부터 파괴될 수 있다.
- 소프트웨어는 시간이 지나도 유용하게 쓸 수 잇지만, 펌웨어는 하드웨어가 발전할 수록 낡아갈 것이다.
- 안드리오드 앱 개발자 역시 업무 로직을 안드로이드 API 로부터 분리하지 않는다면 펌웨어(하드웨어)를 작성하는 셈이다.
- 어떻게 하면 임베디드 소프트웨어 아키텍처를 깔끔하게 유지할 수 있는지, 그래서 소프트웨어가 오랫동안 유용하게 살아남을 가능성을 높일 수 있는지를 살펴보자.
앱-티튜드 테스트
- 임베디드가 아닌 대다수의 앱들도 코드를 올바르게 작성해서 유효 수명을 길게 늘리는데는 거의 관심 없이, 그저 동작하도록 만들어진다.
- 이렇게 앱이 동작하도록 만드는 것을 개발자용
앱-티튜드 테스트(App-titude test)라 부른다.
타깃-하드웨어 병목현상
- 임베디드가 지닌 특수한 문제중 하나다.
- 대개의 경우 테스트할 수 있는 환경이 해당 특정 타깃으로 국한될 것이고, 타깃-하드웨어 병목현상이 발생하여 진척이 느려질 것이다.
클린 임베디드 아키텍처는 테스트하기 쉬운 임베디든 아키텍처다.
계층
- 소프트웨어, 펌웨어, 하드웨어의 경계를 분리해서 테스트하기 쉽게 만들자.
하드웨어는 세부사항이다.
- 소프트웨어와 펌웨어 사이의 경계는 하드웨어 추상화 계층(Hardware Abstraction Layer, HAL)이라고 부른다.
- HAL은 자신보다 위에 있는 소프트웨어를 위해 존재하므로, HAL의 API는 소프트웨어의 필요에 맞게 만들어져야 한다.
- 특정 데이터를 소프트웨어는 어떤 장치에(플래시 메모리 또는 하드디스크) 영속화되는지는 알 수 없게끔 말이다.
HAL 사용자에게 하드웨어 세부사항을 드러내지 말라
- 클린 임베디드 아키텍처로 설계된 소프트ㅜ에어는 타깃 하드웨어 관계없이 테스트 가능하다.
- HAL 은 타깃에 상관없이 테스트할 수 있는 경계층 또는 일련의 대체 지점을 제공한다.
프로세스는 세부사항이다.
- 클린 임베디드 아키텍처라면 이들 장치 접근 레지스터를 직접 사용하는 코드는 소수의, 순전한 펌웨어로만 한정시켜야 한다.
- 이들 레지스터를 알고 있는 것은 모두 펌웨어가 되어야 하며, 따라서 실리콘 칩에 종속된다.
- 코드를 프로세스와 직접적으로 묶어버리면 안정적인 하드웨어가 출시되기 이전에 코드를 실행시키고자 할 때 어려움을 겪을 수 있다.
- 또한 임베디드 애플리케이션을 새로운 프로세서로 이식할 때도 곤란해질 것이다.
- 펌웨어가 저수준 함수들을 프로세서 추상화 계층(Processor Abstraction Layer, PAL)의 형태로 격리시켜줄 수 있다.
- PAL 상위에 위치하는 펌웨어는 타깃-하드웨어에 관계없이 테스트할 수 있게 되어, 펌웨어 자체도 덜 딱딱해질 수 있다.
운영체제는 세부사항이다.
- 작성한 코드의 수명을 늘리려면, 무조건 운영체제를 세부사항으로 취급하고 운영체제에 의존하는일을 막아야한다.
- OS 는 소프트웨어르르 펌웨어로부터 분리하는 계층이고 OS 를 직접 사용하면 문제가 된다.
- 클린 임베디드 아키텍처는 운영체제 추상화 계층(Operating System Abstraction Layer, OSAL)을 통해 소프트웨어를 운영체제로부터 격리시킨다.
- 함수 이름을 바꾸는 정도로 단순할 수도 있고, 여러 함수를 하나로 묶어야할 수도 있다.
- 만약 다른 OS로 이식한다면 작업의 대부분은 기존 OSAL 과 호환되도록 새로운 OSAL 을 작성하는데 소요될 것이다.
- 기존 복잡한 코드 덩어리를 수정하는 것보단 훨씬 낫다…
- OSAL은 테스트 지점을 만드는데 도움이 된다. 그 덕분에 소프트웨어 계층의 귀중한 애플리케이션 코드를 타깃이나 OS에 관계없이 테스트할 수 있게 된다.
인터페이스를 통하고 대체 가능성을 높이는 방향으로 프로그래밍하라
- HAL 을 추가하거나 때로는 OSAL을 추가해야 할 뿐만 아니라, 모든 주요 계층(소프트웨어, OS 펌웨어, 하드웨어) 내부에는 이 책에서 설명한 원칙들을 적용할 수 있다.(아니, 해야 한다.)
- 이들 원칙은 관심사를 분리시키고, 인터페이스를 활용하며, 대체 가능성을 높이는 방향으로 프로그래밍하도록 유도한다.
- 계층형 아키텍처(Layered Architecture)는 인터페이스를 통해 프로그래밍하자는 방상을 기반으로 한다.
- 모듈들이 서로 인터페이스를 통해 상호작용한다면 특정 서비스 제공자를 다른 제공자로 쉽게 대체할 수 있다.
- 그렇게 되면 테스트 하기도 더욱 쉬워질 것이다.
- 구현 세부사항의 가시성을 제한하라. 구현 세부사항은 변경될거라고 가정하라. 세부사항을 알고 있는 부분이 적을수록 추적하고 변경해야할 코드도 적어진다.
- 클린 임베디드 아키텍처에선 모듈들이 인터페이스를 통해 상호작용하기 떄문에 각각의 계층 내부에서 테스트가 가능하다.
- 각 인터페이스는 타깃과는 별개로 테스트할 수 있도록 해주는 경계층 또는 대체 지점을 제공한다.
DRY 원칙: 조건부 컴파일 지시자를 반복하지 말라
- 임베디드 시스템의 경우 타깃-하드웨어의 유형을 식별하는 조건 컴파일을 반복해서 사용할때가 많은데 그러면 다른 OS 로 이식하기 어려워지고 전체가 펌웨어가 되버린다..
- 하드웨어 추상화 계층(HAL)을 통해 세부사항을 가리자. 만약 이 HAL이 조건부 컴파일 대신 사용할 수 있는 일련의 인터페이스를 제공한다면, 우리는 링커 또는 어떤 형태의 실시간 바인딩을 사용해서 소프트웨어를 하드웨어와 연결할 수 있다.
결론
- 모든 코드가 펌웨어가 되도록 내버려두면 제품이 오래 살아남을 수 없게 된다.
- 오직 타깃 하드웨어에서만 테스트할 수 있는 제품도 마찬가지다.
- 클린 임베디드 아키텍처는 제품이 장기간 생명력을 유지하는데 도움을 준다.
Reference
- https://yrok.tistory.com/entry/%ED%81%B4%EB%A6%B0-%EC%95%84%ED%82%A4%ED%85%8D%EC%B2%98%EC%86%8C%ED%94%84%ED%8A%B8%EC%9B%A8%EC%96%B4-%EA%B5%AC%EC%A1%B0%EC%99%80-%EC%84%A4%EA%B3%84%EC%9D%98-%EC%9B%90%EC%B9%99Clean-Architecture-5%EB%B6%80-%EC%95%84%ED%82%A4%ED%85%8D%EC%B2%98-29%EC%9E%A5
- https://velog.io/@okstring/Clean-Architecture-5%EB%B6%80-%EC%95%84%ED%82%A4%ED%85%8D%EC%B2%98#%ED%83%80%EA%B9%83-%ED%95%98%EB%93%9C%EC%9B%A8%EC%96%B4-%EB%B3%91%EB%AA%A9%ED%98%84%EC%83%81