# 깨끗한 코드

### 📃 코드를 만드는 장인 정신

> 물건을 만드는 사람에게 장인 정신이 필요하듯, 코딩을 할 때도 개발자에게 필요한 마인드가 바로 장인 정신이다. 많은 시간과 노력이 필요할 것이다.

* 이론
  * 원칙
  * 패턴
  * 기법
* 실전
  * 열심히 연습한다.

### 📘 이 책으로 얻을 수 있는 것

이 책은 좋은 프로그램 작성 요령을 설명하는 책이고, 온통 코드들이다. 코드를 최대한 다양한 각도에서 살펴본다. 이 책을 읽고 나면 좋은 코드와 나쁜 코드를 구분하는 능력이 생긴다. 게다가 좋은 코드를 작성하는 방법도 익힌다. 마지막으로 나쁜 코드를 좋은 코드로 바꾸는 실력도 쌓인다.

### 📘 코드가 존재하리라

코드는 요구사항을 표현하는 언어다.

코드의 도움 없이 요구사항을 상세하게 표현하기란 불가능하다. 정확히 명시하는 수밖에 없다. 기계가 실행할 정도로 상세하게 요구사항을 명시하는 작업, 바로 이것이 프로그래밍이다. 이렇게 명시한 결과가 바로 코드다.

##

### 📘 나쁜 코드

> 나중은 결코 오지 않는다.

우리는 모두 자신이 짠 쓰레기 코드를 쳐다보며 나중에 손보겠다고 생각한 경험이 있다. 우리 모두는 대충 짠 프로그램이 돌아간다는 사실에 안도감을 느끼며 그래도 안 돌아가는 프로그램보다 돌아가는 쓰레기가 좋다고 스스로를 위로한 경험이 있다. 다시 돌아와 나중에 정리하겠다고 다짐했었다.

##

### 📘 나쁜 코드로 치르는 대가

> 시간을 들여 깨끗한 코드를 만드는 노력이 비용을 절감하는 방법일 뿐 아니라 전문가로서 살아남는 길이다.

**나쁜 코드는 개발 속도를 크게 떨어뜨린다.** 코드를 고칠 때마다 엉뚱한 곳에서 문제가 생긴다. 매번 얽히고 설킨 코드를 '해독'해서 얽히고 설킨 코드를 더한다. 시간이 지나면서 쓰레기 더미는 점점 높아진다.

나쁜 코드가 쌓일수록 팀 생산성은 떨어진다. 그러다가 마침내 0에 근접한다.

##

### 📘 태도

**좋은 코드를 사수하는 일은 바로 우리 프로그래머들의 책임이다.**

자신이 의사라 가정하자. 어느 환자가 수술 전에 손을 씻지 말라고 요구한다. 시간이 오래 걸리니까. 확실히 환자는 상사다. 하지만 의사는 단호하게 거부한다. 왜? 질병과 감염의 위험은 환자보다 의사가 더 잘 아니까. 환자 말을 그대로 따르는 행동은 전문가답지 못하다.

프로그래머도 마찬가지다. 나쁜 코드의 위험을 이해하지 못 하는 관리자 말을 그대로 따르는 행동은 전문가답지 못하다.

> 기한을 맞추며 빨리 가는 유일한 방법은, 언제나 코드를 최대한 깨끗하게 유지하는 습관이다.

##

### 📘 깨끗한 코드란?

* 깨끗한 코드는 보는 사람에게 즐거움을 선사해야 한다.
* 깨끗한 코드는 단순하고 직접적이다. 깨끗한 코드는 잘 쓴 문장처럼 읽힌다.
* 깨끗한 코드에는 의미있는 이름이 붙는다.
* 깨끗한 코드는 한 가지를 제대로 한다.
* 논리가 간단해야 버그가 숨어들지 못한다.
* 의존성을 최대한 줄여야 유지보수가 쉬워진다.
* 의존성은 최소이며 각 의존성을 명확히 정의한다.
* 오류는 명백한 전략에 의거해 철저히 처리한다.
* 성능을 최적으로 유지해야 사람들이 원칙 없는 최적화로 코드를 망치려는 유혹에 빠지지 않는다.
* 단위 테스트 케이스와 인수 테스트 케이스가 존재한다.
* 깨끗한 코드는 모든 테스트를 통과한다.
* 중복이 없다.
* 시스템 내 모든 설계 아이디어를 표현한다.클래스, 메서드, 함수 등은 최대한 줄인다.

