코드가 존재하리라

모호한 요구사항을 알아서 이해하고 완벽하게 실행하는 기계는 없으며 사람도 그러기 힘들다. 제대로 명시된 요구사항은 코드만큼 정형적이며 테스트 케이스로 사용할 수 있지만, 코드는 요구사항을 표현하고 나아가 정형 구조를 뽑아내는 정밀한 표현 방법이다. 코드의 정밀함은 요구사항을 명확히 표현하기 위해 반드시 필요하며 프로그래밍 언어의 추상화 수준이 높아진다고 해서 코드가 사라질 수 없는 근거가 된다.

나쁜 코드

잘 못 짜둔 나쁜 코드를 헤쳐나가는 고행(wading) 작업은 비즈니스를 통째로 좌초시킬 수 있다. 언젠가 다시 손보리라 다짐하지만 그 순간은 영원히 오지 않는다.

LeBlanc's Law states "Later equals never"

나쁜 코드로 치르는 대가

생산성

나쁜 코드가 쌓이다 보면 팀의 생산성은 계속 떨어져 0에 수렴한다. 생산성을 높이고자 시스템 설계를 제대로 알지 못하는 새 인력을 투입하면 심리적 압박 속에 더 나쁜 상황이 연출된다.

재설계

재설계를 위해서 소수의 엘리트로 구성된 타이거팀이 만드는 경우도 있다. 기존 시스템을 모두 제공하면서 그동안 발생하는 변경도 따라잡는 새 시스템을 만들기까지 아주 오랜 시간이 걸린다. 그 기간 동안 타이거팀 인력은 계속 교체되고 결국 타이거팀이 만든 시스템도 또다른 레거시가 된다.

태도

납기일, 무리한 요구사항, 사내 압박 등 여러 요인에 의해 나쁜 코드가 만들어진다. 프로그래머라면 나쁜 코드의 위험을 이해하지 못하는 관리자의 말을 그대로 따라서는 안 된다. 끝까지 좋은 코드를 사수하는 책임감이 필요하다. 그리고 좋은 코드를 유지하는 습관은 작업 속도를 빠르게 유지하고 기한을 맞출 수 있는 유일한 방법이기도 하다.

깨끗한 코드

깨끗한 코드를 작성하려면 청결 감각을 활용해 자잘한 기법을 적용하는 절제와 규율이 필요하다. 코드 감각이 없는 프로그래머도 깨끗하고 좋은 코드와 나쁜 코드를 구분할 수 있다. 그러나 그게 좋은 코드를 짜는 능력이 있다는 뜻은 아니다. 코드 감각이 있는 프로그래머는 나쁜 모듈을 보면 좋은 모듈로 개선할 방안을 떠올리고, 코드 감각으로 최고 방안을 선택한 후 여기서 거기까지 이동하는 경로를 계획한다.

격언

비야네 스트롭스트룹
나는 우아하고 효율적인 코드를 좋아한다. 논리가 간단해야 버그가 숨어들지 못한다. 의존성을 최대한 줄여야 유지보수가 쉬워진다. 오류는 명백한 전략에 의거해 철저히 처리한다. 성능을 최적으로 유지해야 사람들이 원칙 없는 최적화로 코드를 망치려는 유혹에 빠지지 않는다. 깨끗한 코드는 한 가지를 제대로 한다.

1. 효율적인 코드: 속도와 자원을 낭비하지 않는 코드
2. 깨진 창문: 나쁜 코드는 더 나쁜 코드를 유발한다.
3. 철저한 오류처리: 메모리 누수, 경쟁 상태, 일관성 없는 명명법처럼 세세한 사항까지 처리
4. 한 가지에 집중: 나쁜 코드는 너무 많은 일을 하려다가 목적이 흐려진다.

그래디 부치
깨끗한 코드는 단순하고 직접적이다. 깨끗한 코드는 잘 쓴 문장처럼 읽힌다. 깨끗한 코드는 결코 설계자의 의도를 숨기지 않는다. 오히려 명쾌한 추상화와 단순한 제어문으로 가득하다.

1. 코드는 추측이 아니라 사실에 기반해야 한다.
2. 코드는 반드시 필요한 내용만 담아야 한다.
3. 코드는 읽는 사람에게 프로그래머가 단호하다는 인상을 줘야 한다.

데이브 토마스
깨끗한 코드는 작성자가 아닌 사람도 읽기 쉽고 고치기 쉽다. 단위 테스트 케이스와 인수 테스트 케이스가 존재한다. 깨끗한 코드에는 의미 있는 이름이 붙는다. 특정 목적을 달성하는 방법은 여러 가지가 아니라 하나만 제공한다. 의존성은 최소이며 각 의존성을 명확히 정의한다. API는 명확하며 최소로 줄였다. 언어에 따라 필요한 모든 정보를 코드만으로 명확히 표현할 수 없기에 코드는 문학적으로 표현해야 마땅하다.

