[공예영] 5장, 6장, 7장 : 형식 맞추기 외 2장

5장/공예영.md

@@ -0,0 +1,11 @@
+**📕 Ch5. 형식 맞추기**
+
+> 빈 행을 이용해서 개념 분리하기
+
+> 변수는 사용하는 위치와 가까이 선언하기
+
+> 연관된 함수는 가까이 배치하기
+
+일관된 형식을 유지하는 것은 중요하다. 스스로 어느정도의 규칙이 생기면, 익숙해져서 줄바꿈이라도 잘못되어있으면 거슬려서 꼭 바꿔주게 된다. <br>
+프론트에서는 eslint와 prettier를 사용하면 기본적인 규칙을 강제할 수 있다. IDE에서 저장할 때 자동으로 포맷팅되도록 설정해두면 굳이 줄 맞추기, 세미콜론, 들여쓰기 같은 디테일에 신경 쓸 필요가 없어서 굉장히 편하다.
+<br>협업할 때 이런 형식 통일은 필수적하다. 누가 코드를 짰든 항상 같은 스타일로 유지되면, 팀원 간 코드 리뷰도 훨씬 수월하고, 신규 멤버가 들어와도 코드 스타일에 적응하느라 헤매지 않는다. 

6장/공예영.md

@@ -0,0 +1,13 @@
+**📕 Ch6. 객체와 자료구조**
+
+> 객체 지향 코드와 절차 지향 코드는 상호보완적이다. 객체 지향은 새 클래스를 추가하기 쉽고, 절차 지향은 함수를 추가하기 쉽다.
+
+> 우수한 소프트웨어 개발자는 편견없이 이 사실ㅇ르 이해해 직면한 문제에 최적인 해결책을 선택한다.
+
+예전에는 리액트에서 클래스형 컴포넌트를 주로 사용했지만, 지금은 함수형 컴포넌트와 훅의 등장으로 함수형 프로그래밍이 대세가 되었다.
+<br>
+함수형 컴포넌트는 구조가 단순하며 가독성이 좋고, 트리 셰이킹이 가능해 번들 사이즈를 줄이는 데도 유리하다.
+
+반면 클래스형 컴포넌트는 상태 관리나 라이프사이클을 다루는 방식이 복잡하고 재사용 측면에서도 불편한 점이 많다. <br>하지만 그렇다고 클래스 기반 코드를 완전히 배제할 수는 없다. 실제로 모듈화, 구조 설계를 고민하다 보면 특정 부분에서 객체 지향적인 접근이 더 적합한 순간이 분명 존재한다. 클래스 기반의 추상화나 캡슐화는 여전히 유용한 개념이다.<br>
+
+어떤 방식이 더 좋은 가보다는, 각 문제마다 어떤 방식이 더 적합한지 판단하고 활용할 수 있는 능력이 중요하다고 느꼈다.

7장/공예영.md

@@ -0,0 +1,15 @@
+**📕Ch 7. 오류처리**
+
+> 오류 처리를 프로그램 논리와 분리해 독자적인 사안으로 고려하면 튼튼하고 깨끗한 코드를 작성할 수 있다.
+
+프론트엔드 개발을 하면서도 꾸준히 고민하게 되는 부분이다. <br>
+책에서는 주로 자바 기반의 예외 처리 흐름을 예로 들고 있지만 프론트엔드에서도 오류 처리는 중요한 설계 요소다. <br>
+<br> 나는 tanstack-query의 onError 콜백을 적극 활용하고 있다. <br>
+서버와의 통신에서의 다양한 오류 상황을 컴포넌트 내부 로직과 섞지 않고 훅 레벨에서 처리하도록 분리한다.<br>
+이렇게 하면 에러 처리가 UI 로직과 섞이지 않아서 더 읽기 쉬운 코드가 되고, 재사용성도 좋아진다.
+
+하지만 최근 `tanstack-query` v5에서 `onError`, `onSuccess` 등 콜백이 deprecated되면서 그 방식이 예기치 못한 부작용을 유발할 수 있다는 걸 다시 돌아보게 되었다. <br>
+나 역시 이전에 동일한 훅이 여러 번 호출될 때 onError도 중복 호출되어 같은 토스트 메시지가 화면에 반복 출력되는 문제를 겪은 적이 있다. <br>
+당시에는 글로벌 토스트 처리 로직으로 중복 메시지를 필터링해 임시 해결했지만, 지금 생각하면 그건 근본적인 해결책은 아니었다.<br>
+<br>
+앞으로는 tanstack-query가 권장하는 방식처럼 전역 에러 핸들링을 도입해 안정적인 에러 처리 구조를 구성해보려 한다.