클린 코드 (Clean Code)

이 책은 개발자 필독서인 것 같다...!! 👍

다양한 예제와 함께 설명을 해주시는데, 예제를 같이 쓰기는 너무 방대해서 간단히... 아주 간단히... 기억하고 싶은 것들 정리해보려고 한다 : ) 

 

이 포스팅은 거의 수박 겉핥기(?) 수준이다. 예제와 함께 책을 읽는 것을 강력히 추천한다 

 

이 책에서 말하는 것처럼 나도 프로그램을 풀어갈 이야기로 여기고, 코드를 신문기사처럼 작성해서 술술 잘 읽히는 코드를 짜고 싶다

그러기 위해서는 사소한 것 부터 노력해야겠다

( 한꺼번에 많은 시간과 노력을 투자해 코드를 정리할 필요가 없다. 변수 이름 하나를 개선하고, 조금 긴 함수 하나를 분할하고, 약간의 중복을 제거하고, 복잡한 if문 하나를 정리하면 충분하다 ) 

추천사

“사소한 곳에서 발휘하는 정직은 사소하지 않다”

그리고 작은 것에도 충실한 사람이 큰 것에도 충실하다 

 

사소한 것에 정직해야한다 

코드에 정직하고, 코드의 상태에 관하여 동료들에게 정직하고, 무엇보다도, 자기 코드에 대해서 자신에게 정직하라는 뜻이다 

 

읽기 좋은 코드는 돌아가는 코드만큼 중요하다 

첫 아이 이름을 짓듯이 심사숙고해서 변수이름을 지어야한다 (ㅎㅎ)

 

들어가면서

깨끗한 코드를 작성하는 방법은 배우기 어렵다 

단순히 원칙과 패턴을 안다고 깨끗한 코드가 나오지 않는다 고생을 해야한다 

스스로 연습하고 실패도 맛봐야한다 남들이 시도하다가 실패하는 모습도 봐야한다 그들이 넘어지고 일어서는 모습도 봐야한다 

결정을 내리느라 고민하는 모습, 잘못된 결정으로 대가를 치르는 모습도 봐야한다

 

이 책을 읽는 동안 마음 고생할 준비를 하기 바란다. 열심히, 아주 열심히 독파해야하는 책이다 

손으로 마음으로 익히길 바란다  

(꼭 구매해서 꼼꼼하게 읽으시길 추천합니당 🥰)

1장 깨끗한 코드

중복을 피하라, 한 기능만 수행하라, 제대로 표현하라, 작게 추상화하라

 

코드를 읽으면서 짐작한 대로 돌아가는 코드가 깨끗한 코드 

깨끗한 코드는 읽으면서 놀랄 일이 없어야한다 코드를 독해하느라 머리를 쥐어짤 필요가 없어야한다 

깨끗한 코드는 너무도 잘 짜놓은 코드라 읽는 이가 그 사실을 모르고 넘어간다 

모든 뛰어난 설계처럼 설계자가 코드를 어이 없을 정도로 단순하게 설계했기 때문이다 

 

한꺼번에 많은 시간과 노력을 투자해 코드를 정리할 필요가 없다. 변수 이름 하나를 개선하고, 조금 긴 함수 하나를 분할하고, 약간의 중복을 제거하고, 복잡한 if문 하나를 정리하면 충분하다 

 

2장 의미있는 이름

의도가 분명한 이름이 정말로 중요하다 

좋은 이름을 지으려면 시간이 걸리지만 좋은 이름으로 절약하는 시간이 훨씬 더 많다 

변수,함수,클래스 이름은 다음과 같은 굵직한 질문에 모두 답해야한다

존재 이유는?

수행 기능은?

사용 방법은?

따로 주석이 필요하다면 의도를 분명히 드러내지 못했다는 말이다 

 

3장 함수

함수를 만드는 첫째 규칙은 작게!, 둘째 규칙은 더 작게! 

함수는 한 가지를 해야한다. 그 한 가지를 잘 해야한다. 그 한 가지만을 해야한다. 

 

<위에서 아래로 코드읽기: 내려가기 규칙>

코드는 위에서 아래로 이야기처럼 읽혀야한다. 한 함수 다음에는 추상화 수준이 한 단계 낮은 함수가 온다. 즉, 위에서 아래로 프로그램을 읽으면 함수 추상화 수준이 한 번에 한 단계씩 낮아진다. 

 

대가 (master) 프로그래머는 시스템을 (구현할) 프로그램이 아니라 (풀어갈) 이야기로 여긴다 

 

4장 주석

주석이 필요하지 않도록 코드를 개선하는 편이 더 좋다 

 

5장 형식 맞추기

오늘 구현한 코드의 가독성은 앞으로 바뀔 코드의 품질에 지대한 영향을 미친다 

 

신문기사처럼 작성하라 

첫 문단은 전체 기사 내용을 요약한다. 세세한 사실은 숨기고 커다란 그림을 보여준다. 쭉 읽으며 내려가면 세세한 사실이 조금씩 드러난다. 

 

 

한 함수가 다른 함수를 호출한다면 두 함수는 세로로 가까이 배치한다. 또한 가능하다면 호출하는 함수를 호출되는 함수보다 먼저 배치한다. 그러면 프로그램이 자연스럽게 읽힌다 

 

