이제 한 3주 정도만 더 보면 끝이다!(아마도)

이번주는 클린코드 12장과 13장이다

12장 창발성

창발성이 뭐지

하위 계층에는 존재하지 않던 특성이 상위 계층에서 자발적으로 나타나는 현상

이거라고 한다

• 단순한 설계 규칙 1: 모든 테스트를 실행하라
  • 철저한 테스트가 가능한 시스템을 만들면 더 나은 설계가 얻어진다
  • 결합도가 높으면 테스트 케이스를 작성하기 어렵다
  • 낮은 결합도와 높은 응집력이라는 객체 지향 방법론이 지향하는 목표를 저절로 달성한다

스터디봇 만드는거 테스트는 귀찮아서 생략했는데 만들어볼까 고민된다...

• 단순한 설계 규칙 2: 중복을 없애라

  • 소규모 재사용은 시스템 복잡도를 극적으로 줄여준다
  • 하위 클래스는 중복되지 않는 정보만 제공해 빠진 구멍을 메운다

• 단순한 설계 규칙 3: 표현하라

  • 좋은 이름을 선택한다
  • 함수와 클래스 크기를 가능한 줄인다
  • 표준 명칭을 사용한다
  • 단위 테스트 케이스를 꼼꼼히 작성한다

• 단순한 설계 규칙 4: 클래스와 메서드 수를 최소로 줄여라

  • 함수와 클래스 크기를 작게 유지하면서 동시에 시스템 크기도 작게 유지한다
  • 근데 규칙 중 우선순위가 가장 낮다

    이 규칙이 제일 어려운 것 같다. 1,2,3번 규칙을 만족하면서 메서드와 클래스 줄이기... 필요한 클래스와 메서드만 만들라는 뜻인것 같다

13장 동시성

동시성과 깔끔한 코드는 양립하기 어렵다. 이 장에서는 여러 스레드를 동시에 돌리는 이유를 논한다.

• 동시성이 필요한 이유?

  • 동시성은 결합을 없애는 전략이다
  • 무엇과 언제를 분리하면 애플리케이션 구조와 효율이 극적으로 나아진다

• 동시성과 관련한 일반적인 미신과 오해

  • 동시성은 항상 성능을 높여준다
    • 동시성은 때로 성능을 높여준다. 대기시간이 아주 길어 여러 스레드가 프로세서를 공유할 수 있거나, 여러 프로세서가 동시에 처리할 독릭접인 계산이 충분히 많은 경우에만 성능이 높아진다
  • 동시성을 구현해도 설계는 변하지 않는다
    • 단일 스레드 시스템과 다중 스레드 시스템은 설계가 판이하게 다르다
  • 웹 또는 EJB 컨테이너를 사용하면 동시성을 이해할 필요가 없다
    • 실제로는 컨테이너가 어떻게 동작하는지, 어떻게 동시 수정, 데드락 등과 같은 문제를 피할 수 있는지를 알아야만 한다.

• 동시성과 관련된 타당한 생각

  • 동시성은 다소 부하를 유발한다.
  • 동시성은 복잡하다
  • 일반적으로 동시성 버그는 재현하기 어렵다
  • 동시성을 구현하려면 흔히 근본적인 설계 전략을 재고해야 한다

이메일 대량 전송 기능을 구현할 때 Spring Batch 에서 이메일을 중복으로 보내는 버그가 발생했는데 재현이 어려웠던 경험이 있다

• 동시성 방어 원칙

  • 단일 책임 원칙
    • 동시성 관련 코드는 다른 코드와 분리해야 한다
    • 고려할 점
      • 동시성 코드는 독자적인 개발, 변경, 조율 주기가 있다
      • 동시성 코드에는 독자적인 난관이 있다
      • 잘못 구현한 동시성 코드는 별의별 방식으로 실패한다.
    • 권장사항
      • 동시성 코드는 다른 코드와 분리하라 → 어떻게 분리하지...

