docs: 5장 정리

5장/정리.md

@@ -0,0 +1,102 @@
+
+### 서준환
+
+- 객체 내부의 상태를 묻는다 공감하지 못 했음.
+- 메서드 체이닝에서는 처음에는 점을 하나만 쓸 수 있게끔 하는 게 옳은 건가 생각했으나, 다 읽고나서 이해할 수 있었음.
+- 메서드 체이닝이 길어지면 라이브러리의 인터페이스 변경 시 메서드 체이닝을 사용하는 코드에서 변경 시 영향이 크다고 생각햇음.
+- 싱글턴 패턴도 전역 변수의 일종이라는 점을 다시 상기했음.
+- zag 라이브러리 xState 상태 머신을 실무에서 써보고 좋다고 느꼈지만, 다른 개발자들이 보시기 불편하실 수 있겠다 느꼈음.
+- 옵저버 패턴과 구독 패턴에 대해 비슷하다고 생각했음. 해당 패턴들은 디자인 패턴 책에서 학습했음. <br> 
+  소나마(?) 리액트 핫토스트(?) 라이브러리 코드를 까보니 각각 쓰이고 있었음. 보면서 이렇게도 리액트랑 같이 쓸 수 있구나 느꼈음.<br>
+  최근에 토스의 오버레이 키트(?)도 기존 훅 방식에서 옵저버 패턴으로 바뀐 것을 보았는데, 개인적으로 생각했던 단점들이 해결된 것 같아 좋은 패턴이라 생각했음.
+- 반응형 프로그래밍에 대한 관심이 있으며, 특히 Angular와 RxJS의 사용이 신기했음.
+- 변환 프로그래밍 부분은 이해가 어려워 넘어갔고, 상속에 관한 부분에서 다시 생각해보함 계기가 되었음.
+
+
+### 이상조
+
+- 유한 상태 기계 어려웠음. 
+- 메서드 체이닝이 길어지면 특정 메서드가 수정되면 반환 값이 달라질 수 있고, 그에 따라 다른 부분도 수정해야 하는 상황이 발생할 수 있음.
+- 유한 상태 머신은 리덕스와 비슷하다 생각했지만, 다른 자료를 보고 다르다고 생각했음.
+- 간단한 토스트 기능을 구현할 때 옵저버 패턴을 사용했음.
+- Pub-Sub 패턴 어려웠음.
+- 회사에서 RxJS를 사용하다가 React Query로 마이그레이션하는 중인데, RxJS의 인터페이스가 나쁘지 않다고 생각했음.
+- 학습하며 반응형 프로그래밍과 옵저버 패턴의 관계를 이해했음. 
+- RxJS의 메서드 체이닝 방식이 편리하게 느껴졌지만, 캐싱 문제 등으로 React Query로 전환한 것으로 추측했음.
+- 변환 프로그래밍은 잘 이해하지 못했음.
+
+### 백지연
+
+- 실무에서 레거시를 다루고 있다보니 유연한 코드에 대해서 감을 익혔음. 
+- 객체에 위임하는 방식이 가독성과 결합도를 줄이는 데 효과적이라는 것을 깨달음.
+- 메서드 체이닝보다는 끊고, 변수명을 통해 가독성을 높이는 방식이 더 좋다고 생각했음.
+- 전역 데이터 부분은 당연하다 생각했음.
+- 저글링하기 부분에서는 자바스크립트 예시를 찾아보려고 노력했음.
+- 상태 머신 관련해서는 XState 외에는 경험이 없어, 준환님의 예시를 찾아볼 예정.
+- 감시자 패턴은 어디서 사용되고 있는지 잘 몰랐으나 블로그 글의 자바스크립트 예시를 통해 이해를 높였음.
+- 리덕스 메인테이너가 작성한 글을 보며 리덕스에 대한 해당 개발자의 생각을 감명 깊게 읽었음. 해당 글에 리덕스 스토어(?) 간소화 버전 코드가 pub-sub구조로 구현되어 있어 추천함.  
+- 반응형 프로그래밍에 대해 처음에는 모바일이나 태블릿과 관련된 것이라 생각했지만, 다른 개념이라는 것을 깨달았음.
+- 상속을 사용하는 상황이 많지 않아, 큰 인상을 받지 못했음
+
+### 박상범
+
+- 이번장은 결합도를 줄이는 방법으로 이해했음.
+- 열차사고 부분은 이해하기 어려웠으나, 다른분들 덕분에 이해했음.
+- 메서드 체이닝 줄이는 것은 크게 와닿지 않았음.
+- 선언적 프로그래밍의 중요성을 강조하고 있다고 느꼈음.
+- 이벤트 기반 애플리케이션 전략에 소개된 패턴들 간의 차이점이 명확하지 않아 어려웠음.
+- 리액트 쿼리 내부 동작을 봤는데 옵저버 패턴과 pub-sub 패턴을 섞은 것 같다고 생각했음. 
+- 변환 프로그래밍과 관련된 내용 이해하기 어려음. 파이프라인 연산자는 데이터 변환 관점에서 생각하게 해준다고 이해했음. 
+- 상속의 대안 중 믹스인을 유틸리티 함수처럼 이해했지만, 이것도 너무 커지면 문제가 될 수 있다고 생각했음.
+- 회사에서 서비스형 설정 사용하고 있으며, 동료분들에겐 사용 경험이 좋아보이는데 프론트 개발자인 나에겐 공감이 잘 안갔음.
+
+### 오혜성
+
+- 2판과 1판의 5장 내용은 매우 다른 것으로 보임.
+- 1판에는 샤이 코드 이야기가 있음. 샤이 코드에 대해서 이야기할 때 다른 모듈이 변경되거나 교체될 때 다른 모듈들이 변경 없이 수행되게 하는 것을 권장하는 것으로 보임.
+- 자동으로 알아서 바뀌면 좋겠지만 바뀌는 도중에 사람의 손길이 필요한 것들도 있을 수 있다고 생각함.
+- 빌드 타임에 알아서 컴파일 타임에 알아서 많이 알 수 있도록 하는 것도 중요하다고 생각함.
+- 메타 프로그래밍 챕터에서 소개된 세부 내용을 일반 텍스트인 메타데이터로 표현 부분은 2판에서 빠진걸보니 퇴색된 방법인건가 생각했음.  
+- 시간적 결합 챕터 있음.
+- 단지 뷰일 뿐이야 챕터 있음. MVC 패턴이 생각났음. 모바일 진영에서는 mvvm 패턴이 일반적으로 쓰인다고 함.
+- 리액트 쿼리의 쿼리 캐시가 칠판 역할을 하지 않을까 생각했음. 그래서 칠판 정리 중요성 부분에서 다른분들은 어떻게 쿼리 키를 관리하는지 궁금해졌음. <br>
+  플럭스 패턴 기반의 리덕스를 사용하면 우아하게 해결할 수 있다고 생각했음.
+
+
+### 박승훈
+
+- 메서드 체이닝 정도는 트레이드 오프 고려해서 적절하게 사용하는게 중요하다 생각했음.
+- 파이프라인은 두 개념 구현을 생각했음.
+  - 프로미스
+  - 빌더패턴
+    - 현업에서 동료들이 적용했음.
+- 실무에서 상위에 정의된 상태 데이터가 여기저기서 하위로 프롭스 딜링(?)하는 코드들을 보면서 왜 전역 상태를 사용하지 않나 의아했는데 글로벌화의 해악을 읽고 이해했음. (리액트 써본 적이 없어 들리는 대로 적어서 맞는지 모르겠네요ㅠ)
+  - 앞으로 전역상태는 보수적으로 사용할 예정.
+- 싱글톤도 전역 데이터라는게 의외였으며, 리액트 쿼리도 전역데이터처럼 사용되는 것 같다.
+- 어플리케이션 코드가 엉망일지라도 제 역할은 해야한다는 것에 깊이 공감했음.
+- pub-sub, 감시자 패턴 각각 트레이트오프가 있으니 상황에 맞게 잘 사용하는게 중요하다고 생각했음.
+- 변환 프로그래밍에서 변환 찾기는 코딩 테스트가 생각났음.
+- 인터페이스 상속을 자주 사용하는데 베이스 인터페이스 변경 시 하위 인터페이스도 변경해야 하는 문제를 어떻게 잘 관리할지 고민 중임. 
+- 설정을 외부화 부분은 유용했음. 실무에서 설정 부분에 적용해볼 수 있을 것 같다고 생각했음.
+
+
+### 신승준
+
+- 회사에서 예전에 userQuery로 가져온 데이터를 전역으로 사용하는게 유행이였는데, 준환님이 걷어내는데 고생하셨음.
+- xState를 사용해보고 싶음.
+- 감시자 패턴이 소노 라이브러리 코드에 적용되어 있는데, 리덕스나 리액트 쿼리 라이브러리 코드를 이해할 때 도움이 될 것 같다고 생각했음.
+- 여담으로 소노 라이브러리가 인기있는 오픈소스라 코드 퀄리티를 기대했는데 약간 실망했음.
+- 변환 프로그래밍이랑 함수형 프로그래밍이 유사하다고 생각했음.
+- 219페이지의 엘릭서 예제 코드가 신기했으며, 다른 언어에서만 가능한 것들에 관심이 갔고 러스트를 공부해보고 싶다고 생각했음.
+- 상속 부분에 언급된 단점들은 자바스크립트에서 프로토타입을 건드리지 말라는 것과 같은 맥락이라 생각했음.
+
+
+### 변수미
+
+- 묻지 말고 말하라는 응집도 관리로 이해했음.
+- 전역 데이터 피하라는 부분은 매우 공감했으며, 이번에 외부 리소스도 전역 데이터라는 것을 알게 되었음.
+- 유한 상태 기계 웹 개발에서 잘 사용되지 않는다고 생각했음. 예전에 계산 이론(?)에서 사용했던 기억이 있음. 컴파일러 쪽에서는 많이 사용되는데 웹 개발에서는 플로우 다이어그램 정도의 의미 같다고 생각했음.
+- 감시자는 동기, pub-sub은 비동기적이라 성능 개선 버전이 아닌가 생각했음.
+- 반응형 프로그래밍은 스프레드시트가 생각났음.
+- 변환 프로그래밍은 데이터를 변환하고 출력으로 바꾸는 사고 방식으로 돌아가는 것으로 이해했음.
+