11장 시스템
✅ 테스트 주도 시스템 아키텍쳐 구축
단순하면서도 분리된 아키텍처로 소프트웨어 프로젝트를 진행해 결과물을 빠르게 출시한 후, 기반 구조를 추가하며 조금씩 확장해나갈 것
✅ 의사결정을 최적화하라
모듈을 나누고 관심사를 분리하면 지엽적인 관리와 결정이 가능해짐
✅ 명백한 가치가 있을 때 표준을 현명하게 사용할 것
모든 추상화단계에서 의도는 명확하게 표현해야함.
POJO를 작성하고, 관점 혹은 관점과 유사한 메커니즘을 사용해 각 구현 관심사를 분리해야 한다.
12장. 창발성
켄트 벡은 다음 규칙을 따르면 설계는 단순하다고 말한다
1. 모든 테스트를 실행한다
리팩터링 : 테스트 케이스를 모두 작성했다면 코드와 클래스를 정리해도 괜찮음
테스트 케이스가 있으므로 코드를 정리하면서 시스템이 깨질까 걱정할 필요가 없다
2. 중복을 없앤다
3. 프로그래머 의도를 표현한다
- 좋은 이름 선택할 것
- 함수와 클래스 크기 가능한 줄일 것
- 표준 명칭을 사용할 것
- 단위 테스트 케이스 꼼꼼하게 작성할 것
4. 클래스와 메서드 수를 최소로 줄인다
13장 동시성
동시성은 결합을 없애는 전략이다. 즉, 무엇과 언제를 분리하는 전략
✅ 동시성 방어 원칙
동시성 코드가 일으키는 문제로부터 시스템을 방어하는 원칙과 기술
👉 단일 책임 원칙(SRP)
SRP: 주어진 메서드/클래스/컴포넌트를 변경할 이유가 하나여야 한다.
즉, 동시성 관련 코드는 다른코드와 분리해야한다
👉 따름정리: 자료 범위를 제한하라
객체 하나를 공유한 후 동일 필드를 수정하던 두 스레드가 서로 간섭하므로 예상치 못한 결과를 내놓는 무제 발생
공유 객체 사용하는 코드 내 임계영역을 synchronized 키워드로 보호하라고 권장
👉 따름정리: 자료 사본을 사용할 것
👉 따름정리 : 스레드는 가능한 독립적으로 구현할 것
다른 스레드와 자료를 공유하지 않는 자신만의 세상에 존재하는 스레드 구현할 것
✅ 라이브러리를 이해하라
✅ 실행모델을 이용하라
✅ 동기화하는 메서드 사이에 존재하는 의존성을 이해하라
공유 객체 하나에는 메서드 하나만 사용할 것
공유 객체 하나에 여러 메서드가 필요할 경우, 다음 세가지 방법 고려하기
클라이언트에서 잠금 / 서버에서 잠금 / 연결 서버
✅ 동기화하는 부분을 작게 만들어라
✅ 올바른 종료코드는 구현하기 어렵다
✅ 스레드 코드 테스트 하기
문제를 노출하는 테스트 케이스를 작성할 것. 프로그램 설정과 시스템 설정과 부하를 바꿔가며 자주 돌려라. 테스트가 실패하면 원인을 추적할 것. 말이 안되는 실패는 잠정적인 스레드 문제로 취급하라
👉 다중 스레드를 고려하지 않은 순차코드부터 제대로 돌게 만들자
👉 다중 스레드를 쓰는 코드 부분을 상황에 맞게 조율할 수 있게 작성하라
👉 프로세서 수보다 많은 스레드를 돌려보라
👉 다른 플랫폼에서 돌려보라
👉 코드에 보조코드를 너어 돌려라. 강제로 실패를 일으키게 해보라