클린코드 1장 클린코드

일정에 맞추기 위해 나쁜 코드들을 방치하고는 '나중에 고쳐야지'라고 생각한 경험이 다들 있을 것이다. 하지만

Later equals never - LeBlanc's law (나중은 절대 오지 않는다 - 르블랑의 법칙)

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

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

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

 

Clean Code란 무엇인가?

Bjarne Stroustrup, inventor of C++ and author of The C++ Programming Language

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

Grady Booch, author of Object Oriented Analysis and Design with Applications

• 클린코드는 하나의 잘 쓰여진 산문처럼 읽혀야 한다. 소설의 기승전결처럼 문제를 제시하고 명쾌한 해답을 제시해야 한다.
  명백한 추상: 코드는 추측 대신 실제를 중시, 필요한 것만 포함하며 독자로 하여금 결단을 내렸다고 생각하게 해야 한다.

“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.

• 읽고, 끄덕이고, 다음으로 넘어갈 수 있는 코드를 작성하라.
• 당신이 사용하는 언어를 탓하지 말라. 코드를 아름답게 만드는 것은 프로그래머이다.

보이스카우트 규칙

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

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