클린코드 13장 동시성

 “객체는 처리의 추상화다. 스레드는 일정의 추상화다.” - 제임스 O. 코플리

동시성과 깔끔한 코드는 양립하기 어렵다. 스레드를 하나만 실행 하는 코드는 짜기가 쉽다.

겉으로 보기에는 멀쩡해 보이는 다중 스레드코드도 짜기 쉽다. 이런코드는 시스템이 부하를 받기 전까지 멀쩡 하게 돌아간다.

이 장에서는 여러 스레드를 동시에 돌리는 이유를 논하고 여러 스레드를 동시에 돌리는 어려움도 논한다. 이런 어려움에 대처하고 깨끗한 코드를 작성하는 방법도 몇 가지 제안한다. 마지막으로, 동시성을 테스트하는 방법과 문제점을 논한다.

동시성이 필요한 이유?

동시성은 결합(coupling)을 없애는 전략이다. 즉, 무엇(what)과 언제(when)를 분리하는 전략이다.

스레드가 하나인 프로그램은 무엇과 언제가 서로 밀접하다. 그래서 호출 스택을 살펴보면 프로그램 상태가 곧바로 드러난다.

무엇(what)과 언제(when)를 분리하면 애플리케이션 구조와 효율이 극적으로 나아진다. 구조적인 관점에서 프로그램은 거대한 루프 하나가 아니라 작은 협력 프로그램 여럿으로 보인다. 따라서 시스템을 이해하기가 쉽고 문제를 분리하기도 쉽다.

구조적 개선만을 위해 동시성을 채택하는 건 아니다. 어떤 시스템은 응답 시간과 작업 처리량 개선이라는 요구사항으로 인해 직접적인 동시성 구현이 불가피하다. (예를 들면 웹 사이트 정보 수집기, 사용자 처리 시스템, 대량 정보 분석하는 시스템 등등)

미신과 오해

• 동시성은 항상 성능을 높여준다.

  대기 시간이 아주 길어 여러 스레드가 프로세서를 공유할 수 있거나 여러 프로세서가 동시에 처리할 독립적인 계산이 충분히 많은 경우에만 성능이 높아진다.

• 동시성을 구현해도 설계는 변하지 않는다.

  단일 스레드 시스템과 다중 스레드 시스템은 설계가 판이하게 다르다. 일반적으로 무엇과 언제를 분리하면 시스템 구조가 크게 달라진다.

• 웹 또는 EJB 컨테이너를 사용하면 동시성을 이해할 필요가 없다.

  실제로는 컨테이너가 어떻게 동작하는지, 어떻게 동시 수정, 데드락 등과 같은 문제를 피할 수 있는지를 알아야만 한다.

동시성과 관련된 타당한 생각 몇 가지

• 동시성은 다소 부하를 유발한다. 성능 측면에서 부하가 걸리며 코드도 더 짜야한다.
• 동시성은 복잡하다. 간단한 문제라도 동시성은 복잡하다.
• 일반적으로 동시성 버그는 재현하기 어렵다. 그래서 진짜 결함으로 간주되지 않고 일회성 문제로 여겨 무시하기 쉽다.
• 동시성을 구현하려면 흔히 근본적인 설계 전략을 재고해야 한다.

난관

동시에 다른 스레드가 같은 객체를 사용하게 될 때 원하는 값을 못받을 수 있다. 대다수는 올바른 결과를 내지만, 문제는 잘못된 결과를 내놓는 일부가 존재한다는 것이다.

동시성 방어 원칙

단일 책임 원칙(Single Responsibility Principle, SRP)

SRP는 주어진 메서드/클래스/컴포넌트를 변경할 이유가 하나여야 한다는 원칙이다.

동시성은 복잡성 하나만으로도 따로 분리할 이유가 충분하다. 즉, 동시성 관련 코드는 다른 코드와 분리해야 한다는 뜻이다.

동시성 구현시 고려 사항

• 동시성 코드는 독자적인 개발, 변경, 조율 주기가 있다.
• 동시성 코드에는 독자적인 난관이 있다. 다른 코드에서 겪는 난관과 다르며 훨씬 어렵다.
• 잘못 구현한 동시성 코드는 별의별 방식으로 실패한다. 주변에 있는 다른 코드가 발목을 잡지 않더라도 동시성 하나만으로도 충분히 어렵다.

권장사항: 동시성 코드는 다른 코드와 분리하라.

따름 정리(corollary): 자료 범위를 제한하라

객체 하나를 공유한 후 동일 필드를 수정하던 두 스레드가 서로 간섭하므로 예상치 못한 결과를 내놓는다.

공유 객체를 시용하는 코드 내 임계영역(critical section)을 synchronized 키워드로 보호하라고 권장한다. 이런 임계영역의 수를 줄이는 기술이 중요하다.

공유자료를 수정하는 위치가 많을수록 커지는 문제

• 보호할 임계영역을 빼먹는다. 그래서 공유 자료를 수정하는 모든 코드를 망가뜨린다.
• 임계영역을 올바르게 보호했는지 확인하느라 똑같은 노력과 수고를 반복한다.
• 찾기 어려운 버그가 더 찾기 어렵게 된다.

권장사항: 자료를 캡슐화하라. 공유 자료를 최대한 줄여라.

따름 정리: 자료 사본을 사용하라

공유 자료를 줄이려면 처음부터 공유하지 않는 방법이 제일 좋다. 어떤 경우에는 객체를 복사해 읽기 전용으로 사용하는 방법이 가능하다. 어떤 경우에는 각 스레드가 객체를 복사해 사용한 후 한 스레드가 해당 사본에서 결과를 가져오는 방법도 가능하다.

공유자료를 피하는 방법이 있다면 코드가 문제를 일으킬 가능성도 아주 낮아진다. 물론 객체를 복사하는 시간과 부하가 걱정스러울지 모르겠으나 복사 비용으 진짜 문제인지 실측해 볼 필요가 있다. (하지만 사본으로 동기화를 피할 수 있다면 내부 잠금을 없애 절약한 수행시간이 사본 생성과 가비지 컬렉션에 드는 부하를 상쇄할 가능성이 크다)

따름정리: 스레드는 가능한 독립적으로 구현하라

자신만의 세상에 존재하는 스레드를 구현한다. 즉, 다른 스레드와 자료를 공유 하지 않는다. 각 스레드는 클라이언트 요청 하나를 처리한다.모든 정보는 비공유 출처에서 가져오며 로컬 변수에 저정한다. 그러면 각 스레드는 세상에서 자신만 있듯이 돌아간다.

권장사항: 독자적인 스레드로, 가능하면 다른 프로세서에서, 돌려도 괜찮도록 자료를 독립적인 단위로 분할하라.

라이브러리를 이해하라