9장 단위 테스트 

TDD는 실제 코드를 짜기 전에 단위테스트부터 짜라고 요구한다 

 

TDD법칙 세가지 

첫째, 실패하는 단위 테스트를 작성할 때 까지 실제 코드를 작성하지 않는다

둘째, 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다. 

셋째, 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다 

 

위 세 가지 규칙을 다르면 개발과 테스트가 대략 30초 주기로 묶인다. 테스트 코드와 실제 코드가 함께 나올 뿐더러 

테스트 코드가 실제 코드보다 불과 몇 초전에 나온다 

 

하지만 실제 코드와 맞먹을 정도로 방대한 테스트 코드는 심각한 관리 문제를 유발하기도 한다 

 

 

<테스트는 유연성, 유지보수성, 재사용성을 제공한다>

코드에 유연성, 유지보수성, 재사용성을 제공하는 버팀목이 바로 단위테스트다.

테스트 케이스가 있으면 변경이 두렵지 않기 때문이다

테스트 케이스가 없으면 모든 변경이 잠정적인 버그다 

 

테스트 케이스가 있으면 변경이 쉬워지기 때문이다 

 

<깨끗한 테스트 코드>

깨끗한 테스트 코드를 만들려면 세 가지가 필요하다. 가독성, 가독성, 가독성

어쩌면 가독성은 실제 코드보다 테스트 코드에 더더욱 중요하다

테스트 코드에서 가독성을 높이려면? 어느 코드와 마찬가지다. 명료성, 단순성, 풍부한 표현력이 필요하다 

 

가장 좋은 규칙은 "개념 당 assert문 수를 최소로 줄여라"(테스트 당 assert하나 인 것이 좋다 assert문이 단 하나인 함수는 결론이 하나라서 코드를 이해하기 쉽고 빠르다 ) 와 "테스트 함수 하나는 개념 하나만 테스트하라” 라 하겠다 

 

<F.I.R.S.T>

깨끗한 테스트 코드는 다음 다섯가지 규칙을 따른다

 

Fast (빠르게) - 테스트는 빨라야한다. 테스트는 빨리 돌아야한다. 테스트가 느리면 자주 돌릴 엄두를 못낸다

 

Independent (독립적으로) - 각 테스트는 서로 의존하면 안 된다 한 테스트가 다음테스트가 실행될 환경을 준비해서는 안된다 

각 테스트는 독립적으로 그리고 어떤 순서로 실행해도 괜찮아야한다 

 

Repeatable (반복적으로) - 테스트는 어떤 한경에서도 반복 가능해야한다 

 

Self-Validating (자가검증하는) - 테스트는 bool값으로 결과를 내야한다. 성공아니면 실패다 

 

Timely (적시에) - 테스트는 적시에 작성해야한다. 단위테스트는 테스트하려는 실제 코드를 구현하기 직전에 구현한다 실제 코드를 구현한 다음에 테스트 코드를 만들면 테스트가 불가능하도록 실제 코드를 설계 할지도 모른다 또한 어떤 코드는 테스트하기 너무 어렵다고 판명 날지 모른다 

 

 

테스트 코드가 방치되어 망가지면 실제 코드도 망가진다. 테스트 코드를 깨끗하게 유지하자 

 

10장 클래스

<클래스 체계>

가장 먼저 변수목록이 나온다. 정적 공개(static public) 상수가 있다면 맨 처음에 나온다. 다음으로 정적 비공개(private) 변수가 나오며, 이어서 비공개 인스턴스 변수가 나온다. 

변수목록 다음에는 공개 함수가 나온다. 비공개 함수는 자신을 호출하는 공개 함수 직후에 넣는다. 즉, 추상화 단계가 순차적으로 내려간다. 그래서 프로그램은 신문 기사 처럼 읽힌다 

 

클래스를 만들 때 첫 번째 규칙은 크기다. 클래스는 작아야한다. 두번째 규칙도 크기다. 더 작아야한다. 

 

그렇다면 가장 먼저 떠오르는 의문은 얼마나 작아야하는가? 겠다

함수는 물리적인 행 수로 크기를 측정했다. 클래스는 다른 척도를 사용한다. 클래스가 맡은 책임을 센다. 

 

실제로 작명은 클래스 크기를 줄이는 첫번째 관문이다. 간결한 이름이 떠오르지 않는다면 필경 클래스 크기가 너무 커서 그렇다. 클래스 이름이 모호하다면 필경 클래스 책임이 너무 많아서다. 

 

규모가 어느수준에 이르는 시스템은 논리가 많고도 복잡하다. 이런 복잡성을 다루려면 체계적인 정리가 필수다. 그래야 개발자가 무엇이 어디에 있는지 쉽게 찾는다.

 

큰 클래스 몇 개가 아니라 작은 클래스 여럿으로 이뤄진 시스템이 더 바람직하다. 작은 클래스는 각자 맡은 책임이 하나며, 변경할 이유가 하나며, 다른 작은 클래스와 협력해 시스템에 필요한 동작을 수행한다 

 

결합도가 낮다는 소리는 각 시스템 요소가 다른 요소로 부터 그리고 변경으로부터 잘 격리되어있다는 의미다.

시스템 요소가 서로 잘 격리되어있으면 각 요소를 이해하기도 더 쉬워진다