시스템
관심사 분리
- Construction 제작은 Use 사용과 아주 다르다.
Main 분리
사용과 제작을 분리하는 강력한 매커니즘은 Dependency Injection (의존성 주입)
창발성
- 불시에 솟아나는 특성 ( 창발성: emergent property )
단순한 설계를 위한 네가지 규칙
- 켄트백이 제시한 규칙 네가지를 준수하면 설계는 단순하다라고 표현한다.
- 아래 목록은 중요도 순이다.
- 모든 테스트를 실행한다.
- 중복을 없앤다.
- 프로그래머 의도를 표현한다.
- 클래스와 메서드 수를 최소로 줄인다.
단순한 설계 규칙 1: 모든 테스트를 실행하라.
- 테스트 케이스를 만들고 계속 돌려라라는 간단하고 단순한 규칙을 따르면 시스템은 낮은 결합도와 높은 응집력이라는 객체 지향 방법론이 지향하는 목표를 저절로 달성한다.
- 즉 테스트를 작성하면 설계 품질이 높아진다
단순한 설계 규칙 2~4: 리팩터링
- 규칙 1의 테스트 케이스는 마음놓고 리팩터링 할 수 있는 배경을 제공한다.
- 리팩터링 단계에서는 소프트웨어 설계 품질을 높이는 어떠한 기법이라도 모두 적용한다.
중복을 없애라
표현하라
클래스와 메서드 수를 최소로 줄여라
- 이 규칙은 중요도 순위가 제일 낮다.
- 이 규칙은 클래스와 함수의 크기를 작게 유지하면서 동시에 시스템 크기도 작게 유지하는데 있다.
- 함수와 클래스의 크기를 줄이는 작업도 중요하지만, 테스트 케이스를 만들고 중복을 제거하고 의도를 표현하는 작업이 더 중요하다.
경험을 대신할 단순한 개발 기법이 있을까?
당연히 없다.
하지만 이책에서 소개하는 기법은 저자들이 수십 년 동안 쌓은 경험의 정수다.
동시성
동시성이 필요한 이유?
- 동시성은 결합(coupling)을 없애는 전략
- 무엇(what)과 언제(when)을 분리하는 전략
동시성에 관련된 일반적인 미신과 오해
- 동시성은 항상 성능을 높여준다.
- 동시성을 구현해도 설계는 변하지 않는다.
- 웹 또는 EJB 컨테이너를 사용하면 동시성을 이해할 필요가 없다.
동시성과 관련된 타당한 생각
- 동시성은 다소 부하를 유발한다.
- 동시성은 복잡하다.
- 일반적으로 동시성 버그는 재현하기 어렵다.
- 동시성을 구현하려면 흔히 근본적은 설계 전략을 재고해야 한다.
동시성 방어 원칙
동시성 코드는 다른 코드와 분리하라 (SRP)
자료를 캡슐화 하라. 공유 자료를 최대한 줄여라
자료 사본을 사용하라
스레드는 가능한 독립적으로 구현하라
동기화 메서드 사이의 의존성을 이해하라
동기화 하는 부분을 작게 만들어라
Gracefull Shutdown 코드는 구현하기 어렵다.
- 종료 코드를 개발 초기부터 고민하고 동작하게 구현하라.
스레드 코드를 테스트하라
일회성 문제는 없다. 잠재적 문제만 있을 뿐이다.
다중 스레드를 고려하지 않은 순차 코드부터 제대로 돌게 만들자
플랫폼 별로 스레드가 동작하는 방법이 다르다. 프로그램 동작이 예상되는 플랫폼에서 테스트하라.
코드에 보조 코드를 넣어 돌려라. 강제로 실패를 일으키게 하라.
점진적인 개선
프로그래밍은 과학보다 공예(craft)에 가깝다.
지저분한 코드를 짠뒤 코드를 정리해야 한다.
- 무조건 돌아가는 프로그램을 목표로 잡고 개발한다.
- 일단 돌아가면 다음 업무로 넘어간다.
- 돌아가는 프로그램은 그 상태가 어떻든 그대로 버려둔다.
- 이런 행동은 전문가로서 자살 행위이다.
reference