최신 자바 라이브러리를 검색해서 이해할 필요성이 있음. (자바5 기준으로 정리 되어 있어서 혼란을 줄 수 있기 때문에 따로 정리 하지 않음)

실행 모델을 이해하라

• 한정된 자원 (Bound Resource)
  • 다중 스레드 환경에서 사용하는 자원으로, 크기나 숫자가 제한적이다. 대이터베이스 연결, 길이가 일정한 읽기/쓰기 버퍼 등이 예다.
• 상호 배제 (Mutual Exclusion)
  • 한 번에 한 스레드만 공유 자료나 공유 자원을 사용할 수 있는 경우를 가리킨다.
• 기아 (Starvation)
  • 특정 스레드가 굉장히 오랫동안 또는 영원히 자원을 기다리는 경우오랫동안 혹은 영원히 자원을 기다린다. 예를 들어, 항상 짧은 스레드에게 우선순위를 준다면, 짧은 스레드가 지속적으로 이어질 경우, 긴 스레드가 기아 상태에 빠진다.
• 데드락 (Deadlock)
  • 여러 스레드가 서로가 끝나기를 기다린다. 모든 스레드가 각기 필요한 지원을 다른 스레드가 점유하는 바람에 어느 쪽도 더 이상 진행하지 못한다.
• 라이브락 (Livelock)
  • 락을 거는 단계에서 각 스레드가 서로를 방해한다. 스레드는 계속해서 진행하려 하지만, 공명(resonance)으로 인해, 굉장히 오랫동안 혹은 영원히 진행하지 못한다.

생산자-소비자

하나 이상 생산자 스레드가 정보를 생성해 빈 공간이 있으면 (없으면 대기) 버퍼나 대기열에 넣는다. 하나 이상 소비자 스레드가 대기열에서 정보가 있으면 (없으면 대기) 정보를 가져와 사용한다. 생산자 - 소비자 스레드가 사용하는 대기열은 한정된 자원이다

생산자 스레드는 대기열에 정보를 채운 다음 소비자 스레드에게 시그널을 보낸다. 소비자 스레드는 대기열에서 정보를 읽어들인 후 생산자에게 시그널을 보낸다. 잘못하면 생성자 스레드와 소비자 스레드가 둘 다 진행 가능함에도 불구하고 동시에 서로에게서 시그널을 기다릴 가능성이 존재한다.

읽기-쓰기

읽기 스레드를 위한 주된 정보원으로 공유 자원을 사용하지만, 쓰기 스레드가 이 공유 자원을 이따금 갱신한다고 하자. 이런 경우 처리률이 문제의 핵심이다. 처리율을 강조하면 기아 현상이 생기거나 오래된 정보가 쌓인다. 갱신을 허용하면 처리율에 영향을 미친다.

따라서 읽기 스레드의 요구와 쓰릭 스레드의 요구를 적절히 만족시켜 처리율도 적당히 높이고 기아도 방지하는 해법이 필요하다.

식사하는 철학자들

두근 식타에 철학자 한 무리가 둘러앉았다. 각 철학자 왼쪽에는 포크가 놓였다. 식탁 가운데는 커다란 스파게티 한 접시가 놓였다. 철학자들은 배가 고프지 않으면 생각하며 시간을 보낸다. 배가 고프면 양손에 포크를 집어들고 스파게티를 먹는다. 양손에 포크를 쥐지 않으면 먹지 못한다. 왼쪽 철학자나 오른쪽 첡하자가 포크를 사용한 중이라면 그쪽 철학자가 먹고 나서 포크를 내려놓고 배가 고플 때까지 다시 생각에 잠긴다.

여기에서 철학자를 스레드로, 포크를 자원으로 바꿔 생각하면 많은 기업 애플리케이션이 겪는 문제다. 기업 애플리케이션은 여러 프로세스가 자원을 얻으려 경쟁한다. 주의해서 설계하지 않으면 데드락, 라이브락, 처리율 저하, 효율성 저하등의 상황을 겪는다.

권장사항: 위에서 설명한 기본 알고리즘과 각 해법을 이해하라

동기화하는 메서드 사이에 존재하는 의존성을 이해하라

동기화하는 메서드 사이에 의존성이 존재하면 동시성 코드에 찾아내기 어려운 버그가 생긴다. 자바 언어는 개별 메서드를 보호하는 synchronized라는 개념을 지원한다. (하지만 공유 클래스 하나에 동기화된 메서드가 여럿이라면 구현이 올바른지를 다시 한 번 확인하기 바란다.)

권장사항: 공유 객체 하나에는 메서드 하나만 사용하라

공유객체 하나에 여러 메서드가 필요한 경우

• 클라이언트에서 잠금 : 클라이언트에서 첫 번째 메서드를 호출하기 전에 서버를 잠근다.
• 서버에서 잠금 : 서버를 잠그고 모든 메서드를 호출한 후 잠금을 해제하는 메서드를 구현한다.
• 연결 서버 : 잠금을 수행하는중간단계 를 생성한다.

동기화하는 부분을 작게 만들어라

자바에서 synchronized 키워드를 사용하면 락을 설정한다. 같은 락으로 감싼 모든 코드 영역은 한 번에 한 스레드만 실행이 가능하다. 락은 스레드를 지연시키고 부하를 가증시킨다. 그러므로 synchronized 문을 남발하는 코드는 바람직하지 않다.

하지만 임계영역은 반드시 보호해야 한다. 따라서 코드를 짤때는 임계영역수를 최대한 줄여야 한다. 그렇다고 임계영역 크기를 키우면 스레드 간에 경쟁이 늘어나고 프로그램 성능이 떨어진다.

권장사항: 동기화하는 부분을 최대한 작게 만들어라

올바른 종료 코드는 구현하기 어렵다

영구적으로 돌아가는 시스템을 구현하는 방법과 잠시 돌다 깔끔하게 종료하는 시스템을 구현하는 방법은 다르다. 깔끔하게 종료하는 코드는 올바로 구현하기 어렵다. 가장 흔히 발생하는 문제가 데드락이다. 즉, 스레드가 절대 오지 않을 시그널을 기다린다. 그러므로 깔끔하게 종료하는 다중 스레드 코드를 짜야 한다면 시간을 투자해 올바로 구현하기 바란다.

권장사항: 종료 코드를 개발 초기부터 고민하고 동작하게 초기부터 구현하라. 생각보다 오래 걸린다. 생각보다 어려우므로 이미 나온 알고리즘을 검토하라.

스레드 코드 테스트하기

코드가 올바르다고 증명하기는 현실적으로 불가능하다, 테스트가 정확성을 보장하지는 않는다. 그럼에도 충분한 테스트는 위험을 낮춘다. 스레드가 하나일때는 이 말이 옳지만 스레드가 둘 이상으로 늘어나면 상황은 급격하게 복잡해진다.

