Clean Code 12장 - 13장

2019-04-18

12장 창발성

12장 제목을 보고 든 생각은 ‘하 이젠 장 제목부터 발목잡히냐…’ 였다. 이 장은 짧기도 하고 내용이 쉽게 읽히긴 했으나, ‘창발성’이 뭔 뜻인지 몰라서 찾아봤다.

창발성?

창발성 [Emergent Properties , 創發性]의 사전적인 의미는 아래와 같다.

창발성이란 창발된 성질이나 실체와 같은 대상들이 더 근본적인 대상들로부터 발생하지만, 근본적인 대상으로 환원되지 않으며 그 자체로 특수한 지위를 차지하는 것을 의미한다. 하위 체계로부터 생겨나지만, 그 하위 체계로 환원되지 않는 속성을 말한다.

음… 무슨 뜻인지 와 닿지 않는다. 창발적 설계라는 단어가 첫 부분에 나오는데 도저히 무슨뜻인지 모르겠고, 이리저리 찾다가 아래의 글을 찾았다.

창발성의 정의에 대해서는 여러 의견이 있지만 이 단어는 갑작스럽게 솟아나는 특성이라는 뜻으로 영어로는 주로 emergent property로 표현된다. 창발성의 정의에는 주로 두 가지 의미가 포함되는데 하나는 단어 그대로 갑작스러운 등장을 의미하며, 또 다른 하나는 이 과정에서 여러 요소들이 재조합되면서 만들어진 새로운 그 무엇은 본래 요소들의 합보다 더 크다는 것을 의미한다.

아마 이 책에서 말하는 창발성은 여러 요소들이 재조합되면서 만들어진 새로운 그 무엇은 본래 요소들의 합보다 더 크다는 것을 의미한다. 이것인듯 싶다.

켄트백이 제시한 단순한 설계 규칙 네 가지

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

가능한 독단적인 견해는 멀리하고 실용적인 방식을 택해야 한다. 그러니까 4번 항목이 중요한 것은 사실이나, 테스트 케이스를 만들고 중복을 제거하고 의도를 표현하는 작업이 더 중요하다.

12장에서 제일 어려웠던것은 장 제목이었다(…) 12장 내용 자체는 쉽게 이해하고 받아들였으나 실천하기가 힘든것들인듯.

13장 동시성

동시성 관련 코드를 테스트 하려고 애써본적이 없어서 그런지 이번 장은 내내 읽으면서 “아…맞어…음…그래…그렇지…응…” 이었다. 받아들이는데 별 문제도 없었고 걸리는것도 없었는데 뭘 모르는지를 몰라서 그런지 몇 번을 읽어도 저 상태길래 따로 체크해뒀다.

아마 이 파트가 아예 이해가 안갔다면 아래 항목을 찾아 보는 것을 추천한다.

  • Process vs Thread
  • 선점(Non-Preemptive) vs 비선점(Preemptive)
  • 동시성(Concurrency) vs 병렬처리(Parallelism)
  • Non-blocking vs Asynchronous
  • Java에서 HashTable vs HashMap vs ConcurrentHashMap

p. 232 라이브러리를 이해하라

부끄럽게도 Java Executor 프레임워크를 써 본적이 없다. 딱 예전에 Java 배웠을 때 Thread, Runnable 배워서 멀티스레드 짜본게 전부다.

Executor 인터페이스 내부에는 void execute(Runnable command) 하나만 있다.

Executor는 Task를 만드는 것과 실행하는 것을 분리하는 표준적인 방법이며, p.234의 Producer-Consumer 패턴에 기반하고 있다.

Java에서 멀티스레드를 처리하기 위한 도구로는 Executor 뿐만이 아니라 여러가지가 있다. Thread, Executor, ForkJoinPoll, Reactor, CompletableFuture...가 있는데, 각 도구들이 어떤 한계와 장점이 있는지는 좀 더 찾아보고 추후에 포스팅을 해야겠다. 이 포스팅에 이어쓰기엔 너무 긴듯.

p. 233 실행 모델을 이해하라

표 항목에 데드락(DeadLock)과 라이브락(LiveLock)이 구분되어있다. 라이브락 자체를 들어보기만 한거라 찾아봤다.

라이브락은 두 스레드가 락의 해제와 획득을 무한 반복하는 상태이다. 라이브락은 데드락을 피하려는 의도에서 수정한 코드가 불완전할 때 발생하곤 한다.

Java 개발하면서 이 둘을 크게 구분할 일이 없었다는 말을 듣고, 차이만 좀 찾아보고 넘어갔다.

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

Java 스레드 동기화 모델은 내부적으로 모니터를 써서 Lock을 관리한다. 그래서 Low하게 Lock을 다룰 일은 거의 없다고 한다.

모니터가 어떻게 쓰여지는지 좀 찾아보는데, 세마포어와 뮤텍스랑 같이 묶여서 헷갈린다. 비슷하지만 좀 다른것 같은데 확실히 이해는 못했다. 이것 역시 뒤에 차이를 좀 짚고 넘어가봐야겠다.

p.240 하단 주석 18번

이 주석에 적힌건 ‘자바 스레드 모델은 선점형(preemptive) 스레드 스케줄링을 보장하지 않는다는 사실을 아는가?’지만, 정확히 말하면 자바 그 자체 보단 JVM이 그러하다.

그러니까 JVM은 선점형 스케줄링을 100% 보장하지 않는다가 좀 더 맞는 표현일 것이다. 여기까지만 알고 있었는데 왜인지 알고싶어서 더 찾아보니 잘 안보인다. 잠오니까 일단 여기서 정리 마무리..

참고자료