출처 : Readable Code: 읽기 좋은 코드를 작성하는 사고법 - 박우빈

1. 학습 내용 요약

추상(섹션 1, 2)

클린 코드를 추구하는 이유

바로 “가독성” → 유지보수가 쉬움 = 비용 감소

이름짓기

이름을 짓는다 = 추상화

1. 단수와 복수를 구분하기

2. 이름 줄이지 않기

3. 은어/방언 사용 X

4. 좋은 코드를 보고 습득하기

메서드 선언부

1. 메서드명

   1. 추상화된 구체를 유추 가능한 적절한 의미의 이름

   2. 파라미터와 연결 지어 풍부한 의미 전달

2. 파라미터

   1. 파라미터 타입, 개수, 순서를 통해 의미 전달

   2. 외부와 소통하는 창

3. 반환타입

   1. 메서드 시그니처에 납득이 가능한 적절한 타입의 반환값

   2. void 대신 충분히 반환할 만한 값을 고민

논리, 사고의 흐름(섹션 3)

Early return

그냥 if에서 바로 리턴하고, 기존 else를 if로 재작성하면 이전 if문의 조건 정보는 기억할 필요 X → Early return의 장점

따라서 Early return으로 else의 사용을 지양할 것! switch문도 마찬가지!

사고의 depth 줄이기

1. 중첩 분기문, 중첩 반복문

   1. 인지해야 하는 조건들이 너무 많음

   2. 메서드로 추출해서 다 분리하면 best

   c. BUT. 무조건 1 depth로 만들어라가 아님!!! → 사고 과정의 depth를 줄이는 것이 핵심

2. 사용할 변수는 가깝게 선언하기

부정어구 사용 자제

1. 부정어구를 쓰지 않아도 되는 상황인지 체크 → right, left, up, down

2. 부정의 의미를 담은 다른 단어가 존재하는지 고민 or 부정어구로 메서드명 구성

해피 케이스와 예외 처리

예외 처리 방법

1. 예외가 발생할 가능성 낮추기

2. 어떤 값의 검증이 필요한 부분은 주로 외부 세계와의 접점 → 사용자 입력, 객체 생성자, 외부 서버 요청 등

3. 의도한 예외와 예상하지 못한 예외 구분하기

SOLID(섹션 4)

SRP: Single Responsibility Principle

• 하나의 클래스는 오로지 하나의 책임 만을 갖는다.

• 객체의 공개 메서드, 필드, 상수 등은 해당 객체의 책임에 의해서만 변경 가능

2. OCP: Open-Closed Principle

• 확장에는 열려 있고, 수정에는 닫혀 있다.

• 시스템의 기능 확장

3. LSP: Liskov Substitution Principle

• 부모 클래스의 인스턴스를 자식 클래스의 인스턴스로 치환 가능해야 한다.

• 불필요한 타입 체크 문제

4. ISP: Interface Segregation Principle

• 클라이언트는 자신이 사용하지 않는 인터페이스에 의존하지 않는다.

• 인터페이스를 잘게 나눔

5. DIP: Dependency Inversion Principle

• 상위 수준의 모듈은 하위 수준의 묘듈에 의존하지 않는다.

• 모두 추상화에 의존할 것

Value Object(섹션 5)

• 도메인의 어떤 개념을 추상화하여 표현한 값 객체

• 값으로 취급하기 위해, 불변성, 동등성, 유효성 검증 등을 보장

  • 불변성 : final 필드, setter 금지

  • 동등성 : 서로 다른 인스턴스여도 내부 값이 같으면 같은 객체 → equals()와 hashCode() 재정의 필요

  • 유효성 검증 : 객체가 생성되는 시점에 값에 대한 유효성 보장

• 해당 객체를 마치 데이터 타입처럼 사용 가능

VO vs Entity

• Entity는 식별자 가 존재 → 식별자가 같으면 동일한 객체

• VO는 식별자 없이 내부의 모든 값이 같아야 동등한 객체 → 전체 필드가 다같이 식별자 역할

일급 컬렉션

• 다른 요소에게 사용 가능한 모든 연산을 지원하는 요소 → 변수로 할당 or 파라미터로 전달 or 함수의 결과로 반환

• 컬렉션을 포장해 컬렉션만을 유일하게 필드로 가지는 객체

• 컬렉션을 추상화하며 의미를 담을 수 있고, 가공 로직의 보금자리가 생김

• 만약 getter로 컬렉션을 반환할 일이 생긴다면, 외부 조작을 피하기 의해 꼭 새로운 컬렉션으로 만들어서 반환

   

Enum

• 상수의 집합으로, 상수와 관련된 로직을 담을 수 있는 공간

• 경이 잦을 경우 Enum 보다 DB 관리를 추천

2. KPT

Keep(칭찬하고 싶은 점)

• 코드를 직접 따라 치면서 이론을 실무에 적용해 이해하도록 노력했다.

• 미션을 밀리지 않고 시간에 맞춰 제출했다.

• 학습한 내용을 노션에 정리하고 있다.

Problem(아쉬웠던 점)

• 코드를 분석하며 학습을 진행하니 학습 속도가 다소 늦어지고, 오래 걸린다.

• 후반부에 들어서 강의 내용도 어려워지면서 이해가 안 되어도 그냥 넘어가는 경우도 간혹 발생한다.

• 리팩토링 기록을 깃헙에도 남기고 싶었는데 시간 관계 상 하지 못했다.

Try(보완하고 싶은 점)

• 학습에 우선순위를 둘 것(강의듣기 -> 리팩토링 -> 노션정리)

• 이해가 안 되는 부분은 반복+질문으로 해결할 것

• 이론 정리와 리팩토링 학습을 골고루 진행할 것

• 학습 시간 제한을 두어 타이트하게 일정을 관리할 것

3. 미션 회고

미션 1 : 드립 커피 추출을 추상과 구체화로 표현했다. 구체화의 단계를 어느 단계까지 low하게 내려가야 할 지 다소 난감했던 기억이 난다. 추후 다른 사람들의 미션 내용도 확인하면서 조금 더 학습할 예정이다.

미션 2 : 코드 리팩토링 과제였다. 학습한 내용을 단계별로 적용하는 과정을 남기고 싶었는데 이게 단계를 명확하게 구분하기 어렵고, 순서도 머릿속에 뒤죽박죽이 되어 step 별로 정리하는데 애를 먹었다. 실제로 공부한 내용을 적용해 볼 수 있는 시간이라 재밌었다.

4. 느낀점

미션2를 제출하면서 다른 분들이 제출한 내용도 함께 봤는데 역시 잘 하시는 분들이 어마어마하게 많았다. 강의내용에도 허덕이는 스스로에게 자괴감이...😢 그래서 이번주 결론은 다음주는 더 빡세게 공부하자!!!!!!!!!