권장사항: 문제를 노출하는 테스트 케이스를 작성하라. 프로그램 설정과 시스템 설정과 부하를 바꿔가며 자주 돌려라. 테스트가 실패하면 원인을 추적하라. 다시 돌렸더니 통과하더라는 이유로 그냥 넘어가면 절대로 안 된다.

구체적인 여러 지침

• 말이 안 되는 실패는 잠정적인 스레드 문제로 취급하라
• 다중 스레드를 고려하지 않은 순차 코드부터 제대로 돌게 만들자
• 다중 스레드를 쓰는 코드 부분을 다양한 환경에 쉽게 끼워 넣을 수 있게 스레드 코드를 구현하라
• 다중 스레드를 쓰는 코드 부분을 상황에 맞게 조율할 수 있게 작성하라
• 프로세서 수보다 많은 스레드를 돌려보라
• 다른 플랫폼에서 돌려보라
• 코드에 보조 코드(instrument)를 넣어 돌려라. 강제로 실패를 일으키게 해보라

말이 안 되는 실패는 잠정적인 스레드 문제로 취급하라

다중 스레드 코드는 때때로 말이 안 되는 오류를 일으킨다. 대다수의 개발자는 스레드가 다른 코드와 교류하는 방식을 직관적으로 이해하지 못한다. 그래서 많은 개발자가 하드웨어 문제, 단순한 ‘일회성’ 문제로 치부하고 무시한다.

일회성 문제란 존재하지 않는다고 가정하는 편이 안전하다. 일회성 문제를 계속 무시한다면 잘못된 코드 위에 코드가 계속 쌓인다.

권장사항: 시스템 실패를 ‘일회성’이라 치부하지 마라.

다중 스레드를 고려하지 않은 순차 코드부터 제대로 돌게 만들자

당연한 소리지만 다시 한 번 강조한다. 스레드 환경 밖에서 코드가 제대로 도는지 반드시 확인한다. 일반적인 방법으로, 스레드가 호출하는 POJO를 만든다. POJO는 스레드를 모른다. 따라서 스레드 환경 밖에서 테스트가 가능하다. POJO에 넣는 코드는 많을수록 더 좋다.

권장사항: 스레드 환경 밖에서 생기는 버그와 스레드 환경에서 생기는 버그를 동시에 디버깅하지 마라. 먼저 스레드 환경 밖에서 코드를 올바로 돌려라.

다중 스레드를 쓰는 코드 부분을 다양한 환경에 쉽게 끼워 넣을 수 있게 스레드 코드를 구현하라

다중 스레드를 쓰는 코드를 다양한 설정으로 실행하기 쉽게 구현하라.

• 한 스레드로 실행하거나, 여러 스레드로 실행하거나, 실행 중 스레드 수를 바꿔본다.
• 스레드 코드를 실제 환경이나 테스트 환경에서 돌려본다.
• 테스트 코드를 빨리, 천천히, 다양한 속도로 돌려본다.
• 반복 테스트가 가능하도록 테스트 케이스를 작성한다.

권장사항: 다양한 설정에서 실행할 목적으로 다른 환경에 쉽게 끼워 넣을 수 있게 코드를 구현하라.

다중 스레드를 쓰는 코드 부분을 상황에 맞게 조율할 수 있게 작성하라

적절한 스레드 개수를 파악하려면 상당한 시행착오가 필요하다. 처음부터 다양한 설정으로 프로그램의 성능 측정 방법을 강구한다.

스레드 개수를 조율하기 쉽게 코드를 구현한다. 프로그램이 돌아가는 도중에 스레드 개수를 변경하는 방법도 고려한다. 프로그램 처리율과 효율에 따라 스스로 스레드개수를 조율하는 코드도 고민한다.

프로세서 수보다 많은 스레드를 돌려보라

시스템이 스레드를 스와핑(swapping)할 때도 문제가 발생한다. 스와핑을 일으키려면 프로세서 수보다 많은 스레드를 돌린다. 스와핑이 잦을수록 임계영역을 빼먹은 코드나 데드락을 일으키는 코드를 찾기 쉬워진다.

다른 플랫폼에서 돌려보라

다중 스레드 코드는 플랫폼에 따라 다르게 돌아간다. 따라서 코드가 돌아갈 가능성이 있는 플랫폼 전부에서 테스트를 수행해야 마땅하다.

권장사항: 처음부터 그리고 자주 모든 목표 플랫폼에서 코드를 돌려라.

코드에 보조 코드(instrument)를 넣어 돌려라. 강제로 실패를 일으키게 해보라

스레드 버그가 산발적이고 우발적이고 재현이 어려운 이유는 코드가 실행되는 수천 가지 경로 중에 아주 소수만 실패하기 때문이다. 보조코드를 추가해 코드가 실행되는 순서를 바꿔주어 오류를 좀 더 자주 일으킬수 있도록 할 수 있다.

결론

다중 스레드 코드는 올바로 구현하기 어렵다. 다중 스레드 코드를 작성한다면 각별히 깨끗하게 코드를 짜야 한다. 주의하지 않으면 희귀하고 오묘한 오류에 직면하게 된다.

무엇보다 먼저 SRP를 준수한다. POJO를 사용하 스레드를 아는 코드와 스레드를 모르는 코드를 분리한다. 스레드 코드를 테스트할 때는 전적으로 스레드만 테스트한다. 즉, 스레드 코드는 최대한 집약되고 작아야 한다는 의미이다.

동시성 오류를 일으키는 잠정적인 원인을 철저히 이해한다.

사용하는 라이브러리와 기본 알고리즘을 이해한다.

보호할 코드 영역을 찾아내는 방법과 특정 코드 영역을 잠그는 방법을 이해한다.

어떻게든 문제는 생긴다. 초반에 드러나지 않는 문제는 일회성으로 치부해 무시하기 십상이다. 소위 일회성 문제는 대개 시스템에 부하가 걸릴 때나 아니면 뜬금없이 발생한다. 그러므로 스레드 코드는 많은 플랫폼에서 많은 설정으로 반복해서계속 테스트해야 한다.

테스트 용이성은 TDD 3대 규칙을 따르면 자연히 얻어진다.

• 실패하는 단위테스트를 작성할 때까지 실제 코드를 작성하지 않는다.
• 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위테스트를 작성한다.
• 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다.

시간을 들여 보조 코드를 추가하면 오류가 드러날 가능성이 크게 높아진다.

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

클린코드 12장 창발성

 

창발적 설계로 깔끔한 코드를 구현하자

착실하게 따르기만 하면 우수한 설계가 나오는 간단한 규칙 네가지가 있다면? 네 가지 규칙을 따르면 코드 구조와 설계를 파악하기 쉬워진다면? 그래서 SRP나 DIP와 같은 원칙을 적용하기 숴우진다면? 네 가지 규칙이 우수한 설계의 찰발성을 촉진한다면?

