[전호영] 11장, 12장, 13장: 시스템 외 2장

11장/전호영.md

@@ -0,0 +1,9 @@
+# 다시 볼 문장들
+- 시작 단계는 모든 애플리케이션이 풀어야 할 관심사다. 이것이 이 장에서 우리가 맨 처음 살펴볼 관심사다. 관심사 분리는 우리 분야에서 가장 오래되고 가장 중요한 설계 기번 중 하나다.
+- 대다수 DI 컨테이너는 필요할 때까지는 객체를 생성하지 않고, 대부분 계산 지연이나 비슷한 최적화에 쓸 수 있도록 팩토리를 호출하거나 프록시를 생성하는 방법을 제공한다.
+- '처음부터 올바르게' 시스템을 만들 수 있다는 믿음은 미신이다. 대신에 우리는 오늘 주어진 사용자 스토리에 맞춰 시스템을 구현해야 한다. 내일은 새로운 스토리에 맞춰 시스템을 조정하고 확장하면 된다. 이것이 반복적이고 점진적인 애자일 방식의 핵심이다.
+- AOP에서 관점이라는 모듈 구성 개념은 "특정 관심사를 지원하려면 시스템에서 특정 지점들이 동작하는 방식을 일관성 있게 바꿔야 한다." 라고 명시한다. 명시는 간결한 선언이나 프로그래밍 매커니즘으로 수행한다.
+
+# 느낀점
+
+시스템 구성에 있어 관심사 분리의 중요성에 대해 강조한 챕터였다. 의존성 주입, 확장성 있도록 구현하는 것, 횡단 관심사와 같은 내용은 백엔드를 공부하다보면 쉽게 듣게 되는 내용들이다. 그러나 왜 중요한지에 대한 의문보단 다들 중요하다니까 외워둬야지가 더 컸던 것 같다. 이 챕터를 읽으면서 이 내용들이 강조하는게 무엇인지, 우리가 쉽게 들었던 의존성 주입과 같은 내용이 관심사 분리에 어떻게 작용하고, 왜 관심사 분리가 중요한지에 대해서 조금은 더 알게 된 것 같다. 특히 처음부터 올바르게 시스템을 만들 수 있다는 믿음은 미신이란 내용이 와닿았는데, 나 역시도 그런 믿음을 가지고 있었던 것 같다.

12장/전호영.md

@@ -0,0 +1,15 @@
+# 다시 볼 문장들
+
+- 켄트 백은 다음과 같은 규칙을 따르면 설계는 '단순하다'고 말한다.
+  - 모든 테스트를 실행한다.
+  - 중복을 없앤다.
+  - 프로그래머 의도를 표현한다.
+  - 클래스와 메서드 수를 최소로 줄인다.
+- 설계는 의도한 대로 돌아가는 시스템을 내놓아야 한다. 문서로는 시스템을 완벽하게 설계했지만, 시스템이 의도한 대로 돌아가는지 검증할 간단한 방법이 없다면, 문서 작성을 위해 투자한 노력에 대한 가치는 인정받기 힘들다. 테스트를 철저히 거쳐 모든 테스트 케이스를 항상 통과하는 시스템은 '테스트가 가능한 시스템'이다. 당연하지만 중요한 말이다. 테스트가 불가능한 시스템은 검증도 불가능하다. 당연하지만 중요한 말이다. 테스트가 불가능한 시스템은 검증도 불가능하다. 논란의 여지는 있지만, 검증이 불가능한 시스템은 절대 출시하면 안된다.
+- 테스트가 가능한 시스템을 만들려고 애쓰면 설계 품질이 더불어 높아진다. 크기가 작고 목적 하나만 수행하는 클래스가 나온다. SRP를 준수하는 클래스는 테스트가 훨씬 더 쉽다. 테스트 케이스가 많을수록 개발자는 테스트가 쉽게 코드를 작성한다. 따라서 철저한 테스트가 가능한 시스템을 만들면 더 나은 설계가 얻어진다.
+- 놀랍게도 "테스트 케이스를 만들고 계속 돌려라"라는 간단하고 단순한 규칙을 따르면 시스템은 낮은 결합도와 높은 응집력이라는, 객체 지향 방법론이 지향하는 목표를 저절로 달성한다. 즉, 테스트 케이스를 작성하면 설계 품질이 높아진다.
+- '소규모 재사용'은 시스템 복잡도를 극적으로 줄여준다. 소규모 재사용을 제대로 익혀야 대규모 재사용이 가능하다.
+
+# 느낀점
+
+Clean Code 책을 관통하는 챕터인 것 같다. 앞서 읽어왔던 내용을 다 종합하면 결국 '테스트 작성이 쉬운 코드를 작성하고, 모듈을 설계하라'라고 요약이 된다. 항상 테스트 코드를 짜려고 노력해왔다. 그러나 위와 같이 의식적으로 목표를 가지고 테스트 코드를 작성하지 않았다. 테스트 코드를 작성할 때, 코드를 작성할 때 가져야 할 마음가짐에 대해 배우게 된 챕터이다.

13장/전호영.md

@@ -0,0 +1,18 @@
+# 다시 볼 문장들
+- 동시성은 결합을 없애는 전략이다. 즉, 무엇과 언제를 분리하는 전략이다. 스레드가 하나인 프로그램은 무엇과 언제가 서로 밀접하다. 그래서 호출 스택을 살펴보면 프로그램 상태가 곧바로 드러난다.
+- 무엇과 언제를 분리하면 애플리케이션 구조와 효율이 극적으로 나아진다. 구조적인 관점에서 프로그램은 거대한 루프 하나가 아니라 작은 협력 프로그램 여럿으로 보인다. 따라서 시스템을 이해하기가 쉽고 문제를 분리하기도 쉽다.
+- 동시성에 대한 흔한 오해
+  - "동시성은 항상 성능을 높여준다"
+  - "동시성을 구현해도 설계는 변하지 않는다"
+  - "웹 또는 EJB 컨테이너를 사용하면 동시성을 이해할 필요가 없다"
+- 동시성 코드가 일으키는 문제로부터 시스템을 방어하는 원칙과 기술
+  - 동시성 코드는 다른 코드와 분리하라.
+  - 자료를 캡슐화하라. 공유 자료를 최대한 줄여라.
+  - 다른 스레드와 자료를 공유하지 않는다.
+  - ConcurrentHashMap은 거의 모든 상황에서 HashMap보다 빠르다. 
+  - 공유 객체 하나에는 메서드 하나만 사용하라.
+  - 잠긴 영역에서 다른 잠긴 영역을 호출하지 않는다.
+  - 공유하는 객체수와 범위를 최대한 줄인다.
+
+# 느낀점
+SRP 에 신경쓰는 것, 메서드가 커버하는 양을 줄이고, 최대한 독립적으로 메서드를 구현하는 것이 동시성을 줄이는 방법인 것 같다. 하지만 아직 동시성 프로그래밍을 해본적이 많이 없어, 제대로 이해를 하진 못했다. Node.js를 사용할 땐, event loop를 사용한 비동기로 이런 동시성 문제를 자주 피해갔다. 사실 깊게 생각할 일도 없었다. Event Loop를 통해 동시성 문제를 피해가는 방법, C++나 Java 에서처럼 임계영역을 활용해서 동시성 문제를 피해가려는 노력 등을 이해하는 것도 재미있는 공부인 것 같다.