20220316_북이

🪴ㅤTIL (DAY - 12)

2022.03.16

오늘 읽은 범위

👉ㅤ클린코드 12, 13장. 창발성, 동시성

기억하고 싶은 내용ㅤ📕

켄트 벡이 제시간 단순한 설계 (p.216)

• 모든 테스트를 실행한다.
  • 무엇보다 먼저, 설계는 의도한 대로 돌아가는 시스템을 내놓아야 한다. (p.216)
  • 놀랍게도 "테스트 케이스를 만들고 계속 돌려라"라는 간단하고 단순한 규칙을 따르면
    시스템은 낮은 결합도와 높은 응집력이라는, 객체 지향 방법론이 지향하는 목표를 저절로
    달성한다. 즉, 테스트 케이스를 작성하면 설계 품질이 높아진다. (p.217)
  • 코드를 정리하면서 시스템이 깨질까 걱정할 필요가 없다. 테스트 케이스가 있으니까! (p.217)
• 중복을 없앤다.
  • 우수한 설계에서 중복은 커다란 적이다. 중복은 추가 작업, 추가 위험, 불필요한 복잡도를
    뜻하기 때문이다. (p.217)
  • '소규모 재사용'은 시스템 복잡도를 극적으로 줄여준다. 소규모 재사용을 제대로 익혀야
    대규모 재사용이 가능하다. (p.219)
• 프로그래머의 의도를 표현한다.
  • 코드는 개발자의 의도를 분명히 표현해야 한다. 개발자가 코드를 명백하게 짤수록 다른 사람이
    그 코드를 이해하기 쉬워진다. 그래야 결함이 줄어들고 유지보수 비용이 적게 든다. (p.221)
    1. 좋은 이름을 선택한다.
    2. 함수와 클래스 크기를 가능한 줄인다.
    3. 표준 명칭을 사용한다.
    4. 단위 테스트 케이스를 꼼꼼히 작성한다.
  • 자신의 작품을 조금 더 자랑하자. 함수와 클래스에 조금 더 시간을 투자하자. 더 나은 이름을
    선택하고, 큰 함수를 작은 함수 여럿으로 나누고, 자신의 작품에 조금만 더 주의를 기울이자.
    주의는 대단한 재능이다. (p.222)
• 글래스와 매서드 수를 최소로 줄인다
  • 목표는 함수와 클래스 크기를 작게 유지하면서 동시에 시스템 크기도 작게 유지하는 데 있다. (p.222)

동시성에 관련된 글 정리 (p.228)

동시성 방어 원칙 (p.230)

지금부터 동시성 코드가 일으키는 문제로부터 시스템을 방어하는 원칙과 기술을 소개한다.

• 단일 책임 원칙(Single Responsibility Principle, SRP)
  SRP는 주어진 메서드/클래스/컴포넌트를 변경할 이유가 하나여야 한다는 원칙이다.
  권장사항: 동시성 코드는 다른 코드와 분리하라. (p.230)
• 따름 정리(corollary):자료 범위를 제한하라.
  • 따름 정리: 자료 사본을 사용하라
  • 따름 정리: 스레드는 가능한 독립적으로 구현하라
  권장사항: 자료를 캡슐화(encapsulation)하라. 공유 자료를 최대한 줄여라. (p.231)
  권장사항: 독자적인 스레드로, 가능하면 다른 프로세서에서, 돌려도 괜찮도록 자료를
  독립적인 단위로 분할하라. (p.232)
• 라이브러리를 이해하라
  권장사항: 언어가 제공하는 클래스를 검토하라. (p.233)
• 실행 모델을 이해하라
  권장사항: 위에서 설명한 기본 알고리즘과 각 해법을 이해하라. (p.235)
• 동기화하는 메서드 사이에 존재하는 의존성을 이해하라.
  권장사항: 공유 객체 하나에는 메서드 하나만 사용하라. (p.235)
• 동기화하는 부분을 작게 만들어라.
  권장사항: 동기화 하는 부분을 최대한 작게 만들어라. (p.236)
