[최서희] 5장, 6장, 7장 : 형식 맞추기 외 2장

5장/최서희.md

@@ -0,0 +1,59 @@
+# 5장. 형식 맞추기
+
+## 인상 깊은 내용 
+
+- **형식을 맞추는 목적**
+
+  코드 형식은 의사소통의 일환이다. 의사소통은 전문 개발자의 일차적인 의무다.
+  오늘 구현한 코드의 가독성은 앞으로 바뀔 코드의 품질에 지대한 영향을 미친다.
+  오랜 시간이 지나 원래 코드의 흔적을 더 이상 찾아보기 어려울 정도로 코드가 바귀어도 맨 처음 잡아놓은 구현 스타일과 가독성 수준은 유지보수 용이성과 확장성에 계속 영향을 미친다.
+
+- **적절한 행 길이를 유지하라**
+
+  일반적으로 큰 파일보다 작은 파일이 이해하기 쉽다.
+
+- **신문 기사처럼 작성하라**
+
+  이름은 간단하면서도 설명이 가능하게 짓는다. 이름만 보고도 올바른 모듈을 살펴보고 있는지 아닌지를 판단할 정도로 신경 써서 짓는다. 소스 파일 첫 부분은 고차원 개념과 알고리즘을 설명한다. 아래로 내려갈수록 의도를 세세하게 묘사한다. 마지막에는 가장 저차원 함수와 세부 내역이 나온다.
+
+- **개념은 빈 행으로 분리하라**
+
+  너무도 간단한 규칙이지만 코드의 새로 레이아웃에 심오한 영향을 미친다. 빈 행은 새로운 개념을 시작한다는 시각적 단서다. 코드를 읽어 내려가다 보면 빈 행 바로 다음 줄에 눈길이 멈춘다.
+
+- **세로 밀집도**
+
+줄바꿈이 개념을 분리한다면 세로 밀집도는 연관성을 의미한다.
+
+- **수직 거리**
+
+  서로 밀접한 개념은 세로로 가까이 둬야 한다.
+  같은 파일에 속할 정도로 밀접한 두 개념은 세로 거리고 연관성을 표현한다. 여기서 연관성이란 한 개념을 이해하는 데 다른 개념이 중요한 정도다. 연관성이 깊은 두 개념이 멀리 떨어져 있으면 코드를 읽는   사람이 소스 파일과 클래스를 여기저기 뒤지게 된다.
+  변수 선언, 변수는 사용하는 위치에 최대한 가까이 선언한다. 우리가 만든 함수는 매우 짧으므로 지역 변수는 각 함수 맨 처음에 선언한다.
+
+- **가로 형식 맞추기**
+
+  가로로는 공백을 사용해 밀접한 개념과 느슨한 개념을 표현한다.
+
+- **들여쓰기**
+
+  범위로 이뤄진 계층을 표현하기 위해 우리는 코드를 들여쓴다.
+  한 행에 범위를 뭉뚱그린 코드는 피해야한다.
+
+- **팀 규칙**
+
+  개개인이 따로국밥처럼 맘대로 짜대는 코드는 피해야 한다.
+  스타일은 일관적이고 매끄러워야 한다. 한 소스 파일에서 봤던 형식이 다르 소스 파일에도 쓰이라는 신뢰감을 독자에게 줘야 한다. 
+  온갖 스타일을 뒤섞어 소스 코드를 필요 이상으로 복잡하게 만드는 실수는 반드시 피한다.
+
+## 💭 느낀 점
+최근 프로젝트를 진행하면서, 초반에는 팀 규칙을 철저히 따랐다.
+코드 리뷰도 꼼꼼히 진행했고, 항상 `develop` 브랜치로 병합하기 전에 충분한 검토를 거쳤다.
+
+하지만 마감 기한이 다가올수록 이런 원칙들이 하나둘 무너지기 시작했다.
+서로 리뷰 없이 코드를 밀어넣거나, 스타일 가이드를 무시한 채 급하게 작업을 끝내는 일이 점점 많아졌다.
+
+또한 **“어차피 다음 스프린트에서 또 수정할 테니 지금은 이 정도면 괜찮겠지”** 라는 생각으로 여러 부분을 임시로 처리한 적도 있었다.
+하지만 그런 임시방편은 결국 **엄청난 리팩터링 부담**으로 되돌아왔다.
+
+이번 장을 읽으며 그때의 선택들이 자연스레 떠올랐고, 스스로를 돌아보게 되었다.
+그리고 다시금 깨달았다. **작은 원칙 하나를 끝까지 지키는 힘이, 결국 전체 시스템의 품질을 결정한다.**

6장/최서희.md