우리들 대다수는 켄트 벡이 제시한 단순한 설계 규칙 네 가지가 소프트웨어 품질을 크게 높여준다고 믿는다. (중요도 순)

• 모든 테스트를 실행한다.
• 중복을 없앤다.
• 프로그래머 의도를 표현한다.
• 클래스와 메서드 수를 최소로 줄인다.

단순한 설계 규칙 1: 모든 테스트를 실행하라

설계는의도한 대로 돌아가는 시스템을 내놓아야 한다. 문서로는 시스템을 완벽하게 설계했지만, 시스템이 의도한 대로 돌아가는지 검증할 간단한 방법이 없다면, 문서 작ㄱ성을 위해 투자한 노력에 대한 가치는 인정받기 힘들다.

테스트를 철저히 거쳐 모든 테스트 케이스를 항상 통과하는 시스템은 ‘테스트 가능한 시스템’이다. 당연하지만 중요한 말이다. 테스트가 불가능한 시스템은 검증도 불가능하다. 논란의 여지가 있지만, 검증이 불가능한 시스템은 절대 출시하면 안 된다.

테스트가 가능한 시스템을 만들려고 애쓰면 설계 품질이 더불어 높아진다. 크기가 작고 목적 하나만 수행하는 클래스가 나온다. (SRP를 준수하는 클래스는 테스트가 훨씬 더 쉽다)

테스트 케이스가 많을 수록 개발자는 테스트가 쉽게 코드를 작성한다. 따라서 철저한 테스트 가능한 시스템을 만들면 더 나은 설계가 얻어진다.

결합도가 높으면 테스트 케이스를 작성하기 어렵다. 테스트 케이스를 많이 작성할수록 개발자는 DIP와 같은 원칙을 적용하고 의존성 주입(Dependency Injection), 인터페이스, 추상화 등과 같은 도구를 사용해 결합도를 낮춘다. 따라서 설계 품질은 더 높아진다.

단순한 설계 규칙 2~4: 리팩터링

테스트 케이스를 모ㅓ두 작성했다면 이제 코드와 클래스를 정리해도 괜찮다. 구체적으로는 코드를 점진적으로 리팩토링 해나간다. 코드 몇 줄을 추가할 때마다 잠시 멎추고 설계를 조감한다. 새로 추가하는 코드가 설계 품질을 낮추는가? 그러다면 깔끔히 정리한 후 테스트 케이스를 돌려 기존 기능을 깨뜨리지 않았다는 사실을 확인한다. 코드를 정리하면서 시스템이 깨질까 걱정할 필요가 없다. 테스트 케이스가 있으니까!

응집도를 높이고, 결합도를 낮추고, 관심사를 분리하고, 시스템 관심사를 모듈로 나누고, 함수와 클래스 크기를 줄이고, 더 나은 이름을 선택하는 다양한 기법들이 동원한다.

또한 이 단계는 단순한 설계 규칙 중 나머지 3개를 적용해 중복을 제거하고, 프로그래머 의도를 표현하고, 클래스와 메서드 수를 최소로 줄이는 단게이기도 하다.

중복을 없애라

우수한 설계에서 중복은 커다란 적이다. 중복은 추가 작업, 추가 위험, 불필요한 복잡도를 뜻하기 때문이다. 같은 코드는 당연히 중복이다. 비슷한 코드는 더 비슷하게 고쳐주면 리팩터링이 쉬워진다. 깔끔한 시스템을 만들려면 단 몇 줄이라도 중복을 제거하겠다는 의지가 필요하다.

표현하라

자신이 이해하는 코드를 짜기는 쉽다. 코드를 짜는 동안에는 문제에 푹 빠져 코드를 구석구석 이해하니까. 하지만 나중에 코드를 유지보수할 사람이 코드를 짜는 사람만큼이나 문제를 깊이 이해할 가능성은 희박하다.

소프트웨어 프로젝트 비용 중 대다수는 장기적인 유지보수에 들어간다. 시스템이 점차 복잡해지면서 유지보수 개발자가 시스템을 이해하느라 보내는 시간은 점점 늘어나고 동시에 코드를 오해할 가능성도 점점 커진다. 그러므로 코드는 개발자의 의도를 분명히 표현해야 한다.

개발자가 코드를 명백하게 짤수록 다른 사람이 그 코드를 이해하기 쉬워진다. 그래야 결함이 줄어들고 유지보수 비용이 적게 든다.

1. 좋은 이름을 선택한다. 이름과 기능이 완전히 딴판인 클래스나 함수로 개발자를 놀라게 해서는 안 된다.
2. 함수와 클래스 크기를 가능한 한 줄인다. 작은 클래스와 작은 함수는 이름 짓기도 쉽고, 구현하기도 쉽고, 이해하기도 쉽다.
3. 표준 명칭을 사용한다. 예를 들어, 디자인 패턴은 의사소통과 표현력 강화가 주요 목적이다.
4. 단위 테스트 케이스를 꼼꼼히 작성한다.

하지만 표현력을 높이는 가장 중요한 방법은 노력이다. 나중에 읽을 사람을 고려해 조금이라도 읽기 쉽게 만드려는 충분한 고민은 거의 찾기 어렵다. 하지만 나중에 코드를 읽을 사람은 바로 자신일 가능성이 높다는 사실을 명심하자.

그러므로 자신의 작품을 조금 더 자랑하자. 함수와 클래스에 조금 더 시간을 투자하자. 더 나은 이름을 선택하고, 큰 함수를 작은 함수 여럿으로 나누고, 자신의 작품에 조금만 더 주의를 기울이자. 주의는 대단한 재능이다.

클래스와 메서드 수를 최소로 줄여라

중복을 제거하고, 의도를 표현하고, SRP를 준수한다는 기본적인 개념도 극단으로 치달으면 득보다 실이 많아진다.

클래스와 메서드 크기를 줄이자고 조그만 클래스와 메서드를 수없이 만드는 사례도 없지 않다. 그래서 이 규칙은 함수와 클래스 수를 가능한 줄이라고 제안한다.

때로는 무의미하고 독단적인 정책 탓에 클래스 수와 메서드 수가 늘어나기도 한다.

• 클래스마다 무조건 인터페이스를 생성하라고 요구하는 구현 표준
• 자료 클래스(자료구조)와 동작 클래스(객체)는 무조건 분리해야 한다고 주장하는 개발자
• 가능한 독단적인 견해는 멀리하고 실용적인 방식을 택해야 한다.

목표는 함수와 클래스 크기를 작게 유지하면서 동시에 시스템 크기도 작게 유지하는 데 있다. 하지만 이 규칙은 간단한 설계 규칙 네 개 중 우선순위가 가장 낮다. 다시 말해, 클래스와 함수 수를 줄이는 작업도 중요하지만 그보다 테스트 케이스를 만들고 중복을 제거하고 의도를 표현하는 작업이 더 중요하다는 뜻이다.