• 올바른 종료 코드는 구현하기 어렵다.
  권장사항: 종료 코드를 개발 초기부터 고민하고 동작하게 초기부터 구현하라. 생각보다 오래 걸린다.
  생각보다 어려우므로 이미 나온 알고리즘을 검토하라. (p.237)
• 스레드 코드 테스트 하기.
  권장사항: 문제를 노출하는 테스트 케이스를 작성하라. 프로그램 설정과 시스템 설정과 부하를
  바꿔가며 자주 돌려라. 테스트가 실패하면 원인을 추적하라. 다시 돌렸더니 통과하더라는 이유로 그냥
  넘어가면 절대로 안 된다. (p.237)
• 말이 안되는 실패는 잠정적인 스레드 문제로 취급하라.
  권장사항: 시스템 실패를 '일회성'이라 치부하지 마라 (p.238)
• 다중 스레드를 고려하지 않은 순차 코드부터 제대로 돌게 만들자.
  권장사항: 스레드 환경 밖에서 생기는 버그와 스레드 환경에서 생기는 버그를 동시에
  디버깅 하지마라. 먼저 스레드 환경 밖에서 코드를 올바로 돌려라 (p.238)
• 다중 스레드를 쓰는 코드 부분을 다양한 환경에서 쉽게 끼워 넣을 수 있게 스레드 코드를 구현하라
  권장사항: 다양한 설정에서 실행할 목적으로 다련 환경에 쉽게 끼워 넣을 수 있게
  코드를 구현하라. (p.239)
• 다중 스레드를 쓰는 코드 부분을 상황에 맞게 조율할 수 있게 작성하라.
• 프로세서 수보다 많은 스레드를 돌려보라.
• 다른 플랫폼에서 돌려보라.
  권장사항: 처음부터 그리고 자주 모든 목표 플랫폼에서 코드를 돌려라. (p.240)
• 코드에 보조 코드(instrument)를 넣어 돌려라. 강제로 실패를 일으키게 해보라.
• 직접 구현해보기
• 자동화
  권장사항: 흔들기 기법을 사용해 오류를 찾아내라 (p.243)

다중 스레드 코드는 올바로 구현하기 어렵다. 간단했던 코드가 여러 스레드와 공유 자료를 추가하면서
악몽으로 변한다. 다중 스레드 코드를 작성한다면 각별히 깨끗하게 코드를 짜야 한다. 주의하지 않으면
희귀하고 오묘한 오류에 직면하게 된다. (p.243)

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

오늘 읽은 소감ㅤ📙

오늘 읽은 파트도 역시 이해하기가 매우 어려웠다.
일단 스레드(thread)라는 단어를 처음 접하게 되어서 특히나 '동시성'파트는 거의
"이런 것도 있구나"정도만 알고 넘기게 되었다.
스레드(thread) : 어떠한 프로그램내에서, 특히, 프로세스 내에서 실행되는 흐름의 단위
🗣 일반적으로 하나의 프로그램당 하나의 스레드를 가집니다
최대한 간추려서 중요한 부분을 적으려 했으나, 실패했다.
내 눈엔 죄다 중요해 보였기 때문이다....
역시나 나는 아직까진 독후감 스킬도 부족하고 IT계열 지식도 부족한 것 같다.
슬 프 다 !

명언 혹은 궁금하거나 이해가 잘 가지 않는 내용ㅤ📘

🦖ㅤ동시성이 필요한 이유 ?
👉ㅤ동시성은 결합(coupling)을 없애는 전략이다. 즉 무엇(what)과 언제(when)를 분리하는 전략이다
👉ㅤ무엇과 언제를 분리하면 애플리케이션 구조와 효율이 극적으로 나아진다. 구조적인 관점에서
ㅤ프로그램은 거대한 루프 하나가 아니라 작은 협력 프로그램 여럿으로 보인다. 따라서 시스템을 이해하기가
ㅤ쉽고 문제를 분리하기도 쉽다.