Skip to main content

11장 시스템

written by
Xednicoder
Xednicoder 🏆Front End Engineer

도시는 전체의 흐름은 몰라도 개인 또는 팀이 관리하는 구성요소는 효율적으로 돌아감(추상화와 모듈화) 이것이 시스템 수준에서 코드를 깨끗하게 유지하는 방법이다.

1) 시스템 제작과 시스템 사용을 분리하라!#

즉 준비 과정과 런타임 로직을 분리해야 한다.

(1) 관심사 분리(Separation of concerns)#

  • 소프트웨어 상에서 구조를 패턴, 역할, 기능 등을 각각 맞게 섹션 별로 분리해서 작성하는 것
  • 관심사 분리 관련 자료

(2) Main 분리#

  • 생성과 관련된 모든 코드는 main이나 main이 호출하는 모듈로 옮기고 나머지 시스템은 모든 객체가 생성되었고 모든 의존성이 연결되었다고 가정한다.
  • 즉 어플리케이션은 객체가 생성되는 과정을 전혀 모른다. (적절히 생성되었다고 가정)

(3) 팩토리#

  • 객체 생성 시점을 애플리케이션이 결정할 필요가 있을 때 Abstract Factory 패턴을 사용하여 생성 코드를 감춘다
  • Abstract Factory 패턴
  • 구체적인 클래스에 의존하지 않고 서로 연관되거나 의존적인 객체들의 조합을 만드는 인터페이스를 제공하는 패턴

(4) 의존성 주입#

  • 제어 역전 기법을 의존성 관리에 적용한 메커니즘
  • 한 개체가 맡은 보조 책임을 새로운 객체에게 전적으로 떠넘기고, 새로운 객체는 넘겨받은 책임만 맡으므로 SRP(단일 책임 원칙)를 만족시킴
  • 진정한 의존성 주입
  • 클래스가 의존성을 해결하려 시도하지 않는다. 대신 의존성을 주입하는 방법으로 설정자 메서드나 생성자 인수를 제공한다.
  • (ex : 배터리 일체형, 배터리 분리형)

2) 확장#

TDD(테스트 주도 개발), 리펙터링으로 얻어지는 깨끗한 코드는 코드 수준에서 시스템을 조정하고 확장하기 쉽게 만든다. 하지만 시스템 수준에서 아키텍처를 복잡한 아키텍처로 조금씩 키울 수는 없다. 소프트웨어 시스템은 관심사를 분리해 관리한다면 소프트웨어 아키텍쳐를 발전할 수 있다.

(1) 횡단 관심사#

3) 프록시#

  • 프록시를 사용하면 깨끗한 코드를 작성하기 어렵다.
  • 프록시는 시스템 단위로 실행 '지점'을 명시하는 메커니즘도 제공하지 않는다.

4) 순수 자바 AOP 프레임워크#

  • 대부분의 프록시 코드는 판박이라 도구로 자동화할 수 있다.
  • 테스트가 개념적으로 더 쉽고 간단하다.
  • 상대적으로 단순하기 때문에 미래 스토리에 맞춰 코드를 보수, 개선하기 편하다.
다시 말해, 아주 단순하면서도 멋지게 분리된 아키텍처로 소프트웨어 프로젝트를 진행해 결과물을 재빨리 출시한 후,기반 구조를 추가하며 조금씩 확장해나가도 괜찮습니다. 그렇다고 아무 방향 없이 프로젝트에 뛰어들어도 좋다는 의미는 아닙니다.프로젝트를 시작할 때는 일반적인 범위, 목표, 일정 그리고 결과로 내놓을 시스템의 일반적인 구조까지 생각해야 합니다.하지만 변하는 환경에 대처해 진로를 변경할 능력도 반드시 유지해야 합니다.

5) AspectJ 관점#

  • 관심사를 관점으로 분리하는 가장 강력한 도구는 AspectJ언어이다.
  • 관련 자료

6) 테스트 주도 시스템 아키텍처 구축#

  • 관점으로 관심사를 분리하는 방식은 그 위력이 막강하다.
  • 다시 말해, 아주 단순하면서도 멋지게 분리된 아키텍처로 소프트웨어 프로젝트를 진행해 결과물을 재빨리 출시한 후, 기반 구조를 추가하며 조금씩 확장해나가도 괜찮다.
  • 그렇다고 아무 방향 없이 프로젝트에 뛰어들어도 좋다는 의미는 아니다. (프로젝트를 시작할 때는 일반적인 범위, 목표, 일정 그리고 결과로 내놓을 시스템의 일반적인 구조까지 생각해야 합니다.)
  • 하지만 변하는 환경에 대처해 진로를 변경할 능력도 반드시 유지해야 합니다.

7) 의사 결정을 최적화해라#

  • 모듈을 나누고 관심사를 분리하면 지엽적인 관리와 결정이 가능해진다.
  • 아주 큰 시스템에서는 한 사람이 모든 결정을 내리기 어렵기 때문에, 가장 적합한 사람에게 책임을 맡기는 것이 가장 좋다.
  • 최대한 정보를 모아 최선의 결정을 내리기 위해서, 때때로 가능한 마지막 순간까지 결정을 미루는 방법이 최선이라는 사실을 까먹곤 한다.

8) 명백한 가치가 있을 때 표준을 현명하게 사용하라#

  • 표준을 사용하면 아이디어와 컴포넌트를 재사용하기 쉽고, 적절한 경험을 가진 사람을 구하기 쉬우며, 좋은 아이디어를 캡슐화하기 쉽고, 컴포넌트를 엮기 쉽다.
  • 하지만 때로는 표준을 만드는 시간이 너무 오래 걸려 업계가 기다리지 못하기도 하고, 어떤 표준은 원래 표준을 제정한 목적을 잊어버리기도 한다.
  • 따라서 아주 과장되게 포장된 표준에 집착하는 경우들을 경계해야 한다.

9) 결론#

  • 시스템은 역시 깨끗해야 한다.
  • 깨끗하지 못한 아키택처는 도메인 논리를 흐리며 기민성을 떨어뜨린다.
  • 도메인 논리가 흐려지면 제품 품질이 떨어진다.(버그가 숨어들기 쉽고, 스토리 구현이 어려워지는 탓, 기민성이 떨어지면 TDD가 제공하는 장점이 사라짐)
  • 모든 추상화 단계에서 의도는 명확히 표현해야 한다.(관심사 분리를 해야한다)
  • 실제로 돌아가는 가장 단순한 수단을 사용해야 한다.