13장 동시성 동시성과 깔끔한 코드는 양립하기 어렵다. 1. 동시성이 필요한 이유? 동시성은 결합을 없애는 전략이다. 즉, 무엇과 언제를 분리하는 전략이다. 스레드가 하나인 프로그램은 무엇과 언제가 서로 밀접하다. 그래서 호출 스택을 살펴보면 프로그램 상태가 곧바로 드러난다. 흔히 단일 스레드 프로그램은 정지점(breakpoint)을 정한 후 어느 정지점인지 살펴보면서 시스템 상태를 파악한다. 무엇과 언제를 분리하면 애플리케이션 구조와 효율이 극적으로 나아진다. 구조적인 관점에서 프로그램은 거대한 루프 하나가 아니라 작은 협력 프로그램 여럿으로 보인다. 따라서 시스템을 이해하기가 쉽고 문제를 분리하기도 쉽다. 구조적 개선만을 위해 동시성을 채택하는 것은 아니다. 어떤 시스템은 응답 시간과 작업 처리량(t..

12장 창발성 창발성이란? 하위 체계로부터 생겨나지만, 그 하위 체계로 환원되지 않는 속성 1. 창발적 설계로 깔끔한 코드를 구현하자 모든 테스트를 실행한다. 중복을 없앤다. 프로그래머 의도를 표현한다. 클래스와 메서드 수를 최소로 줄인다. 위 네 가지 규칙을 착실하게 따르기만 하면 우수한 설계가 나오고 코드 구조와 설계를 파악하기 쉽고 SRP(단일 책임 원칙)나 DIP(의존 관계 역전 원칙)와 같은 원칙을 적용하기 쉽고 창발성을 촉진한다. 2. 단순한 설계 규칙 1 : 모든 테스트를 실행하라 무엇보다 먼저, 설계는 의도한 대로 돌아가는 시스템을 내놓아야 한다. 문서로는 시스템을 완벽하게 설계했지만 시스템이 의도한 대로 돌아가는지 검증할 간단한 방법이 없다면 문서 작성을 위해 투자한 노력에 대한 가치는 ..

11장 시스템 도시를 세운다면? 온갖 세세한 사항을 혼자서 직접 관리할 수 있을까? 불가능하다. 도시에는 큰 그림을 그리는 사람들도 있으며 수도, 전력, 교통 등 작은 사항에 집중하는 사람들도 있다. 도시가 돌아가는 또 다른 이유는 적절한 추상화와 모듈화 때문이다. 그래서 큰 그림을 이해하지 못할지라도 개인과 개인이 관리하는 구성요소는 효율적으로 돌아간다. 흔히 소프트웨어 팀도 도시처럼 구성한다. 그런데 막상 제작하는 시스템은 비슷한 수준으로 관심사를 분리하거나 추상화를 이뤄내지 못한다. 깨끗한 코드를 구현하면 낮은 추상화 수준에서 관심사를 분리하기 쉬워진다. 이 장에서는 높은 추상화 수준인 시스템에서도 깨끗함을 유지하는 방법을 살펴본다. 1. 시스템 제작과 시스템 사용을 분리하라 소프트웨어 시스템은 준..

10장 클래스 1. 클래스 체계 클래스를 정의하는 표준 자바 관례에 따르면 가장 먼저 변수 목록이 나오고 변수 목록 다음에는 공개 함수가 나온다. 변수: 정적 공개 상수 -> 정적 비공개 변수 -> 비공개 인스턴스 변수 -> 공개 변수 비공개 함수는 자신을 호출하는 공개 함수 직후에 넣는다. 즉, 추상화 단계가 순차적으로 내려간다. 1) 캡슐화 변수와 유틸리티 함수는 가능한 공개하지 않는 편이 낫지만 반드시 숨겨야 한다는 법칙도 없다. 때로는 protected로 선언해 테스트 코드에 접근을 허용하기도 한다. 그러나 그전에 비공개 상태를 유지할 온갖 방법을 강구하고 캡슐화를 푸는 결정은 최후의 수단이다. 2. 클래스는 작아야 한다! 함수와 마찬가지로 클래스 설계의 기본은 '작게'이다. 큰 클래스 몇 개가 ..

9장 단위 테스트 지난 1997년만 해도 TDD라는 개념을 아무도 몰랐고 단위 테스트란 자기 프로그램이 돌아간다는 사실만 확인하는 일회성 코드에 불과했다. 클래스와 메서드를 공들여 구현한 후 임시 코드를 급조해 테스트를 수행했는데 대개는 간단한 드라이버 프로그램을 구현해 자신이 짠 프로그램을 수동으로 실행했다. 하지만 지금은 눈부신 성장을 이뤘다. 꼬치꼬치 따지며 코드가 제대로 도는지 확인하는 테스트 코드를 작성하고 테스트 케이스를 모두 구현하고 통과한 후에는 내 코드를 사용할 사람들에게도 공개하고 테스트 코드와 내 코드를 같은 소스 패키지로 묶어 체크인한다. 애자일과 TDD 덕택에 단위 테스트를 자동화하는 프로그래머들이 이미 많아졌으며 점점 더 늘어나는 추세이다. 하지만 우리 분야에 테스트를 추가하려고..

8장 경계 시스템에 들어가는 모든 소프트웨어를 직접 개발하는 경우는 드물다. 때로는 패키지를 사고 오픈 소스를 이용한다. 어떤 식으로든 이 외부 코드와 우리 코드의 경계를 깔끔하게 처리하고 통합해야 한다. 1. 외부 코드 사용하기 패키지 제공자나 프레임워크 제공자는 적용성을 최대한 넓혀 더 많은 환경에서 돌아가길 원한다. 하지만 사용자는 자신의 요구에 집중하는 인터페이스를 더 원한다. 예로 java.util.Map을 살펴보자. Map이 제공하는 기능성과 유연성은 확실히 유용하지만 그만큼 위험도 크다. 넘기는 쪽에서는 Map 내용을 삭제하지 않으리라 믿을 수 있지만, Map이 제공하는 메서드 중 Clear()가 존재한다. 즉, Map 사용자라면 누구나 Map 내용을 지울 수 있다. 어떤 클래스를 저장하는 ..