클린 임베디드 아키텍처
29. 클린 임베디드 아키텍처
소프트웨어는 닳지 않지만, 펌웨어와 하드웨어는 낡아 가므로 결국 소프트웨어도 수정해야 한다.
소프트웨어는 닳지 않지만, 펌웨어와 하드웨어에 대한 의존성을 관리하지 않으면 안으로부터 파괴될 수 있다.
ROM에 상주하는 코드만이 펌웨어는 아니다.
무엇에 의존하는지, 그리고 하드웨어 발전에 맞춰 수정하기가 얼마나 어려운지에 따라 정의된다.
펌웨어를 수없이 양산하는 일을 멈추고, 코드에게 유효 수명을 길게 늘릴 수 있는 기회를 주어라
앱-티튜드 테스트
소프트웨어를 구축하는 세 가지 활동
- “먼저 동작하게 만들어라” 소프트웨어가 동작하지 않는다면 사업은 망한다.
- “그리고 올바르게 만들어라” 코드를 리팩터링해서 당신을 포함한 나머지 사람들이 이해할 수 있게 만들고, 요구가 변경되거나 요구를 더 잘 이해하게 되었을 때 코드를 개선할 수 있게 만들어라
- “그리고 빠르게 만들어라” 코드를 리팩터링해서 ‘요구되는’ 성능을 만족시켜라
동작하는 것을 배우고 더 나은 해결책을 만들어라
앱이 동작하도록 만드는 것 -> 개발자용 앱-티튜드 테스트(App-titude test)
타깃-하드웨어 병목현상
클린 임베디드 아키텍처는 테스트하기 쉬운 임베디드 아키텍처다
계층
계층에는 여러가지가 있다.
맨 하단에는 하드웨어
최소한 하드웨어가 정의된 이후라면 하드웨어와 나머지 시스템 사이의 분리는 주어진다.
소프트웨어와 펌웨어가 서로 섞이는 일은 안티 패턴이다.
안티 패턴을 보이는 코드는 변화에 저항하게 된다.
변경하기 어려울 뿐 아니라 변경하는 일 자체가 위험을 수반하여, 때로는 의도치 않은 결과를 불러온다.
하드웨어는 세부사항이다
임베디드 소프트웨어 개발자가 해야 할 일 하나는 소프트웨어와 펌웨어 사이의 경게를 분명하게 만드는 것
소프트웨어와 펌웨어 사이의 경계는 하드웨어 추상과 계층(Hardware Abstraction Layer, HAL)이라고 부른다.
HAL은 자신보다 위에 있는 소프트웨어를 위해 존재하므로, HAL의 API는 소프트웨어의 필요에 맞게 만들어 져야 한다.
소프트웨어에는 어떻게 저장되는지 드러내지 않는다.
HAL 사용자에게 하드웨어 세부사항을 드러내지 마라
클린 임베디드 아키텍처로 설계된 소프트웨어는 타깃 하드웨어에 관계없이 테스트 가능
프로세서는 세부사항이다
클린 임베디드 아키텍처라면 장치 접근 레지스터를 직접 사용하는 코드는 소수의, 순전히 펌웨어로만 한정시켜야 한다.
운영체제는 세부사항이다
작성한 코드의 수명을 늘리려면, 무조건 운영체제를 세부사항으로 취급하고 운영체제에 의존하는 일을 막아야 한다.
OS는 소프트웨어를 펌웨어로부터 분리하는 계층
OS를 직접 사용했는데, OS가 변경되면 코드 수정할 일이 많아짐
클린 임베디드 아키텍처는 운영체제 추상화 계층(Operating System Abstraction Layer, OSAL)을 통해 소프트웨어를 운영체제부터 격리
OSAL은 테스트 지점을 만드는 데 도움이 되며, 그 덕분에 소프트웨어 계층의 귀중한 애플리케이션 코드를 타깃이나 OS에 관계없이 테스트할 수 있다.
인터페이스를 통하고 대체 가능성을 높이는 방향으로 프로그래밍하라
관심사를 분리시키고, 인터페이스를 활용하며, 대체 가능성을 높이는 방향으로 프로그래밍하도록 유도한다.
계층형 아키텍처는 인터페이스를 통해 프로그래밍하자는 발상을 기반으로 한다.
클린 임베디드 아키텍처에서는 모듈들이 인터페이스를 통해 상호작용하기 때문에 각각의 계층 내부에서 테스트가 가능
각 인터페이스는 타깃과는 별개로 테스트할 수 있도록 해주는 경계층 또는 대체 지점을 제공한다.
DRY 원칙: 조건부 컴파일 지시자를 반복하지 말라
참조
- 클린 아키텍처(Clean Architecture)