byungil

27장. 크고 작은 모든 서비스들

  • 서비스 지향 아키텍처와 마이크로서비스 아키텍처는 최근에 큰 인기를 끌고 있는데, 그 이유는 ㅏㄷ음과 같음

    • 서비스를 사용하면 상호 결합이 철저하게 분리되는 것처럼 보인다. 나중에 보겠지만, 이는 일부만 맞는 말이다.

    • 서비스를 사용하면 개발과 배포 독립성을 지원하는 것처럼 보인다. 나중에 보겠지만, 이 역시도 일부만 맞는 말이다.

서비스 아키텍처?

  • 먼저 서비스를 사용한다는 것은 본질적으로 아키텍처에 해당하지 않음

  • 시스템 아키텍처는 의존성 규칙을 준수하며 고수준의 정책을 저수준의 정책으로부터 분리하는 경계에 의해 정의됨

  • 단순히 애플리케이션의 행위를 분리할 뿐인 서비스라면 값비싼 함수 호출에 불과하며, 아키텍처 관점에서 꼭 중요하다고 볼 수 없음

  • 아키텍처적으로 중요한 서비스도 있지만, 중요하지 않은 서비스도 존재하는데, 이 장에서 우리가 관심을 갖는 서비스는 전자임

야옹이 문제

  • 서비스 다이어그램을 살펴보면 이 기능을 구현하려면 이들 서비스 전부를 변경해야 함

    • 의심의 여지 없이 야옹이 배달 기능을 추가하려면 개발과 배포 전략을 모두 신중하게 조정해야 함

    • 다시 말해 이 서비스들은 모두 결합되어 있어서 독립적으로 개발하고, 배포하거나 유지될 수 없음

  • 이게 바로 횡단 관심사가 지닌 문제임

    • 모든 소프트웨어 시스템은 서비스 지향이든 아니든 이 문제에 직면하기 마련임

    • 위의 서비스 다이어그램과 같은 종류의 기능적 분해는 새로운 기능이 기능적 행위를 횡단하는 상황에 매우 취약함

28장. 테스트 경계

  • 테스트는 시스템의 일부이며, 시스템의 나머지 요소가 아키텍처에 관여하는 것과 동등하게 아키텍처에도 관여함

  • 어떤 면에서는 정말 평범하게 관여하고, 또 다른 면에서는 상당히 독특하게 관여함

테스트를 고려한 설계

  • 테스트가 시스템의 설계와 잘 통합되지 않으면 테스트는 깨지기 쉬워지고, 시스템은 뻣뻣해져서 변경하기가 어려워짐

  • 시스템에 강하게 결합된 테스트라면 시스템이 변경될 때 함게 변경되어야만 함

    • 시스템 컴포넌트에서 생긴 아주 사소한 변경도, 이와 결합된 수 많은 테스트를 망가뜨릴 수 있음

    • 시스템의 공통 컴포넌트가 변경되면 수백, 수천 개의 테스트가 망가지며, 이는 "깨지기 쉬운 테스트 문제"로 알려져있음

    • 깨지기 쉬운 테스트는 시스템을 뻣뻣하게 만드는 부작용을 낳을 때가 많음

    • 시스템에 가한 간단한 변경이 대량의 테스트 실패로 이어진다면, 개발자는 변경을 하지 않을 것임

  • 이를 해결하려면 테스트를 고려해서 설계해야 하며, 소프트웨어 설계의 첫 번째 규칙은 언제나 변동성이 있는 것에 의존하지 않는 것

  • GUI는 변동성이 크므로 시스템과 테스트를 설계할 때 GUI를 사용하지 않고 업무 규칙을 테스트할 수 있게 해야 함

테스팅 API

  • 모든 클래스에 테스트 클래스가 각각 존재하고, 또 모든 메소드에 테스트 메소드 집합이 존재하는 테스트 스위트는 강하게 결합됨

  • 클래스나 메소드 중 하나라도 변경되면 딸린 다수의 테스트가 변경되어야 함

  • 결과적으로 테스트는 깨지기 쉬워지고, 이로 인해 상용 코드를 뻣뻣하게 만듬

  • 구조적 결합이 강하면 필수적인 진화 과정을 방해할 뿐만 아니라, 상용 코드의 범용성과 유연성이 충분히 좋아지지 못함

결론

  • 테스트는 시스템 외부에 있지 않고 시스템의 일부이므로, 테스트를 통한 안정성과 회귀의 이점을 얻으려면 잘 설계 되어야 함

  • 테스트를 시스템의 일부로 설계하지 않으면, 테스트는 깨지기 쉽고 유지보수가 어려워지는 경향이 있음

  • 이러한 테스트는 유지보수하기 너무 힘들기 때문에 방바닥의 휴지처럼 버려지는 최후를 맡게 됨

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

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

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

  • 안드로이드 앱 개발자 역시 업무 로직을 안드로이드 API로부터 분리하지 않는다면 펌웨어를 작성하는 셈임

앱-ㅌ튜드 테스트

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

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

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

Previous6weekNextheegeon

Last updated