5부. 아키텍처6

29장 클린 임베디드 아키텍처

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

• 임베디드 엔지니어가 아닌 엔지니어들도 또한 펌웨어를 작성할 수 있음

• 코드에 SQL을 심어두거나, 개발하는 코드 전반에 플랫폼 의존성을 퍼뜨려 놓는다면 본질적으로 펌웨어를 작성하는 셈임

앱-티튜드(App-titude) 테스트

• 켄트백은 소프트웨어를 구축하는 세 가지 활동을 다음과 같이 기술했고, 설명은 글쓴이가 덧붙인 해설임

  • 먼저 동작하게 만들어라: 소프트웨어가 동작하지 않는다면 사업은 망한다.

  • 그리고 올바르게 만들어라: 코드를 리팩토링해서 당신을 포함한 나머지 사람들이 이해할 수 있게 만들고, 요구가 변경되거나 요구를 더 잘 이해하게 되었을 때 코드를 개선할 수 있게 만들어라.

  • 그리고 빠르게 만들어라: 코드를 리팩토링해서 ‘요구되는’ 성능을 만족시켜라

대다수의 앱들도 코드를 올바르게 작성해서 유효 수명을 길게 늘리는 데는 거의 관심 없이, 그저 동작하도록 만들어진다.

프로그래밍에는 단순히 앱이 동작하도록 만드는 것보다 중요한 것이 훨씬 많다.

타겟-하드웨어 병목현상

• 계층 분리

• 하드웨어는 세부사항이다

  • 소프트웨어와 펌웨어 사이의 경계는 하드웨어 추상화 계층(Hardware Abstraction Layer, HAL)이라고 부른다. HAL은 자신보다 위에 있는 소프트웨어를 위해 존재하므로, HAL의 API는 소프트웨어의 필요에 맞게 만들어져야 한다.

• HAL 사용자에게 하드웨어 세부사항을 드러내지 말라

• 프로세서는 세부사항이다

• 운영체제는 세부사항이다

  • 운영체제 추상화 계층(Operating System Abstraction Layer, OSAL)을 통해 소프트웨어를 운영체제로부터 격리시킨다.

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

HAL을 추가하거나 때로는 OSAL을 추가해야 할 뿐만 아니라, 모든 주요 계층(소프트웨어, OS 펌웨어, 하드웨어) 내부에는 이 책에서 설명한 원칙들을 적용할 수 있다.

이들 원칙은 관심사를 분리시키고, 인터페이스를 활용하며, 대체 가능성을 높이는 방향으로 프로그래밍하도록 유도한다. 계층형 아키텍처(Layered Architecture)는 인터페이스를 통해 프로그래밍하자는 발상을 기반으로 한다.

DRY(Don'y Repeat Yourself) 원칙 : 조건부 컴파일 지시자를 반복하지 말라