결론

경험을 대신할 단순한 개발 기법이 있을까? 당연히 없다. 하지만 이 장, 아니 이 책에서 소개하는 기법은 저자들이 수십 년 동안 쌓은 경험의 정수다. 단순한 설계 규칙을 따른다면 (오랜 경험 후에야 익힐) 우수한 기법과 원칙을 단번에 활용할 수 있다.

클린코드 11장 시스템

 “복잡성은 죽음이다. 개발자에게서 생기를 앗아가며, 제품을 계획하고 제작하고 테스트하기 어렵게 만든다.” -레이 오지, 마이크로소프트 최고 기술 책임자

도시를 세운다면?

새로운 도시를 세우거나 이미 세워진 도시일 때 한 사람의 힘으로 관리하는 것은 무리다.

그럼에도 불구하고 도시는 잘 돌아간다. → 수도관리팀, 전력관리팀, 교통관리팀 등 각 분야를 관리하는 팀이 있기 때문이다. 도시에는 큰 그림을 그리는 사람들도 있으며 작은 사항에 집중하는 사람도 있다.

도시가 돌아가는 또 다른 이유는 적절한 추상화 모듈화 때문이다. 큰 그림을 이해하지 못해도 개인과 개인이 관리하는 구성요소는 효율적으로 돌아간다.

소프트웨어도 도시처럼 구성한다. 그런데 막상 팀이 제작하는 시스템은 비슷한 수준으로 관리를 분리하거나 추상화를 이뤄내지 못한다. 깨끗한 코드를 구현하면 낮은 추상화 수준에서 관심사를 분리하기 쉬워진다.

시스템 제작과 시스템 사용을 분리하라

“제작” 은 “사용” 과 아주 다르다.

소프트웨어 시스템은 (애플리케이션 객체를 제작하고 의존성을 서로 연결하는) 준비 과정과 (준비 과정 이후에 이어지는) 런타임 로직을 분리해야 한다.

“관심사 분리” 는 우리 분야에서 가장 오래되고 가장 중요한 설계 기법 중 하나다. 하지만 불행히도 대다수 애플리케이션은 시작 단계라는 관심사를 분리하지 않는다. 준비 과정 코드를 주먹구구식으로 구현할 뿐만 아니라 런타임 로직과 마구 두섞는다.

아래 코드가 전형적인 예다

public Service getService() {
	if (service == null) {
		service = new MyServiceImpl(); // 모든 상황에 적합한 기본값일까?
	}
	return service;
}

위 코드의 장점은, 객체가 실제로 필요할 때까지 객체를 생성하지 않으므로 불필요한 부하가 걸리지 않는다. 어떤 경우에도 null 을 반환하지 않는다.

하지만 getService 메서드가 MyServiceImpl 과 생성자 인수에 명시적으로 의존한다. 런타임 로직에서 MyServiceImpl 런타임 로직에서 MyServiceImpl 객체를 전혀 사용하지 않더라도 의존성을 해결하지 않으면 컴파일이 안 된다.

테스트도 문제다. MyServiceImpl 이 무거운 객체라면 단위 테스트에서 getService 메서드를 호출하기 전에 적절한 전용 객체를 service 필드에 할당해야 한다. 또한 일반 런타임 로직에 객체 생성 로직을 섞어놓은 탓에 모든 실행 경로도 테스트해야 한다.

무엇보다 MyServiceImpl 이 모든 상황에 적합한 객체인지는 모른다는 사실이다. (주석도 그렇게 달려 있다)

초기화 지연 기법을 한 번 정도 사용한다면 별로 심각한 문제는 아니다. 하지만 많은 애플리케이션이 이처럼 좀스러운 설정 기겁을 수시로 사용한다. 그래서 전반적인 설정 방식이 애플리케이션 곳곳에 흩어져 있다. 모듈성은 저조하며 대개 중복이 심하다.

Main 분리

시스템 생성과 시스템 사용을 분리하는 한 가지 방법으로, 생성과 관련한 코드는 모두 main 이나 main 이 호출하는 모듈로 옮기고, 나머지 시스템은 모든 객체가 생성되었고 모든 의존성이 연결되었다고 가정한다.

제어 흐름은 따라가기 쉽다. main 함수에서 시스템에 필요한 객체를 생성한 후 이를 애플리케이션에 넘긴다. 애플리케이션은 그저 객체를 사용할 뿐이다.

애플리케이션은 main 이나 객체가 생성되는 과정을 전혀 모른다. 단지 모든 객체가 적절히 생성되었다고 가정한다.

팩토리

때로는 객체가 생성되는 시점을 애플리케이션이 결정할 필요도 생긴다. 예를 들어 , 주문 처리 시스템에서 애플리케이션은 LineItem 인스턴스를 생성해 Order 에 추가한다. 이 때 ABSTRACT FACTORY 패턴 을 사용한다. 그러면 LineItem 을 생성하는 시점은 애플리케이션이 결정하지만 LineItem 을 생성하는 코드는 애플리케이션이 모른다.

의존성 주입

사용과 제작을 분리하는 강력한 메커니즘 하나가 의존성 주입이다. 의존성 주입은 제어 역전 기법을 의존성 관리에 적용한 메커니즘이다. 제어 역전에서는 한 객체가 맡은 보조 책임을 새로운 객체에게 전적으로 떠넘긴다. 새로운 객체는 넘겨 받은 책임만 맡으므로 단일 책임 원칙을 지키게 된다. 의존성 관리 맥락에서 객체는 의존성 자체를 인스턴스로 만드는 책임은 지지지 않는다. 대신 이런 책임을 다른 전담 메커니즘에 넘겨야 한다. 그렇게 함으로써 제어를 역전한다. 초기 설정은 시스템 전체에서 필요하므로 대개 책임질 메커니즘으로 main 루틴이나 특수 컨테이너를 사용한다.

클래스가 의존성을 해결하려 시도하지 않는다. 클래스는 완전히 수동적이다. 대신 의존성을 주입하는 방법으로 설정자 메서드나 생성자 인수를 제공한다. DI 컨테이너는 필요한 객체의 인스턴스를 만든 후 생성자 인수나 설정자 메서드를 사용해 의존성을 설정한다. 실제로 생성되는 객체 유형은 설정 파일에 지정하거나 특수 생성 모듈에서 코드를 명시한다.

스프링 프레임워크는 가장 널리 알려진 자바 DI 컨테이너를 제공한다.

초기화 지연으로 얻는 장점을 포기 해야하는 걸까? 이 기법은 DI를 사용하더라도 때론 여전히 유용하다. 먼저 대다수 DI 컨테이너는 필요할 때까지 객체를 생성하지 않고, 대부분은 계산 지연이나 비슷한 최적화에 쓸 수 있도록 팩토리를 호출하거나 프록시를 생성하는 방법을 제공한다. 즉, 계산 기법이나 이와 유사한 최적화 기법에서 이런 메커니즘을 사용할 수 있다.

