클린코드 : 1장 - 깨끗한 코드

1_ 깨끗한 코드

책을 읽는 이유

1. 프로그래머라서
2. 더 나은 프로그래머가 되려고

코드가 존재하리라

코드가 사라질 가망은 전혀 없다.

• 코드는 요구사항을 상세히 표현하는 수단이니까
• 어느 수준에 이르면 코드의 도움 없이 요구사항을 상세하게 표현하기란 불가능
• 추상화도 불가능
• 기계가 실행할 정도로 상세하게 요구사항을 명시하는 작업이 프로그래밍이다. 그것의 결과가 바로 코드
• 궁극적으로 코드는 요구사항을 표현하는 언어

나쁜 코드로 치르는 대가

나쁜 코드가 쌓일수록 팀 생산성은 떨어진다. 0에 수렴한다.
재설계를 요청해도 일정을 맞추기 위해 결국은 나쁜 코드가 더 쌓이게 된다.

원초적 난제

빨리가는 유일한 방법은, 언제나 코드를 최대한 깨끗하게 유지하는 습관이다.

깨끗한 코드라는 예술

깨끗한 코드를 구현하는 행위는 그림을 그리는 행위와 비슷
깨긋한 코드를 작성하려면 ‘청결’ 이라는 힘겹게 습득한 감각을 활용해 자잘한 기법들을 적용하는 절제와 규율이 필요

비야네 스트롭스트룹 (Bjarne Stroustrup) - C 창시자 (The C Programming Language 저자)

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

그래디 부치 (Grady Booch) - Object Oriented Analysis and Design with Application

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

데이브 토마스(Dave Thomas) - OTI 창립자이자 이클립스 전략의 대부

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

마이클 페더스 (Working Effectively with Lagacy Code 저자)

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

론 제프리스 (Ron Jeffries) - Extream Programming Installed & Extrem Programming Adventure in C# 저자

나는 켄트 백이 제안한 단순한 코드 규칙으로 구현을 시작한다. 중요한 순으로 나열하자면 간단한 코드는
- 모든 테스트를 통과한다.
- 중복이 없다.
- 시스템 내 모든 설계 아이디어를 표현한다.
- 클래스, 메서드, 함수 등을 최대한 줄인다.

워드 커닝햄(Ward Cunningham) - 위키, Extreme Programming 창시자, 디자인 패턴을 뒤에서 움직이는 전문가, 스몰토그와 객체지향의 정신적 지도자

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

보이스카우트 규칙

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

프리퀼과 원칙

Agile Software Development : Prin-ciples, Patterns, and Practices 의 프리퀼이다. PPP책은 객체지향설계의 원칙을 설명하고 전문 개발자들이 사용하는 실무 기법을 소개한다. PPP를 읽지 않았다면 이 책을 먼저 읽은 후 나중에 읽기를 바란다. PPP는 이 책에서 하는 이야기를 이어간다.

이 책에서는 다양한 설계 원칙을 산발적으로 거론한다.

• SRP (Single Responsibility Principle)
• OCP (Open Closed Principle)
• DIP (Dependency Inversion Principle)