[클린코드] Chapter-1

나쁜 코드

Killer app 하나로 대박난 회사가 머지 않아 망한 일이 있었다. 그 원인은 나쁜 코드였다.
일정에 맞추기 위해 나쁜 코드들을 방치하고는 '나중에 고쳐야지'라고 생각한 경험이 다들 있을 것이다. 하지만
Later equals never - LeBlanc's law (나중은 절대 오지 않는다 - 르블랑의 법칙)

난장판을 품는 데에 드는 비용

초기에는 매우 빠른 속도로 진행되던 프로젝트가 1~2년 만에 달팽이처럼 느린 페이스로 진행되게 되는 것을 볼 수 있다.
나쁜 코드로 짠 프로그램에 가해지는 변경사항은 어느것 하나 사소하지 않다.
나쁜 코드가 쌓일 수록 그 팀의 생산성은 떨어지고 이윽고 0에 수렴한다.
관리팀은 인력을 추가하려 한다.
하지만 새 팀원은 구조를 이해하지 못한다.
거기다 그 팀은 '새 인력을 투입했으므로 생산성이 늘겠지'라는 압박을 받는다.
결과, 나쁜 코드는 더 쌓인다.

환상의 "장대한 재디자인"

팀은 봉기한다. 재디자인을 요구한다.
달갑지는 않지만 관리팀 또한 개발팀의 생산성이 바닥을 기는 것을 알고 있으므로 허가하게 된다.
새 tiger team이 setup되고 기존의 프로덕트의 스펙 + 새로운 기능을 맡게 된다. 기존의 팀원들은 기존의 코드를 유지보수하게 된다.
두 팀은 오래 동안 경쟁한다.
tiger team이 기존의 프로젝트를 거의 따라잡을 즈음, tiger team의 초기 맴버들은 대부분 새 맴버들로 교체되어 있다.
그리고 그들은 다시 재디자인을 요구한다...
깨끗한 코드는 효율적일 뿐 아니라 생존과 직결되는 문제이다.

마음가짐

한시간이면 될 변경을 1주일이 넘도록 보고 있다던지, 한줄만 바꾸면 될 문제를 가지고 수백개의 모듈을 건드린다던지 하는 증상은 흔하다.
왜 좋은 코드는 그렇게도 빠르게 나쁜 코드로 바뀌는 것일까?
초기와 다른 스펙, 스케쥴, 멍청한 매니저, 참을성 없는 고객, 쓸데없는 마케팅 인간들을 비난할 지도 모른다. 하지만 그건 우리 잘못이다.
대부분은 매니저들은 우리 생각보다 더 진실을 원하고 있다.
그들 또한 좋은 코드를 원한다. 그와 동시에 스케쥴 또한 지키고 싶어한다.
그와 마찬가지로, 좋은 코드를 지키는 것 또한 우리의 몫이다.

태고의 난제

더러운 코드는 생산성을 저하시킨다. 그와 동시에 개발자들은 기한을 맞추기 위해 더러운 코드를 짠다. 하지만, 더러운 코드를 만들어서는 절대 기한을 맞추지 못한다.
빨리 가기 위한 단 하나의 방법은 "최대한 깨끗한 코드를 항상 유지하는 것"이다.

Clean Code의 미학이란?

클린코드란 예술작품과 같다. 어떤 코드가 클린코드 인지 아닌지를 구분하는 것과 클린코드를 쓸 수 있는지는 다른 문제이다.
클린코드를 작성하려면 피를 토해가며 얻은 클린코드에 대한 감각을 사용해 무수하게 많은 작은 기술들을 적용해야 한다.

Clean Code란 무엇인가?

코드는 즐겁게 읽혀야 한다.

효율적인 코드라야 한다. 이는 성능적 측면 뿐만 아니라 나쁜 코드는 난장판을 더 키우기 때문이다.(깨진 유리창 이론) 1
에러 핸들링, 메모리 누수, 경쟁상태, 일관되지 않은 네이밍 등 디테일을 신경쓰라.
나쁜 코드는 여러가지 일을 하려고 한다. 나쁜 코드는 애매한 의도와 모호한 목적을 포함한다. 클린코드는 한 가지에 집중한다. 클린코드는 한 가지 일을 잘 한다.

클린코드는 하나의 잘 쓰여진 산문처럼 읽혀야 한다. 소설의 기승전결처럼 문제를 제시하고 명쾌한 해답을 제시해야 한다.

명백한 추상: 코드는 추측 대신 실제를 중시, 필요한 것만 포함하며 독자로 하여금 결단을 내렸다고 생각하게 해야 한다.
“Big” Dave Thomas, founder of OTI, godfather of the Eclipse strategy
다른 이가 수정하기 쉬워야 한다.
테스트를 해야 한다.
코드는 간결할 수록 좋다.(Smaller is better)
코드는 세련되어야 한다.
Michael Feathers, author of Working Effectively with Legacy Code
코드를 care하라.(주의, 관심을 가지고 작성하라)
Ron Jeffries, author of Extreme Programming Installed and Extreme Programming Adventures in C#

중복을 없애라

클래스/메서드는 한 가지 일만 하게 하라
메서드의 이름 등으로 코드가 하는 일을 명시하라
(메서드 등을) 일찍 추상화해서 프로젝트를 빠르게 진행할 수 있게 하라
Ward Cunningham, inventor of Wiki, inventor of Fit, coinventor of eXtreme Programming. Motive force behind Design Patterns. Smalltalk and OO thought leader. The godfather of all those who care about code.
읽고, 끄덕이고, 다음으로 넘어갈 수 있는 코드를 작성하라.
당신이 사용하는 언어를 탓하지 말라. 코드를 아름답게 만드는 것은 프로그래머이다.

보이스카우트 규칙

시간이 지날 수록 더러워지는 코드를 본 적이 있을 것이다. 미국 보이스카우트에는 이러한 상황에 사용할 수 있는 단순한 규칙이 하나 있다.

항상 이전보다 개선해라

우리가 본 코드를 그 순간보다 조금만 더 개선한다면 코드는 더러워질 수가 없다. 거창하게 생각할 필요는 없다. 변수의 명명, 너무 긴 코드의 분할, 작은 중복의 제거, 복합 if문 하나의 개선 정도만 해 보라.