확장

군락은 마을로, 마을은 도시로 성장한다. 처음에는 좁거나 사실상 없던 길이 포장되며 넓어지고 작은 건물과 공터는 큰 건물로 채워진다. 처음에는 없던 서비스도 나중에는 생겨난다.

그렇지만 성장에는 고통이 따른다. 확장 공사로 꽉 막힌 도로에서 왜 처음부터 넓게 만들지 않았는지라는 의문을 갖는다. 하지만 처음부터 넓은 도로로 만들면 비용을 정당화 할 수 없다.

처음부터 올바른 시스템을 만들 수 있다는 믿음은 미신이다. 대신 우리는 오늘 주어진 사용자 스토리에 맞춰 시스템을 구현해야 한다. 내일은 새로운 스토리에 맞춰 시스템을 조정하고 확장하면 된다. 이것이 반복적이고 점진적인 애자일 방식의 핵심이다. 테스트 주도 개발, 리팩터링, 깨끗한 코드는 코드 수준에서 시스템을 조정하고 확장히 쉽게 만든다.

하지만 시스템 수준에서는 어떨까? 시스템 아키텍처는 사전 계획이 필요하지 않을까? 단순한 아키텍처를 복잡한 아키텍처로 조금씩 키울 수 없다는 현실은 정확하다. 맞는 말 아닌가?

소프트웨어 시스템은 물리적인 시스템과 다르다. 관심사를 적절히 분리해 관리한다면 소프트웨어 아키텍처는 점진적으로 발전할 수 있다.