> 테스트 케이스가 없는 코드는 깨끗한 코드가 아니다. 아무리 코드가 우아해도, 아무리 가독성이 높아도, 테스트 케이스가 없으면 깨끗하지 않다.

> 깨끗한 코드는 고치려고 살펴봐도 딱히 손 댈 곳이 없다. 작성자가 이미 모든 사항을 고려했으므로 고칠 궁리를 하다보면 언제나 제자리로 돌아온다.

> 깨끗한 코드는 코드를 독해하느라 머리를 쥐어짤 필요가 없어야 한다. 읽으면서 짐작한 대로 돌아가는 코드가 깨끗한 코드다. 모듈을 읽으면 다음에 벌어질 상황이 보인다.

> 새 코드를 짜면서 우리는 끊임없이 기존 코드를 읽는다. 따라서 읽기 쉬운 코드가 매우 중요하다. 주변 코드가 읽기 쉬우면 새 코드를 짜기도 쉽다.

> 여러 기능을 수행하는 객체나 메서드를 찾는다. 객체가 여러 기능을 수행한다면 여러 객체로 나눈다. 메서드가 여러 기능을 수행한다면 메서드 추출 리팩터링 기법을 적용해 기능을 명확히 기술하는 메서드 하나와 기능을 실제로 수행하는 메서드 여러 개로 나눈다.

> 어떤 집합에서 특정 항목을 찾아낼 필요가 자주 생긴다. 이런 상황이 발생하면 나는 추상 메서드나 추상 클래스를 만들어 실제 구현을 감싼다.

_**요약: 중복을 피하라. 한 기능만 수행하라. 제대로 표현하라. 작게 추상화 하라.**_

##

### 📘 우리는 저자다

우리는 저자다. 저자에겐 독자가 있다. 다음에 코드를 짤 때는 자신이 저자라는 사실을, 여러분의 노력을 보고 판단을 내릴 독자가 있다는 사실을 기억하기 바란다.

코드를 읽는 시간 대 코드를 짜는 시간 비율이 10대 1을 훌쩍 넘는다.

_**새 코드를 짜면서 우리는 끊임없이 기존 코드를 읽는다.**_ 비율이 이렇게 높으므로 읽기 쉬운 코드가 매우 중요하다. 기존 코드를 읽어야 새 코드를 짜므로 읽기 쉽게 만들면 사실은 짜기도 쉬워진다. 주변 코드가 읽기 쉬우면 새 코드를 짜기도 쉽다.

> 그러므로 급하다면, 서둘러 끝내려면, 쉽게 짜려면, 읽기 쉽게 만들면 된다.
>
> ###

### 📘 보이스카우트 규칙

> 캠프장은 처음 왔을 때보다 더 깨끗하게 해놓고 떠나라

체크아웃할 때보다 좀 더 깨끗한 코드를 체크인 한다면 코드는 절대 나빠지지 않는다. 한꺼번에 많은 시간과 노력을 투자해 코드를 정리할 필요가 없다. 변수 이름 하나를 개선하고, 조금 긴 함수 하나를 분할하고, 약간의 중복을 제거하고, 복잡한 if문 하나를 정리하면 충분하다.

##

### 📘 결론

이 책을 읽는다고 뛰어난 프로그래머가 된다는 보장은 없다. 단지 뛰어난 프로그래머가 생각하는 방식과 그들이 사용하는 기술과 기교와 도구를 소개할 뿐이다.

이 책은 세세한 정보로 가득하다. 코드도 많다. 좋은 코드도 소개하고 나쁜 코드도 소개한다. 나쁜 코드를 좋은 코드로 바꾸는 방법도 소개한다. 다양한 경험적 교훈과 체계와 절차와 기법도 열거한다. 예제도 무수히 많이 보여준다. 나머지는 여러분에게 달렸다.
