# 학습에 관한 회고

클린 코드에 대해 작정하고 탐구한 적은 없지만 모 부트캠프 선발과정에서 해당 주제를 처음 접하고 고민해본 적은 있었다. 덕분에 강의에서 나오는 단어와 이야기들이 아주 낯설지는 않았다. 그때도 느꼈지만 개념만 놓고 보면 참 아리송한 이야기들로 한가득이다. 문장으로는 읽히지만 곧 '그래서 뭐 어쩌라는거지', '이렇게.. 이렇게 하면 되는건가? 맞나?' 라는 질문들로 가득 찬다.

강의는 고맙게도 설명과 간단한 예시에서 그치지 않고 아예 작은 프로젝트 하나를 통째로 뜯어고치며 그 내용들을 직접 적용해 설명해준다. 덕분에 명확하게 개념이 보이는 것들도 있고 아직은 아리송한 것들도 있다. 그래도 예시를 함께 보니 이전보다 훨씬 뚜렷해졌다.

1주차가 시작되기 전에 미리 강의를 수강해두고 싶었는데 이전에 수강하던 강의 완료가 늦어져 그러질 못했다. 따라서 정해진 일정에 늦지 않게 맞춰 따라가는게 중요했다. 큰 무리 없이 따라가나 싶었지만 후반부에 다른 일이 끼어들어 진도 맞추는게 좀 빠듯해졌다. 또 강의 시간을 그대로 일정표에 적용했는데 코드를 실제로 작성하며 학습하는 과정 때문에 예상보다 좀 더 시간이 소요됐다. 2주차에선 각 섹션별로 시간을 좀 더 넉넉하게 잡고 본 클럽의 일정을 우선순위로 두어 무리없이 학습을 따라갈 예정이다.

# 미션

첫번째 미션은 '자유 주제로 추상화 연습해보기' 였다. 주제는 도메인이기에 내게 익숙한 취미생활 '볼링'으로 결정했다. 볼링 투구에 대해서 떠들어보라고 하면 몇 시간 단위로 떠들 수 있는 나이기에 파악된 정보를 추상화하기는 쉬울거라 생각했다.

처음엔 상위 문장에서 점점 추상화를 통해 분리해 나갈 생각이었는데 이게 생각보다 쉽지 않았다. 이미 내 머리속에 로우 레벨의 정보들이 너무 많아서 차근차근 추상화되지 않고 한번에 몇 단계를 넘어 상세한 내용들이 쏟아진게 원인이었다. 추상화의 레벨이 중요함을 직접 체감했다.

덕분에 과제 수행에 있어 순방향인지 역방향인지 모르겠지만 로우 레벨의 정보들을 모두 나열하고 관련 있는 정보들을 묶어 하이 레벨로 올라가기로 했고 잘 먹혀든 것 같다.

또, 로우 레벨의 정보들에도 볼링 용어라고 할 만한 단어들이 많이 있었는데 이걸 더 풀어 설명하자니 지나치게 길어지는게 문제였다. 이를 도메인 지식이라고 할 수 있을 것 같다. 미리 알고 있어야 대화가 쉽게 풀리는 부분이 있음을 느꼈다.

두번째 미션은 '추상화로 직접 코드 리팩토링 하기' 이다. 아직 나는 리팩토링이 익숙하지 않아 차근차근 해보기로 했다.

먼저 복잡한 조건문들을 파악하여 early return의 형태를 갖췄다. 그 후 validateOrder메서드의 목적, 문맥과 함께 Order객체가 가질 책임을 상상해서 들어날 필요 없는 조건들을 모두 객체 내부 메서드로 옮겼다. 이름은 최대한 연속적으로 읽히도록 작명했다.

결과,

Order의 유효성을 검증할 건데, Order가 아이템을 가지고 있지 않다면, Order는 유효하지 않다.

Order가 총 가격이 0보다 같거나 작다면, Order는 유효하지 않다.