1. 깨끗한 코드란 다른 사람이 고치기 쉬운 코드다.
2. 테스트 케이스가 없는 코드는 깨끗한 코드가 아니다. (TDD 원칙)
3. 코드는 작을수록 좋다.
4. 코드는 인간이 읽기 좋도록 문학적이어야 한다.

마이클 페더스
깨끗한 코드의 특징은 많지만 그 중에서도 모두를 아우르는 특징이 하나 있다. 개끗한 코드는 언제나 누군가 주의 깊게 짰다는 느낌을 준다. 고치려고 살펴봐도 딱히 손 댈 곳이 없다. 작성자가 이미 모든 사항을 고려했으므로, 고칠 궁리를 하다보면 언제나 제자리로 돌아온다. 그리고는 누군가 남겨준 코드, 누군가 주의 깊게 짜놓은 작품에 감사를 느낀다.

1. 깨끗한 코드는 주의 깊게 작성한 코드다.
2. 누군가 시간을 들여 깔끔하고 단정하게 정리한 코드다.
3. 세세한 사항까지 꼼꼼하게 신경 쓴 코드다.

론 제프리스
간단한 코드는 모든 테스트를 통과하고, 중복이 없으며, 시스템 내 모든 설계 아이디어를 표현하고 클래스, 메서드, 함수 등을 최대한 줄인 코드다. (중략)

1. 중복을 피하라
2. 표현력을 신경써라 (의미 있는 이름, 메서드 추출 리팩토링을 통해 매서드 분류)
3. 초반부터 간단한 추상화 고려하기 (추상 메서드나 추상 클래스로 실제 구현을 감싸기)

워드 커닝햄
코드를 읽으면서 짐작했던 기능을 각 루틴이 그대로 수행한다면 깨끗한 코드라 불러도 되겠다. 코드가 그 문제를 풀기 위한 언어처럼 보인다며 아름다운 코드라 불러도 되겠다.

깨끗한 코드는 읽으면서 놀랄 일이 없어야 한다. 설계자가 코드를 어이 없을 정도로 단순하게 설계하면 읽는 사람은 종종 깨끗하다는 사실조차 인지하지 못 한다.

특정 언어를 신봉하는 광신자가 많은데 프로그램을 단순하게 보이도록 만드는 열쇠는 언어가 아니라 프로그래머다.

저자의 생각

책에서 주장하는 기법은 저자가 수십 년에 걸친 경험과 반복적인 시행착오로 습득한 교훈이다. 그 중 다수는 논쟁의 여지가 있다. 동의하지 않더라도 그러한 시각을 이해하고 존중하길 바란다.

프로그래머는 저자다

코드를 읽는 시간 대 코드를 짜는 시간 비율은 10:1을 넘는다. 새 코드를 짜면서 끊임 없이 기존 코드를 읽는다. 그러므로 어렵더라도 처음부터 읽기 쉬운 코드를 작성해야 한다.

보이스카우트 규칙 캠프장은 처음 왔을 때보다 더 깨끗하게 해놓고 떠나라.

시간이 지나도 언제나 깨끗하게 코드를 유지해야 하기 위해서 적극적으로 코드의 퇴보를 막아야 한다. 한꺼번에 많은 시간과 노력을 투자해 코드를 정리할 필요가 없다. 변수 이름 하나를 개선하고, 조금 긴 함수 하나를 분할하고, 약간의 중복을 제거하고, 복잡한 if 문 하나를 정리하면 충분하다.

저자의 다른 책 소개

클린 코드는 Agile Software Development: Principles, Patterns, and Practice (일명 PPP책)의 프리퀄이라고 한다. PPP책은 객체 지향 설계의 원칙을 설명하고 전문 개발자들이 사용하는 실무 기법을 소개하므로 클린 코드 이후에 읽어보는 것을 추천한다.

PPP에서 소개하는 객제 지향 설계의 다섯 가지 원칙은 클린 코드에서도 반복적으로 제시된다.

SRP(The Single Responsibility Principle) 단일 책임의 원칙
클래스에는 한 가지, 단 한가지 변경 이유만 존재해야 한다.
OCP(The Open Closed Principle) 개방 폐쇄의 원칙
클래스는 확장에 열려 있어야 하며 변경에 닫혀 있어야 한다.
LSP(The Liskov Substitution Principle) 리스코프의 치환 법칙
상속받은 클래스는 기초 클래스를 대체할 수 있어야 한다.
DIP(The Dependency Inversion Principle) 의존 역전의 법칙
추상화에 의존해야 하며, 구체화에 의존하면 안 된다.
ISP(The Interface Segregation Principle) 인터페이스 분리 원칙
클라이언트에 밀접하게 작게 쪼개진 인터페이스를 유지한다.