1장 - 깨끗한 코드

깨끗한 코드의 정의는 프로그래머 수만큼이나 다양하다.

코드가 있을지어다

• 코드는 요구사항을 상세히 표현하는 수단이므로 앞으로 코드가 사라질 가망은 없다.
• 프로그래밍: 기계가 실행할 정도로 상세하게 요구사항을 명시하는 작업
• 코드: 명시한 결과

나쁜 코드

예시: Killer App을 구현한 회사가 있었다. 이전 버전에 있던 버그가 다음 버전에도 남아있었다. 출시에 바빠 코드를 마구 짠 나머지, 그 나쁜 코드 때문에 회사가 망했다.

우리는 대충 짠 코드가 돌아가는 것을 보며 나중에 손보겠다고 다짐한다. 그러나 나중은 절대 오지 않는다.

나쁜 코드로 치르는 대가

• 나쁜 코드는 개발 속도와 팀 생산성을 떨어뜨린다.
• 매번 얽히고설킨 코드를 '해독' 해서 얽히고설킨 코드를 더한다.

태도

• 변명들: 요구사항이 원래 설계를 뒤집는 방향으로 변했다 / 일정이 촉박해 시간이 없었다 / 멍청한 관리자와 조급한 고객 탓이다 등..
• 잘못은 전적으로 우리 프로그래머에게 있다. 우리에게 정보를 구하고, 요구사항의 현실성을 자문하고, 일정에 대한 도움을 청하기 때문이다.
• 따라서 좋은 코드를 사수하는 일은 바로 우리 프로그래머들의 책임이다. 나쁜 코드의 위험을 이해하지 못하는 관리자 말을 그대로 따르는 행동은 전문가답지 못하다.

원초적 난제

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

깨끗한 코드라는 예술?

깨끗한 코드를 어떻게 작성할까?

• 깨끗한 코드를 구현하는 행위 = 빈 캔버스를 그림으로 그려가는 행위
  • 깨끗한 코드와 나쁜 코드를 구분할 줄 안다고 깨끗한 코드를 작성할 줄 안다는 뜻은 아니다.
  • 열쇠는 코드 감각이다. 코드 감각을 통해 나쁜 코드와 좋은 코드를 구분하고, 나쁜 코드를 좋은 코드로 바꾸는 전략도 파악할 수 있다.
  • 어떤 사람은 코드 감각을 타고나지만, 어떤 사람은 투쟁해서 얻어야 한다.

깨끗한 코드란?

깨끗한 코드의 정의는 프로그래머 수만큼이나 다양하다.

✧ Bjarne Stroustru (inventor of C++ and author of The C++ Programming Language)

우아한(보는 이에게 즐거움을 선사하는)
효율적인(속도뿐만 아니라 CPU 자원을 낭비하지 않는) 코드

• 논리가 간단해 버그가 숨어들지 못하고, 의존성이 최소한이어서 유지보수가 쉬운 코드
• 나쁜 코드 = 깨진 창문¹
• 철저한 오류처리
  • 세세한 사항까지 꼼꼼하게 처리하는 코드
  • 메모리 누수, 경쟁 상태, 일관성 없는 명명법을 피할 것
• 한 가지에 집중하는 코드

✧ Grady Booch (author of Object Oriented Analysis and Design with Applications)

가독성 높은 코드

= 잘 쓴 문장처럼 읽힌다.
= 설계자의 의도가 바로 드러난다.
= 해결할 문제의 명백한 해법을 제시한다.

• 코드는 추측이 아니라 사실에 기반을 둬야 한다.
• 반드시 필요한 내용만 담는다.
• 코드를 통해 단호하다는 인상을 주어야 한다.

✧ “Big” Dave Thomas (founder of OTI, godfather of the Eclipse strategy

다른 사람이 고치기 쉬운 코드
문학적인 코드(인간이 읽기 좋은 코드)

• 단위 테스트 케이스와 인수 테스트 케이스가 있는 코드
• 최소: 작을수록 좋다. 큰 코드보다 작은 코드에 가치를 둔다.

✧ Michael Feathers (author of Working Effectively with Legacy Code)

주의 깊게 짠 코드

• 주의: 시간을 들여 깔끔하고 단정하게 정리, 세세한 사항까지 신경 쓴 코드
• 고치려고 살펴봐도 딱히 손댈 곳이 없다. 작성자가 이미 모든 사항을 고려했으므로.

✧ Ron Jeffries (author of Extreme Programming Installed and Extreme Programming Adventures in C#)

 깨끗한 코드는 다음과 같은 규칙으로 구현한다.

1. 모든 테스트를 통과한다
2. 중복이 없다
3. 시스템 내 모든 설계 아이디어를 표현한다
4. 클래스, 메서드, 함수 등을 최소화한다

• 중복을 줄인다. 중복은 코드가 아이디어를 제대로 표현하지 못한다는 증거다.
• 표현력 높이기:
  • 의미 있는 이름 사용하기
  • 분리하기
    • 객체가 여러 기능을 수행한다면 여러 객체로 나눈다
    • 메서드가 여러 기능을 수행한다면 나눈다
• 간단한 추상화 고려하기
  • 추상 메서드/클래스로 실제 구현을 감싼다
  • When? 어떤 집합에서 특정 항목을 찾아낼 필요가 있는 상황이 발생할 때

✧ Ward Cunningham (inventor of Wiki, inventor of Fit, co-inventor of extreme Programming. Motive force behind Design Patterns. Smalltalk and OO thought leader. The godfather of all those who care about code)

짐작했던 기능을 그대로 수행하는 코드
아름다운 코드

• 깨끗한 코드는 읽으면서 놀랄 일이 없어야 한다.
• 독해하느라 머리 쥐어짤 필요가 없는 명백단순한 코드. 모듈을 읽으면 다음에 벌어질 상황이 보인다.
• 아름다움: 코드가 그 문제를 풀기 위한 언어처럼 보여야 한다. 언어를 단순하게 보이게 하는 책임은 우리 프로그래머에게 있다

우리는 저자다

우리의 코드를 보고 판단을 내릴 독자가 있다는 사실을 기억해야 한다. 저자에게는 독자와 잘 소통할 책임이 있다.
새 코드를 짜면서 우리는 끊임없이 기존 코드를 읽는다. 기존 코드를 읽는 비율이 높으므로 읽기 쉬운 코드가 매우 중요하다. 주변 코드가 읽기 쉬우면 새 코드를 짜기도 쉽다. 그러므로 급하다면, 서둘러 끝내려면, 쉽게 짜라면, 읽기 쉽게 만들면 된다.

보이스카우트 규칙

잘 짠 코드가 전부는 아니다. 시간이 지나도 언제나 깨끗하게 유지해야 한다.

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

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

결론

이 책을 읽는다고 뛰어난 프로그래머가 되거나 코드 감각을 확실히 얻는다는 보장도 없다. 단지 뛰어난 프로그래머가 생각하는 방식과 그들이 생각하는 기술과 기교와 도구를 소개할 뿐이다. 나머지는 여러분에게 달렸다.