소프트웨어 시스템은 “수명이 짧다” 는 본질로 인해 아키테[ㄱ처의 점진적인 발전이 가능하다.

횡단(cross-cutting) 관심사

영속성 같은 관심사는 애플리케이션의 자연스러운 객체 경계를 넘나드는 경향이 있다. 모든 객체가 전반적으로 동일한 방식을 이용하게 만들어야 한다. 예를 들어 특정 DBMS나 독자적인 파일을 사용하고, 테이블과 열은 같은 명명 관계를 따르며, 트랜잭션 의미가 일관적이면 더욱 바람ㅈ기하다.

원론적으로는 모듈화되고 캡슐화된 방식으로 영속성 방식을 구성할 수 있다. 하지만 현실적으로는 영속성 방식을 구현한 코드가 온갖 객체로 흩어진다. 여기서 횡단 관심사라는 용어가 나온다. 영속성 프레임워크 또한 모듈화할 수 있다. 도메인 논리도 모듈화 할 수 있다. 문제는 이 두 영역이 세밀한 단위로 겹친다는 점이다. AOP 는 횡단 관심사에 대처해 모듈성을 확보하는 일반적인 방법론이다.

AOP 에서 관점이라는 모듈 구성 개념은 특정 관심스를 지원하려면 시스템에서 특정 지점들이 동작하는 방식을 일관성있게 바꿔야한다 라고 명시한다.

영속성을 예로 들면 프로그래머는 영속적으로 저장할 객체와 속성을 선언한 후 영속성 책임을 영속성 프레임워크에 위임한다. 그러면 AOP 프레임워크는 대상 코드에 영향을 미치지 않는 상태로 동작 방식을 변경한다.

자바 프록시

단순한 상황에 적합하다. 개별 객체나 클래스에서 메서드 호출을 감싸는 경우가 좋은 예다.

하지만 JDK 에서 제공하는 동적 프록시는 인터페이스만 지원한다. 클래스 프록시를 사용하려면 CCLIB, ASM, Javassist 등과 같은 바이트 코드 처리 라이브러리가 필요하다.

순수 자바 AOP 프레임워크

대부분의 프록시 코드는 판박이라 도구로 자동화 할 수 있다. Spring, JBoss AOP와 등과 같은 여러 자바 프레임워크는 내부적으로 프록시를 사용한다.

스프링은 비지니스 논리를 POJO로 구현한다. POJO는 순수하게 도메인에 초점을 맞춘다. POJO는 엔터프라이즈 프레임워크에 의존하지 않는다. 따라서 테스트가 개념적으로 더 쉽고 간단하다.

프로그래머는 설정 파일이나 API를 활용해 필수적인 구조를 구현한다. 여기에는 영속성, 트랜잭션, 보안, 캐시, 장애조치 등과 같은 횡단 관심사 포함된다.

AspectJ 관점

관심사를 관점으로 분리하는 가장 강력한 도구는 AspectJ 언어다. AspectJ는 언어 차원에서 관점을 모듈화 구성으로 지원하는 자바 언어 확장이다. 새 도구를 사용하고 새 언어 문법과 사용법을 익혀야 한다는 단점이 있다.

스프링 프레임워크는 AspectJ에 미숙한 팀들이 어노테이션 기반 관점을 쉽게 사용하도록 다양한 기능을 제공한다.

테스트 주도 시스템 아키텍처 구축

관점으로 (혹은 유사한 개념으로) 관심사를 분리하는 방식으로 그 위력이 막강하다. 애플리케이션 도메인 논리를 POJO로 작성할 수 있다면, 즉 코드수준에서 아키텍처 관심사를 분리할 수 있다면, 진정한 테스트 주도 아키텍처 구축이 가능해진다.

아주 단순하면서도 멋지게 분리된 아키텍처로 소프트웨어 프로젝트를 진행해 결과물을 재빨리 출시한 후, 기반 구조를 추가하며 조금씩 확장해나가도 괜찮다는 말이다. 그렇다고 아무 방향 없이 프로젝트에 뛰어들어도 좋다는 뜻은 아니다. 프로젝트를 시작할때는 일반적인 범위, 목표, 일정은 물론이고 결과로 내놓을 시스템의 일반적인 구조도 생각해야 한다.

최선의 시스템 구조는 각기 POJO(또는 다른) 객체로 구현되는 모듈화되는 모듈화된 관심사 영역(도메인)으로 구성된다. 이렇게 서로 다른 영역은 해당 영역 코드에 최소한의 영향을 미치는 관점이나 유사한 도구를 사용해 통합한다. 이런 구조 역시 코드와 마찬가지로 테스트 주도 기법을 적용할 수 있다.

의사 결정을 최적화하라

모듈을 나누고 관심사를 분리하면 지엽적인 관리와 결정이 가능해진다. 도시든 소프트웨어 프로젝트든, 아주 큰 시스템에서는 한 사람이 모든 결정을 내리기 어렵다.

가장 적합한 사람에게 책임을 맡기면 가장 좋다. 우리는 때때로 가능한 마지막 순간까지 결정을 미루는 방법이 최선이라는 사실을 까먹곤한다.

게으르거나 무책임해서가 아니라, 최대한 정보를 모아 최선의 결정을 내리기 위해서이다. 성급한 결정은 불충분한 지식으로 내린 결정이다. 너무 일찍 결정하면 고객 피드백을 모으고 프로젝트를 더 고민하고, 구현 방안을 더 탐험할 기회가 사라진다.

관심사를 모듈로 분리한 POJO 시스템은 기민함을 제공한다. 이런 기민함 덕택에 최신 정보에 기반해

최선의 시점에 최적의 결정을 내리기가 쉬워진다. 또한 결정의 복잡성도 줄어든다.

명백한 가치가 있을 때 표준을 현명하게 사용하라

EJB2는 단지 표준이라는 이유만으로 많은 팀이 사용했다. 가볍고 간단한 설계로 충분했을 프로젝트에서도 EJB2를 채택했다. 아주 과장되게 포장된 표준에 집착하는 바람에 고객 가치가 뒷전으로 밀려난 사례도 많이 있다.

표준을 사용하면 아이디어와 컴포넌트를 재사용하기 쉽고, 적절한 경험을 가진 사람을 구하기 쉬우며, 좋은 아이디어를 캡슐화하기 쉽고, 컴포넌트를 엮기 쉽다. 하지만 때로는 표준을 만드는 시간이 너무 오래 걸려 업계가 기다리지 못한다. 어떤 표준은 원래 표준을 제정한 목적을 잊어버리기도 한다.

시스템은 도메인 특화 언어가 필요하다

DSL은 간단한 스크립트 언어나 표준 언어로 구현한 API를 가리킨다. DSL로 짠 코드는 도메인 전문가가 작성한 구조적인 산문처럼 읽힌다. 좋은 DSL은 도메인 개념과 그 개념을 구현한 코드 사이에 존재하는 "의사소통 간극"을 줄여준다.

도메인 특화 언어(Domail-Specific Language)를 사용하면 고차원 정책에서 저차원 세부사항에

이르기까지 모든 추상화 수준과 모든 도메인을 POJO로 표현할 수 있다.

결론

시스템 역시 꺠끗해야 한다. 깨끗하지 못한 아킽텍처는 도메인 논리를 흐리며 기민성을 떨어뜨린다. 도메인 논리가 흐려지면 제품 품질이 떨어진다. 버그가 숨어들기 쉬워지고, 스토리를 구현하기 어려워진다. 기민성이 떨어지면 생상성이 낮아져 TDD가 제공하는 장점이 사라진다.

모든 추숭화 단계에서 의도는 명확히 표현해야 한다. 그러려면 POJO를 작성하고 관점 혹은 관점과 유샇나 메커니즘을 사용해 각 구현 관심사를 분리해야 한다.

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

클린코드 10장 클래스

 

클래스 체계

클래스를 정의하는 표준 자바 관례에 따르면, 가장 먼저 변수 목록이 나온다.

정적, 공개 상수가 있다면 맨 처음에 나온다. 그 다음으로 비공개 변수가 나온다

이어서 비공개 인스턴스 변수가 나온다. 공개 변수가 필요한 경우는 거의 없다.

변수 목록 다음에는 공개 함수가 나온다. 비공개 함수는 자신을 호출하는 공개 함수 직후에 넣는다.

즉, 추상화 단계가 순차적으로 내려간다. 그래서 프로그램은 기사 처럼 읽는다.

public class Samlpe {
	private static final String PREFIX = "SAMPLE";
	public static final String TABLE_NAME = "SAMPLE";
	
	private static boolean locked = false;
	
	private String data;
	public String getData() {
		return this.data;
	}
	public String setData(String data) {
		this.data = data;
	}
	
	public String save() {
		lock();
		// save
		unlock();
	}
	
	private void lock() {
		this.locked = true;
	}
	
	private void unlock() {
		this.locked = false;
	}
}

캡슐화

변수와 유틸리티 함수는 가능한 공개하지 않는 편이 낫지만 반드시 숨겨야한다는 법칙도 없다. 떄로는 변수나 유틸리티 함수를 protected 로 선언해 테스트 코드에 접근을 허용하기도 한다. 같은 패키지 안에서 테스트 코드가 함수를 호출하거나 변수를 사용해야하면 그 함수나 변수 protected 로 선언하거나 패키지 전체로 공개한다.

하지만 캡슐화를 풀어주는 결정은 언제나 최후의 수단이다. 그 전에 다른 방법이 있는지 고민해봐야 한다.

클래스는 작아야 한다!

클래스를 만들 때

첫 번째 규칙은 크기다. 클래스는 작아야 한다. 두 번째 규칙도 크기다. 더 작어여 한다.

클래스를 설계할 때도, 함수와 마찬가지로 작게가 기본 규칙이다.

그렇다면 얼마나 작아야할까?

함수는 물리적인 행수로 크기를 측정했지만, 클래스는 다른 척도를 사용해야 한다. → 클래스가 맡은 책임으로 측정한다.

메서드가 적다고 책임이 적은 것이 아니다.

클래스 이름은 해당 클래스 책임을 기술해야 한다. 실제로 작명은 클래스 크기를 줄이는 첫 번째 관문이다.

간결한 이름이 떠오르지 않는다면 클래스 크기가 너무 커서 그런 것이다.

클래스 이름이 모호하다면 클래스 책임이 너무 많아서다. 예를 들어 클래스 이름에 Processor, Manager, Super 등과 같이 모호한 단어가 있따면 클래스에다 여러 책임을 떠안겼다는 증거다.

또한 클래스 설명은 만일(if), 그리고(and), 하며(or), 하지만(but) 을 사용하지 않고 25단어 내외에로 가능해야 한다.

단일 책임 원칙 (Single Responsibility Principle, SRP)

클래스나 모듈을 변경할 이유가 하나, 단 하나뿐이어야 한다는 원칙이다.

SRP 는 책임이라는 개념을 정의하며 적절한 클래스 크기를 제시한다. 클래스는 책임, 즉 변경할 이유가 하나여아 한다는 의미다.

publuc class SuperDashboard extend JFrame implements MetaDataUser {
	public Component getLastFocusedComponent()
	public void setLastFoucsed(Component lastFocused)
	public int getMajorVersionNumber()
	public int getMinorVersionNumber()
	public int getBuildNumber()
}

위 클래스를 봤을 때 변경할 이유는 두 가지이다.

첫째, SuperDashboard 는 소프트웨어 정보를 추적한다. 그런데 버전 정보는 소프트웨어를 출시할 때마다 달라진다.

둘째, SuperDashboard 는 자바 스윙 컴포넌트를 관리한다. 즉, 스윙 코드를 변경할 때마다 버전 번호가 달라진다.

책임, 즉 변경할 이유를 파악하려 애쓰다 보면 코드를 추상화기 쉬워진다. SuperDashboard 에서 버전 정보를다루는 메서드 세개를 따로 빼내 Version 이라는 독자적인 클래스를 만든다. Version 클래스는 다른 어플리케이션에서 재사용하기 쉬운 구조이다

public class Version {
	public int getMajorVersionNumber()
	public int getMinorVersionNumber()
	public int getBuildNumber()
}

SRP 는 객체 지향 설계에서 더욱 중요한 개념이다. 또한 이해하고 지키기 수월한 개념이기도 하다. 하지만 SRP는 클래스 설계자가 가장 무시하는 규칙 중 하나이다. 우리는 수많은 책임을 떠안은 클래스를 꾸준하게 접한다. 왜일까?

소프트웨어를 동라가게 만드는 활동과 소프트웨어를 깨끗하게 만드는 활동은 완전 별개다. 우리들 대다수는 두뇌 용량에 한계가 있어 깨끗하고 체계적인 소프트웨어 보다는 돌아가는 소프트웨어에 초점을 맞춘다.

문제는 우리들 대다수가 프로그램이 돌아가면 일이 끝났다고 여기는 데 있다. 깨끗하고 체계적인 소프트웨어라는 다음 관심사로 전환하지 않는다.

또, 많은 개발자는 자잘한 단일 책임 클래스가 많아지면 큰 그림을 이해하기 어려워진다고 우려한다. 큰 그림을 이해하려면 이 클래스 저 클래슬르 수없이 넘나들어야 한다 걱정한다.

하지만 클래스가 많은 시스템이든 큰 클래스가 몇 개뿐인 시스템이든 돌아가는 부품은 그 수가 비슷하다.

그러므로 고민할 질문은 다음과 같다. “도구 상자를 어떻게 관리하고 싶은가?”

• 작은 서랍을 많이 두고 기능과 이름이 명확한 컴포넌트로 나눠 넣고 싶은가?
• 아니면 큰 서랍 몇 개를 두고 모두 던져 넣고 싶은가?

큰 클래스 몇 개가 아니라 작은 클래스 여럿으로 나눠진 시스템이 더 바람직하다. 작은 클래스는 각자 맡은 채김이 하나며, 변경할 이유도 하나며, 다른 작은 클래스와 협력해 시스템에 필요한 동작을 수행한다.

응집도

클래스는 인스턴스 변수 수가 작아야한다. 각 클래스 메서드는 클래스 인스턴스 변수를 하나 이상 사용해야 한다.

일반적으로 메서드가 변수를 더 많이 사용할 수록 메서드와 클래스는 응집도가 더 높다. 모든 인스턴스 변수를 메서드마 사용하는 클래스는 응집도가 가장 높다.

일반적으로 이처럼 응집도가 가장 높은 클래스는 가능하지도 바람직하지도 않다. 그렇지만 우리는 응집도가 높은 클래스를 선호한다. 응집도가 높다는 말은 클래스에 속한 메서드와 변수가 서로 의존하며 논리적인 단위로 묶인다는 의미기 때문이다.

public class Stack {
	private int topOfStack = 0;
	List<Integer> elements = new LinkedList<Integer>();
	
	public int size() {
		return topOfStack;
	}
	
	public void push(int element) {
		topOfStack++;
		elements.add(element);
	}
	
	public int pop() throws PoppedWhenEmpty {
		if (topOfStack == 0) {
			throw new PoppedWhenEmpty();
		}
		
		int element = elements.get(--topOfStack);
		elements.remove(topOfStack);
		
		return element;
	}
}

위 클래스는 응집도가 아주 높다. size()를 제외한 다른 두 메서드는 두 변수를 모두 사용한다.

“함수를 작게 매게 변수 목록을 짧게” 라는 전략을 따르다 보면 때때로 몇몇 메서드만이 사용하는 인스턴스 변수가 아주 많아진다. 이는 십줄팔구 새로운 클래스로 쪼개야 한다는 신호다. 응집도가 높아지도록 변수와 메서드를 적절히 분리해 새로운 클래스 두 세개로 쪼개준다.

응집도를 유지하면 작은 클래스 여럿이나온다

큰 함수를 작은 함수 여럿으로 나누기만 해도 클래스 수가 많아진다. 예를 들어, 변수가 아주 많은 큰 함수 하나가 있다. 큰 함수 일부를 작은 함수 하나로 빼내고 싶은데, 빼내려는 코드가 큰 함수에 정의된 변수 넷을 사용한다. 그렇다면 변수 네 개를 새 함수에 인수로 넘겨야 옳을까? → 전혀 아니다. 만약 인스턴스 변수로 넘기면 새 함수는 인수가 전혀 필요 없다. 그 만큼 함수를 쪼개기 쉬워진다. 불행히도 이렇게 하면 클래스가 응집력을 잃는다. 몇몇 함수만 사용하는 인스턴스 변수가 점점 더 늘어나기 때문이다. → 몇몇 함수가 몇몇 변수만 사용한다면 독자적인 클래스로 분리하면 된다.

그래서 큰 함수를 작은 함수 여럿으로 쪼개다 보면 종종 작은 클래스 여럿으로 쪼갤 기회가 생긴다.

리팩토링 코드는 책에서 직접 확인해보면 좋을 것..

• 리팩토링 하고 나면 일단 프로그램이 길어진다.
  • 점 더 길고 서술적인 변수 이름을 사용한다.
  • 코드에 주석을 추가하는 수단으로 함수 선언과 클래스 선언을 활용한다.
  • 가독성을 높이고자 공백을 추가하고 형식을 맞추었다.
• 원래 프로그램은 세 가지 책임으로 나눠져 있었다.
  • PrimePrinter 클래스는 main 함수 하나만 포함하며 실행 환경을 책임진다. → 호출 환경이 바뀌면 고쳐준다
  • RowColumnPagePrinter 클래스는 숫자 목록을 주어진 행과 열에 맞춰 페이지에 출력하는 방법을 안다. → 출력하는 모양새를 바꾸려면 고쳐준다.
  • PrimeGenerator 클래는 소수 목록을 생성하는 방법을 안다. → 소수를 계산하는 알고리즘이 바뀌면 클래스를 고쳐준다.

변경하기 쉬운 클래스

대다수 시스템은 지속적인 변경이 가해진다 .그리고 뭔가 변경할 때마다 시스템이 의도대로 동작하지 않을 위험이 따른다.

깨끗한 시스템은 클래스를 체계적으로 정리해 변경에 수반하는 위험을 낮춘다.

변경으로부터 격리

요구사항은 변하기 마련이다 .따라서 코드도 변하기 마련이다.

상세한 구현에 의존하는 클라이언트 클래스는 구현이 바뀌면 위험에 빠진다. 그래서 우리는 인터페이스와 추상 클래스를 사용해 구현이 미치는 영향을 격리한다.

상세한 구현에 의존하는 코드는 테스트가 어렵다.