[클린 코드] 5주차: 11, 13장

11장: 시스템

• 높은 추상화 수준(시스템 수준)에서도 깨끗함을 유지해야 함
• 시스템 수준에서의 확장
• 관심사를 적절히 분리해 관리하면 소프트웨어 아키텍처는 점진적으로 발전할 수 있다.

관심사 분리

제작-사용 분리

• 관심사를 분리하지 않은 대표적인 경우
  • 초기화 지연/계산 지연: 필요할 때까지 객체 생성을 미루는 방법
    • 필요한 경우 그 때 생성하므로 생성자에 의존
    • 테스트를 위해 테스트 더블 필요
    • 일반 런타임 로직과 객체 생성 로직을 전부 테스트해야 함 → SRP 위반
• 시스템 생성-시스템 사용을 분리하는 방법
  1. main 분리
     • 생성은 main이나 main이 호출하는 모듈에 집약
     • main은 생성 역할, 애플리케이션은 생성된 객체 사용
     • 애플리케이션은 생성 과정에 대해 알 수 없음
  2. 팩토리
     • 애플리케이션은 생성 시점은 결정하지만 생성 방법은 모름
  3. 의존성 주입
     • 객체의 보조 책임을 새로운 객체에게 전적으로 위임

관점 분리

• 영속성과 같은 관심사는 애플리케이션 객체 경계를 넘나드는 경향이 있음
• 관점과 유사한 매커니즘
  1. 자바 프록시
  2. 순수 자바 AOP 프레임워크
  3. AspectJ
• 테스트 주도 시스템 아키텍처 구축
  • 도메인 로직을 POJO로 작성 → 코드 수준에서 아키텍처 관심사 분리 가능(헥사고날 아키텍처?)

결론

• 가능한 마지막 순간까지 결정을 미루는 방법이 최선 → 가장 적합한 객체에게 책임 위임
• 표준에 집착하지 말 것 → 가치가 확실한 경우에 표준 사용
• 도메인 특화 언어로 도메인 로직을 구현하면 잘못 구현될 가능성 감소

시스템을 설계하든 개별 모듈을 설계하든, 실제로 돌아가는 가장 간단한 수단을 사용해야 한다.

 

 

13장: 동시성

깔끔한 접근 방식을 취한다면 코드가 올바로 돌아갈 가능성이 극적으로 높아진다.

동시성

• 동시성이 필요한 이유
  • 구조적 개선
  • 동시성은 결합을 없에는 전략이다. 즉 무엇과 언제를 분리하는 전략이다.
  • 응답 시간과 처리량 개선
• 동시성과 관련된 일반적 미신과 오해
  • 동시성은 항상 성능을 높여주지는 않음
  • 단일 스레드 시스템과 다중 스레드 시스템은 설계가 크게 다름
  • 컨테이너를 사용해도 관련 문제를 해결하기 위해 동시성을 이해해야 함

동시성 방어 원칙

• 단일 책임 원칙: 동시성 관련 코드와 나머지 코드를 분리
• 따름 정리
  • 자료 범위 제한
    • 임계 영역의 수 줄이기
    • 공유 자원을 최대한 줄이기
  • 자료 사본 사용
    • 처음부터 공유하지 않기
  • 스레드는 가능한 독립적으로 구현

라이브러리 이해

• 스레드 세이프한 java.util.concurrent 패키지 활용

실행 모델 이해

• 생산자-소비자 문제, 읽기-쓰기 문제, 식사하는 철학자들 문제
• 위 문제들에 대한 기본 알고리즘과 해결 방법 이해하기

동기화 메서드 사이의 의존성 이해

• 공유 객체 하나에는 메서드 하나만 사용하기

동기화 크기 최소화

• synchronized 부분 최소화

종료 코드

• 올바른 종료 코드는 구현하기 어렵기 때문에 자주 사용되는 알고리즘 검토하기

스레드 코드 테스트

• 말이 안 되는 실패(이해하기 어려운 실패)는 스레드 문제로 취급
• 순차 코드부터 통과하도록 테스트 작성
  • 스레드 환경 밖에서 정상 작동하는지
  • POJO에 넣는 코드가 많을수록 좋음
• 다중 스레드 부분 테스트 작성
  • 다양한 환경에서도 정상 작동하는지
• 상황에 맞게 다중 스레드 부분을 조절할 수 있도록 테스트 작성
  • 성능 측정 방법을 통해 적절한 스레드 개수 파악
• 프로세서 수보다 많은 스레드 돌리기
• 다른 플랫폼에서 돌리기
• 코드에 보조 코드를 넣어 돌리기
  • 실행 순서, 실행 시간 등의 보조 코드를 추가해 실패를 강제하기