Clean Code 독서 & 메모

<블로그 주인장의 말>

프로젝트를 진행하고 시간이 지난 후, 프로젝트를 재개하거나 다시 살펴봐야 할 일이 생겼을 때.

그 프로젝트를 다시 보려면 큰 각오가 필요하고 엄두가 안난다면?

이 책을 한번 읽어보자. 내가 코드를 클린하게 짜고 있는지.

---

코드는 요구사항의 상세한 표현이다

<클린코드의 4가지 원칙?>

중복을 피하라

한 기능만 수행하라

제대로 표현해라

작게 추상화해라

<우리는 저자다>
Javadoc에는 @author 필드가 있다

코드 작성을 글 작성처럼 이야기하는 듯 하다 (의도를 표현하는 글)

<좋은 코드를 작성하는 것은 오래 걸린다?>

80년대 에디터는 입력한 모든 커맨드를 기억했다. 그것을 재생시켜보면 실제로 코딩시간의 90%는 화면을 스크롤하고, 코드를 읽는 시간이었다고 한다

좋은 코드는 읽기 쉽다. 잘 안 읽히는 코드는, 코드 작성을 어렵게 만든다

변수/클래스는 명사구

함수/메서드는 동사구

<함수는 짧게>

함수길이는 최소한 한 화면에 들어와야 한다고 생각하고 있었지만,

이 책에서는 심지어 함수가 2~4줄 정도로 작아야 의도를 잘 표현한다고 이야기한다

함수의 최대 들여쓰기는 2단 이하를 추천한다

블록을 함수로 분리함으로써 2단 이하로 줄이는 것이다

함수 내 모든 라인의 추상화 레벨은 동일하게

SRP: Single Responsibility Principle

 - 가지 책임만 가져야 한다

OCP:Open Closed Principle

 - 변경에 닫혀있어야 한다 (new employee type이 추가될 때마다 case문을 추가해야한다)

앞부분에 Abstract Factory 패턴이 자주 나온다

<서술적인 이름 사용>

함수 이름이 길어도 괜찮다.

짧고 어려운 이름보다, 길고 서술적인 주석보다 좋다.

발음하기 쉬운 이름 사용

<파라메터>

파라메터 3개 이상은 피하자

특별한 이유가 없다면

많은 파라메터는 테스트도 어렵게 만든다

아웃풋 파라메터는 더 어렵다. 피하자

플래그 파라메터도 피하자

함수가 플래그에 따라 두가지 일을 한다고 대놓고 공표하는 셈이니까!

ex) render(True)

new Point(0,0)의 파라메터

이것은 한 값을 표현하는 두 요소이다. 두 요소에는 자연적인 순서도 있다

assertEquals(expected, actual)

이 함수는 2항을 피할수는 없지만, 항 사이 순서가 없다. 헷갈린다!

<오류코드 리턴보다는 예외 처리를 사용하라>

if문으로 에러코드를 리턴하면, caller는 에러코드를 "즉시" 처리해야 한다는 문제에 부딪힌다

하지만 try/catch문을 사용하면, 에러 처리 코드를 분리할 수 있다

또 하지만, 저자는 try/catch문이 코드 구조에 혼란을 일으키며 정상동작/에러처리 코드를 뒤섞어놓는다고 한다 (이해는 잘 안되지만)

그러므로 try, catch 블록 각각을 함수화 시켜야 한다고 이야기한다

좀더 추가설명을 하자면, 에러처리도 "한 작업"이므로 분리해야 한다는 것이다

<주석보다는 코드로 의도를 표현하라>

저자는 최대한 주석을 줄이라고 이야기한다

심지어 주석은 실패를 의미한다고 한다. 코드로 의도를 표현하는 데에 실패했다는 것이다