• 따름 정리

  • 자료 범위를 제한하라
    • 코드 내 임계영역을 synchronized 키워드로 보호하라고 권장
    • 자료를 캡슐화하라. 공유 자료를 최대한 줄여라
  • 자료 사본을 사용하라
    • 객체를 복사해 읽기 전용으로 사용 또는 각 스레드가 객체를 복사해 사용한 후 한 스레드가 해당 사본에서 결과를 가져옴
    • 공유 객체 피하기
  • 스레드는 가능한 독립적으로 구현하라
    • 다른 스레드와 자료 공유 X
    • 독자적인 스레들, 가능하면 다른 프로세서에서, 돌려도 괜찮도록 자료를 독립적인 단위로 분할

• 라이브러리를 이해하라

  • 언어가 제공하는 클래스를 검토하라

• 실행 모델을 이해하라

  • 생산자-소비자
    • 하나 이상 생산자 스레드가 정보를 생성해 버퍼나 대기열에 넣음
    • 하나 이상 소비자 스레드가 대기열에서 정보를 가져와 사용
  • 읽기-쓰기
    • 읽기 스레드와 쓰기 스레드로 분리
    • 읽기 스레드의 요구와 쓰기 스레드의 요구를 적절히 만족시켜 처리율도 적당히 높이고 기아도 방지하는 해법 필요
  • 식사하는 철학자들
    • 이건 봐도 모르겠네
    • 여러 프로세스가 자원을 얻으려 경쟁하는 현상인것 같다
    • 데드락, 라이브락, 처리율 저하, 효율성 저하 등을 겪음

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

  • 공유 객체 하나에는 메서드 하나만 사용하라
  • 공유 객체 하나에 여러 메서드가 필요한 상황이 생기면?
    • 클라이언트에서 잠금: 클라이언트에서 첫 번째 메서드를 호출하기 전에 서버를 잠금 → 마지막 메서드를 호출할 때까지 잠금 유지
    • 서버에서 잠금: 서버에다 서버를 잠그고 모든 메서드를 호출한 후 잠금을 해제하는 메서드 구현 → 클라이언트에서 이 메서드 호출
    • 연결 서버: 잠금을 수행하는 중간 단계 생성 → 원래 서버 변경 X

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

  • 여기저기서 synchronized 문을 남발하면 안됨
  • 임계영역은 반드시 보호해야 함 → 임계영역 수를 최대한 줄임
  • 수를 줄인다고 거대한 임계영역 하나로 구현하면 성능 떨어짐.

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

  • 깔끔하게 종료하는 다중 스레드 코드를 짜야 한다면 시간을 투자해 올바로 구현해라
  • 권장사항: 종료 코드를 개발 초기부터 고민하고 동작하게 초기부터 구현하라. 생각보다 어려우므로 이미 나온 알고리즘 검토

• 스레드 코드 테스트하기

  • 권장사항: 문제를 노출하는 테스트 케이스를 작성하라. 테슾트가 실패하면 원인을 추적하라. 다시 돌렸더니 통과하더라는 이유로 그냥 넘어가면 절대 안된다!!!
  • 고려 사항
    • 말이 안되는 실패는 잠정적인 스레드 문제로 취급
      • 시스템 실패를 일회성이라 치부하지 마라
    • 다중 스레드를 고려하지 않은 순차 코드부터 제대로 돌게 만들기
      • 스레드 환경 밖에서 생기는 버그와 스레드 환경에서 생기는 버그를 동시에 디버깅하지 마라.
    • 다중 스레드를 쓰는 코드 부분을 다양한 환경에 쉽게 끼워 넣을 수 있도록 스레드 코드 구현
      • 다양한 설정에서 실행할 목적으로 다른 환경에 쉽게 끼워 넣을 수 있게 코드 구현
    • 다중 스레드를 쓰는 코드 부분을 상황에 맞춰 조정할 수 있게 작성
    • 프로세서 수보다 많은 스레드를 돌려보라
    • 다른 플랫폼에서 돌려보라
      • 처음부터 그리고 자주 모든 목표 플랫폼에서 코드를 돌려라
    • 코드에 보조 코드를 넣어 돌려라. 강제로 실패를 일으키게 해보라
      • 흔들기 기법을 사용해 오류를 찾아내라

클린코드를 보면 볼수록 테스트 코드의 중요성을 알게 되는 것 같다... 지금까지는 기능을 구현하는데에만 집중했는데 테스트 코드를 통해 검증을 하는 습관을 제대로 들여야 할 것 같다.