@@ -0,0 +1,32 @@
+# 6장. 객체와 자료 구조
+
+## 인상 깊은 내용
+
+* **객체는 동작을 공개하고 자료를 숨긴다.**
+
+  그래서 기존 동작을 변경하지 않으면서 새로운 객체 타입을 추가하기는 쉽다.
+  하지만 기존 객체에 새로운 동작을 추가하는 것은 어렵다.
+
+* 반대로 **자료 구조는 자료를 공개하고 동작은 숨긴다.**
+
+  그래서 기존 자료 구조에 새로운 동작을 추가하는 것은 쉽지만,
+  기존 함수에 새로운 자료 구조를 적용하기는 어렵다.
+
+---
+
+## 💭 느낀 점
+
+이번 장은 **자바를 기반으로 설명된 내용이 많아**,
+프론트엔드를 준비하고 있는 나로서는 이해하기가 조금 어려웠다.
+
+객체와 자료 구조의 차이를 언급하는 내용은 중요하다고 느꼈지만,
+아직은 내 개발 맥락과 직접적으로 연결되지 않아 완전히 와닿지는 않았다.
+
+그래서 프론트엔드 관점에서도 이 개념이 어떻게 적용될 수 있는지
+React와 상태 관리 라이브러리(Zustand, Redux 등)에서의 예제를 찾아보며 추가로 공부했다.
+
+예를 들어, **상태 관리 객체에 메서드를 함께 정의하는 방식**은 객체 지향적인 구조이고,
+반대로 **순수한 데이터와 액션을 분리해 처리하는 Redux 같은 패턴**은 자료 구조 중심 설계에 더 가깝다는 걸 알게 됐다.
+
+비록 처음엔 어려웠지만,
+앞으로 **상태 모델링, 커스텀 훅 설계, 컴포넌트 추상화**를 할 때 이 개념들이 실제로 도움이 될 거라고 느꼈다.

7장/최서희.md

@@ -0,0 +1,63 @@
+# 7장. 오류 처리
+
+## 인상 깊은 내용 - 우아하고 고상하게 오류를 처리하는 기법과 고려 사항 몇 가지를 소개
+
+* **오류 코드보다 예외를 사용하라**
+
+   오류가 발생하면 예외를 던지는 편이 낫다. 호출자 코드가 더 깔끔해지고, 논리와 오류 처리 코드가 뒤섞이지 않는다.
+
+* **Try-Catch-Finally 문부터 작성하라**
+
+* **미확인 예외를 사용하라**
+
+  아주 중요한 라이브러리를 작성하는 경우가 아니라면,
+  일반 애플리케이션에서는 확인된 예외보다 미확인 예외가 더 나은 선택일 수 있다.
+  의존성이 증가하는 비용이 이익보다 클 수 있기 때문이다.
+
+* **예외에 의미를 제공하라**
+
+* **호출자를 고려해 예외 클래스를 정의하라**
+
+  라이브러리 API를 감싸면서 **예외 유형 하나만 반환**하면,
+  호출자는 외부 라이브러리와의 의존성을 줄이면서 오류를 명확히 처리할 수 있다.
+  대부분의 경우 예외 클래스 하나로 충분하지만,
+  예외 상황에 따라 구체적으로 나눠야 할 때는 예외 클래스를 여러 개 사용하는 것이 적절하다.
+
+* **정상 흐름을 정의하라 (특수 사례 패턴)**
+
+  예외적인 상황을 객체나 클래스로 감싸서 처리하면,
+  클라이언트 코드에서 if-check 없이도 예외 상황을 우아하게 다룰 수 있다.
+
+* **Null을 반환하지 마라**
+
+  Null을 반환하면 호출자에게 책임을 넘기게 된다.
+  누군가 null 체크를 빠뜨리면, **예측 불가능한 버그**가 발생할 수 있다.
+  대신 예외를 던지거나, 특수 객체를 반환하는 방식이 더 안전하다.
+
+* **Null을 전달하지 마라**
+
+  메서드 인자로 null을 넘기는 것은 더 위험하다.
+  애초에 null을 허용하지 않는 정책을 세워두는 것이 실수를 줄이는 길이다.
+
+---
+
+## 💭 느낀 점
+
+프론트엔드 개발을 하면서도,
+**적절한 예외 처리를 통해 예상치 못한 오류를 찾아낸 경험**이 있었다.
+
+또한, 백엔드의 예외 처리 코드를 참고해
+**프론트 쪽 유효성 검증 로직을 구현한 경험**도 있다.
+그 과정을 통해 백엔드의 예외 처리 방식이
+**프론트와의 연동에 있어 얼마나 중요한 역할을 하는지**를 직접 체감했다.
+
+단순히 오류 메시지를 출력하는 것을 넘어서,
+**예외 처리 구조를 이해하고 그 흐름을 프론트에서 자연스럽게 연동하는 것**이
+결국 사용자 경험을 크게 좌우한다는 걸 깨달았다.
+
+이번 장 역시 앞 장과 마찬가지로
+프론트엔드에서는 자바스크립트를 주로 사용하는 입장에서
+책의 예시가 **자바 기반으로 구성되어 있는 점은 다소 아쉬웠다.**
+
+그럼에도 불구하고,
+**적절한 오류 처리를 통해 더 깔끔하고 안정적인 코드를 만드는 기법과 기준을 배울 수 있어 유익한 장이었다.**