CleanCode 1장 깨끗한 코드

1. 코드가 존재하리라

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

• 언어는 요구사항에 가깝게한다
• 요구사항에서 정형구조를 뽑아낸다.

코드의 도움 없이 요구사항을 상세히 표현하기는 불가능하다 : 코드는 정밀한 표현이다.
고도로 추상화된 언어나 특정 응용 분야 언어로 기술하는 명세도 코드이다.

프로그래밍 언어에서 추상화 수준은 점차 높아질 것이다.

 

2. 나쁜 코드

우리 모두는 좋은 코드가 중요하다는 사실을 안다.

회사가 망한 원인 -> 나쁜 코드

• 버그가 남아있고, 프로그램이 죽는 횟수가 늘어짐
• 출시에 바빠 코드를 마음대로 짜고, 기능을 추가할 수록 엉망이 되었다.

고행(wading) = 나쁜 코드를 헤쳐나간다

르블랑의 법칙(Leblanc's Law) = 나중은 결코 오지 않는다.

• 나중에 손보겠다고 한 코드 + 돌아간다는 사실에 안도감을 느끼며 위로함 -> 고치지 않는다.
• 짤 때부터 클린하게 잘 짜보자

 

3. 나쁜 코드로 치르는 대가

개발속도를 크게 떨어뜨린다.
나쁜 속도가 쌓일수록 팀 생산성은 떨어진다. - 얽히고 설킨 코드를 '해독'하고 더한다.

 

3-1. 원대한 재설계의 꿈

깨끗한 코드를 만드는 노력이 비용을 절감할 뿐아니라 전문가로서 살아남는다.

원대한 재설계 : 타이거팀 - 기존 시스템 기능을 제공하는 새 시스템 + 새로운 변경 > (10년 지속) 이에 대한 새로운 재 설계도 나온다

 

3-2. 태도

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

나쁜코드로 전략한 실패 -> 잘못은 프로그래머 책임이다.
요구사항 변경, 일정 촉박, 관리자 고객 마케팅에 대한 불평 : 프로그래머가 프로젝트 계획을 실패한 것 (전문성의 요소였다)

 

3-3. 원초적 난제

기한을 맞추는 방법 = 빨리가는 방법 = 언제나 코드를 최대한 깨끗하게 유지하는 습관
나쁜코드가 업무 속도를 늦춤을 안다.
그럼에도 기한을 맞추려고 나쁜코드를 짠다 = 빨리가려고 시간을 들이지않는다.

 

3-4. 깨끗한 코드라는 예술

깨끗한 코드 = 코드감각 & 절제와 규율

'코드감각'이 있는 프로그래머 = 나쁜 모듈을 보면 좋은 모듈로 개선할 방안을 떠올린다.

 

3-5. 깨끗한 코드란?

a. 비야네 스트롭스트룹 (Biarne Stroustrup)

• '보기에 즐거운' 코드
• 나쁜코드는 나쁜코드를 '유혹'한다 = 나쁜 코드를 고치면서 오히려 더 나쁜 코드를 만든다.
  깨진 창문 ) 창문이 일단 깨지고 나면 쇠퇴하는 과정이 시작된다
• 세세한 사항까지 꼼꼼하게 처리해야한다. (세세한 오류처리)
  메모리 누수, 경쟁상태(race condition), 일관성 없는 명명법
• 한가지 목적에 '집중'한다

b. 그래디 부치 (Grady Booch)

• 가독성을 강조 = 깨끗한 코드가 잘 쓴 문장처럼 읽혀야한다.
• 코드는 추측이 아니라 사실에 기반해야한다. 필요한 내용만 담아야한다 (명쾌한 추상화)

 

c. '큰(big)' 데이브 토마스 (Dave Thomas)

• 깨끗한 코드란 다른 사람이 고치기 쉽다
• 아무리 코드가 우아하고, 가독성이 높아도, 테스트 케이스가 없으면 깨끗하지 않다.
• 큰 코드보다 작은 코드에 가치를 둔다.
• 코드가 '문학적'이어야한다 - 인간이 읽기 좋은 코드를 작성하라

 

d. 마이플 페더스 (Michael Feathres)

• 깨끗한 코드는 시간을 들여 깔금하고 단정하게 정리한 코드다 = 주의를 기울인 코드다.

 

e. 론 제프리스 (Ron Jeffries)

• 모든 테스트를 통과한다
• 중복이 없다.
• 시스템 내 모든 설계 아이디어를 표현한다.
• 클래스, 메서드, 함수 등을 최대한 줄인다.
  여러 객체로 나누기 : 한 객체가 여러 기능을 수행할 때
  메서드 추출 : 기능을 명확히 기술하는 메서드 하나 + 기능을 실제로 수행하는 메서드 여러개
• 집합에서 특정 항목을 찾는다 : 추상메서드나 추상클래스를 만들어 실제 구현을 감싼다

 

f. 워드 커닝햄 (Ward Cunningham)

• 읽으면서 짐작한 대로 돌아가는 코드가 깨끗한 코드다.
• 코드는 그 문제를 풀기위한 언어처럼 보일때 아름다운 코드다
  언어를 단순해 보이게 만드는 열쇠는 프로그래머
  

 

4. 우리들 생각 & 우리는 저자다

오브젝트 멘토 진영 [Robert C Martin] 이 생각하는 깨끗한 코드를 설명한다 : 깨끗한 변수 이름, 깨끗한 함수, 깨끗한 클래스

새 코드를 짜면서 우리는 끊임없이 기존 코드를 읽는다 [ 10 : 1 = 읽는 시간 : 짜는 시간 ]

읽기쉬운 코드가 매우 중요하다.

 

5. 보이스카우트 규칙

체크아웃할 때보다 좀 더 깨끗한 코드를 체크인 하자.
캠프장은 처음 왔을 때보다 더 깨끗하게 해놓고 떠나라

시간이 지날수록 코드가 좋아지는 프로젝트를 작업하자

 

6. 객체 지향 설계의 다섯가지 원칙

SRP (The Single Reponsibility Principle) : 단일 책임의 원칙
클래스에는 한 가지, 단 한 가지 변경 이유만 존재해야 한다.

OCP (The Open Closed Principle) : 개방 폐쇄의 원칙
클래스는 확장에 열려있어야하며, 변경에 닫혀있어야 한다.

LSP (The Liskov Substitution Principle) : 리스코프의 치환 법칙
상속받은 클래스는 기초 클래스를 대체할 수 있어야 한다.

DIP (The Dependency Inversion Principle) : 의존 역전의 법칙
추상화에 의존해야하며, 구체화에 의존하면 안된다.

ISP (The Interface Segregation Principle) : 인터페이스 분리 원칙
클라이언트에 밀접하게 작게 쪼개진 인터페이스를 유지한다.