[클린 코드] 5. 시스템

 

Ch11. 시스템

레이 오지 (MS CTO) "복잡성은 죽음. 개발자에게서 생기를 앗아가며, 제품을 계획하고 제작하고 테스트하기 어렵게 만든다"

 

• 시스템 제작(construction) 과 사용(use) 을 분리하라
• S/W 시스템은 준비 과정 (app 객체 제작, 의존성 연결 등) 과 그 이후의 런타임 로직을 분리해야 한다
• 관심사 분리는 오래되고 중요한 설계 기법 중 하나. 대다수 app은 시작단계라는 관심사를 분리하지 않는다.
• Factory: 때론 객체가 생성되는 시점을 app이 결정할 필요도 생긴다.
• 의존성 주입 : 사용과 제작을 분리하는 강력한 메커니즘 중 하나
• 확장
• 의사결정을 최적화 : 모듈을 나누고 관심사를 분리하면 지엽적인 관리, 결정이 가능해진다
• 시스템은 도메인 특화 언어 (Domain-Specific Language,DSL) 가 필요하다.

결론

• 깨끗하지 못한 아키텍처는 도메인 논리를 흐리며 기민성을 떨어뜨린다.
• 모든 추상화 단계에서 의도는 명확히 표현해야 한다.

---

* 관심사 분리?

• 소프트웨어 개발에서 각각의 모듈이나 컴포넌트가 명확한 책임을 가지고 특정 관심사만 처리하도록 설계하는 원칙이며
• 이를 통해 코드의 가독성, 재사용성, 유지보수성을 높이는 것이 목표

 

관심사 (Concern)란?

- 소프트웨어에서 특정 기능, 역할, 혹은 책임을 의미. 예: 데이터베이스 접근, 사용자 인터페이스, 비즈니스 로직 등.

분리 (Separation)란?
- 서로 다른 관심사가 뒤섞이지 않도록 모듈화하거나 계층화하는 것.
- 각 모듈은 자신에게 주어진 역할만 수행하고 다른 관심사에는 의존하지 않도록 설계한다.

예시

 

- MVC 패턴 (Model-View-Controller)

• Model: 데이터 및 비즈니스 로직 관리.
• View: 사용자에게 데이터를 표시.
• Controller: 사용자의 입력을 처리하고 Model과 View를 연결. 관심사를 분리해 각 구성요소가 자신의 역할에만 집중하도록

- 레이어 아키텍처

• 프레젠테이션 계층: 사용자 인터페이스 처리.
• 애플리케이션 계층: 비즈니스 로직 수행.
• 데이터 계층: 데이터 저장 및 관리. 각 계층은 명확한 책임을 가지며, 다른 계층의 내부 구현에 의존하지 않는다.

- CSS와 JavaScript 분리

• HTML: 구조 정의.
• CSS: 디자인 및 스타일 정의.
• JavaScript: 동작 정의.

장점

1. 가독성 향상: 각 모듈이 하나의 관심사에 집중하므로 코드가 명확해진다
2. 유지보수 용이: 변경 사항이 생겼을 때 다른 부분에 미치는 영향을 최소화.
3. 재사용성 증가: 관심사가 분리된 코드는 다른 프로젝트나 모듈에서도 쉽게 활용할 수 있다.
4. 테스트 용이: 독립적인 관심사를 가진 모듈은 단위 테스트를 수행하기 쉽다

적용 시 주의점

1. 과도한 분리: 지나치게 세분화하면 오히려 복잡성이 증가할 수 있다.
2. 의존성 관리: 관심사를 분리했더라도 의존성이 얽히면 효과가 떨어질 수 있다.
3. 명확한 경계 설정: 모듈의 책임과 역할을 명확히 정의해야 한다.

 

도메인 특화 언어 (Domain-Specific Language, DSL)

특정 도메인이나 문제 영역에 특화되어 설계된 프로그래밍 언어나 스크립트 언어를 의미

범용 프로그래밍 언어(General-Purpose Language, GPL)와 달리, 특정 작업을 더 간결하고 효율적으로 표현할 수 있도록 설계

DSL의 유형

1. 내부 DSL (Internal DSL)
   • 기존 범용 언어 위에서 DSL을 구축
   • 예: Ruby의 RSpec, Python의 Flask 라우팅
2. 외부 DSL (External DSL)
   • 독립적인 언어로 설계되어, 별도의 파서와 인터프리터 또는 컴파일러가 필요
   • 예: SQL, HTML, 정규표현식