Order가 고객 정보를 가지고 있지 않다면, Order는 유효하지 않다.

위 조건에 걸리지 않으면 Order는 유효하다.

로 정리할 수 있었다.

한가지 해결하지 못한 부분이 있었는데 두 번째 총가격 검증 부분에서 0이 메서드가 넘겨주는 인자가 되어야 할지, Order가 내부에서 알아서 기준을 세워 검증해야할지 의문이었다. 외부에서 0이라는 값을 지정한다면 이후 다양한 조건을 지정할 수 있을 것이고 Order가 내부에서 기준을 가진다면 validateOrder는 검사를 요구하기만 하면 되기 때문에 추상화 레벨에 맞다는 생각이 든다.

세번째 미션은 'SOLID 정리하기'.

이는 학습하면서 받은 느낌의 첫 인상만 짧게만 정리했다. 아직은 알것 같으면서 실천하라고 하면 좀 주춤할 것 같은 단계라 좀 더 코드로 직접 체감을 해봐야겠다.

# 학습 내용 요약

## 왜 클린 코드?

- 가독성, Readability를 위해

단순히 줄간격 등의 양식을 말하는 것이 아니다. 글, 코드가 잘 읽혀야한다. 잘 읽힌다는 것은 이해가 잘된다는 것을 뜻한다. 이해가 잘되면 유지보수가 수월해진다.

## 어떻게 클린 코드?

- 추상화, 중요한 정보를 골라 남기고 덜 중요한 정보는 치워둔다.

지금 작성하는 메서드의 문맥을 읽고 핵심을 결정한다. 작성된 모든 코드는 메서드의 작동에 필요한 요소겠지만 지금 이 메서드의 이름에 부합하는 내용의 뼈대만 고르고 나머지는 다른 메서드에 치워둔다. 이를 반복하여 추상화 레벨을 다듬고 읽기 좋은 코드를 완성한다.

## 몇 가지 구체적인 방법

- 빠른 리턴, 조건을 구질구질하게 늘여놓지 말자

1. 이러하면 이거, 인데 아니면 저러할때때 저거, 인데 둘 다 아니면 그것.

조건이 여러 개 겹쳐서 읽힌다.

1. 이러하면 이거. 저러하면 저거. 그러하면 그거.

필요한 조건들만 분류하여 가독성을 높힌다.

- 부정 연산자를 지양해보기

if(!이러하면): '이러하지 않다면', 한 번 더 생각해야 한다.

if(이러하지 않다면): '이러하지 않다면', 메서드명에 넣어버리자 읽기 편해진다.

## 객체를 존중하기

- 객체의 책임을 항상 염두해두고 이를 기반으로 적절한 추상화를 해야함

## SOLID에 대해 정리해보기

### SRP

- 단일 책임의 원칙이란 하나의 클래스가 하나의 주제만 가지는 것

### OCP

- 개방-폐쇄의 원칙이란 새로운 코드 작성에 기존 코드가 영향 받지 않는 것

### LSP

- 리스코프 치환 원칙이란 부모 클래스는 자식 클래스의 부분집합이라는 것

### ISP

- 인터페이스 분리 원칙이란 인터페이스에는 반드시 필요한 메서드들만 선언하는 것

### DIP

- 의존성 역전의 법칙이란 추상화된 의존관계를 주입시켜 주는 것

## 상속보다 조합

- 상속보다는 조합이 우수하다.

그럼.. 상속은 아무데도 쓸 곳이 없는건가요..? 상속만이 가지는 장점이 뭘까..

## VO

- 기본 타입을 랩핑

- 불변성, final, setter 금지

- 동등성, equals() & hashCode() 재정의

- 유효성 검증, 생성 시점에 유효한 값 검증하기

## Entity

- 엔티티는 식별자가 존재한다. 이 식별자를 통해 동등성을 파악한다.