함수

작게 만들어라

함수를 만드는 첫 번째 규칙은 "작게" 이다.
두 번째 규칙은 "더 작게" 이다.

들여쓰기

대부분 while, for, if 문 내부에서 함수를 호출한다.
중첩 구조가 생길만큼 함수가 커지면 안된다. 들여쓰기 수준은 1단이나 2단을 넘어서면 안된다.

한가지만 해라

함수는 한 가지를 해야 한다. 그 한 가지를 잘 해야 한다.

함수 당 추상화 수준은 하나로

함수가 확실히 '한 가지' 작업만 하려면 함수 내 모든 문장의 추상화 수준이 동일해야 한다.

위에서 아래로 코드 읽기

코드는 위에서 아래로 이야기처럼 읽혀야 좋다.
한 함수 다음에는 추상화 수준이 한 단계 낮은 함수가 온다.

Switch 문

switch 문은 작게 만들기 어렵다.
다형성을 이용하여 저차원 클래스에 숨기고 반복하지 않는 방법은 있다. 다형성을 이용하는 것

위 함수는 길다.

새로운 EmployeeType을 추가하면 끝도 없이 길어진다.

문제를 해결하기 위해 switch 문을 추상 팩토리에 숨기고 아무에게도 보여주지 않는다.

팩토리는 switch를 사용해 Employee 파생 클래스의 인스턴스를 생성한다.

calculatePay, isPayday, deliverPay 등과 같은 함수는 Employee 인터페이스를 거쳐 호출된다.

자신의 기억력을 자랑하지 마라

자신이 항상 URL을 r이라는 변수에 사용했다면, 자신은 그것을 항상 기억하기 때문에 사용해도 괜찮다고 생각한다.
하지만 정말 능력자들은 자신의 능력을 좋은 방향으로 사용해 남들이 이해하는 코드를 내놓는다.

클래스 이름

명사나 명사구가 적합하다.
Customer, WikiPage, Account, AddressParse 등은 OK
Manager, Processor, Data, Info 등과 같은 단서 X

메서드 이름

동사나 동사구가 적합하다.
postPayment, deletePage, save OK
접근자, 변경자, 조건자는 접두어로 get, set, is 를 붙인다.

Complex fulcrumPoint = Complex.FromRealNumber(23.0); // 정적 팩토리 메소드
vs
Complex fulcrumPoint = new Complext(23.0); // 생성자

생성자를 오버로딩할 때는 정적 팩토리 메서드를 사용한다.

기발한 이름은 피하라

농담이나 유머감각이 비슷한 사람만 알 수 있는 명명을 피하라

한 개념에 한 단어를 사용하라

추상적인 개념 하나에 단어 하나를 선택해 이를 고수한다.

예를 들어, 같은 메서드를 클래스마다 fetch, retrieve, get 으로 제각각 부르면 혼란스럽다.

말장난을 하지마라

한 단어를 두 가지 목적으로 사용하지 마라.
앞선 '한 개념에 한 단어를 사용하라'와 조금은 충돌되는 부분이다.
모든 add 메서드의 매개변수와 반환값이 의미적으로 같으면 상관이 없다.
하지만 같은 맥락이 아닌데도 '일관성' 을 고려해 add라는 단어를 선택한다.
ex) 지금까지의 add메서드는 2개의 값을 더하거나 새로운 값을 만든다고 가정하자.
새로 작성하는 메서드는 집합에 값 하나를 추가한다.
이 메서드도 add라고 불러도 괜찮은가? -> insert나 append의 이름이 적합하지 않을까? -> 의미가 다르니

해법 영역에서 가져온 이름을 사용하라

코드를 읽을 사람도 프로그래머이다.
전산 용어, 프로그래머 용어, 알고리즘 이름, 패턴이름, 수학 용어 등을 사용해도 무방하다
ex) Visitor 패턴에 친숙한 프로그래머는 AccountVisitor라는 이름을 금방 알 것이다.
JobQueue, ReadyQueue를 모르는 프로그래머는 없을 것이다.

문제 영역에서 가져온 이름을 사용하라

적절한 프로그래머들의 용어가 없다면 문제 영역에서 이름을 가져온다.

의미있는 맥락을 추가하라

스스로 의미가 분명한 이름이 있다. 하지만 대부분의 이름은 그렇지 못하다
그래서 클래스, 함수, 이름 공간에 넣어 맥락을 부여한다.
firstName, lastName, street, houseNumber, city, state, zipcode라는 변수가 있다. 변수를 보면 "주소"라는 사실을 금방 알아챈다.

하지만 어느 메서드가 state라는 변수를 하나만 사용한다면? 해당 state가 주소의 state인지 상태인지 모를 것이다.
따라서 이럴 때는 접두어를 붙여서 맥락을 분명히 한다. addrState 처럼

마치며

좋은 이름을 선택하려면 설명 능력이 뛰어나야하고 문화적 배경이 같아야한다.
사람들이 이름을 바꾸지 않으려는 이유 중 하나는 다른 개발자가 반대할까 두려워서이다.
하지만 좋은 이름으로 바꾼다면 그것은 고마운 일이다. 따라서 개선하려는 노력을 중단해서는 안 된다.

(나쁜 코드가 프로젝트에 존재한다 -> 해독하느라 시간도 쓰이고 나쁜 코드를 위에 얹는다 -> 팀 생산성이 떨어진다 -> 관리층은 생산성 증가를 위해 새로운 인력을 추가한다 -> 새인력과 팀은 압력에 시달린다 -> 더 많은 나쁜 코드를 양산한다 ....)

재설계의 꿈

1. 팀이 반기를 든다. 더 이상 혐오스러운 코드로는 일을 못하겠다며 관리층에게 재설계를 요구한다.
2. 관리층은 재설계에 자원을 쏟아붓기는 싫지만, 생산성이 바닥이라는 사실을 부인할 순 없다.
3. 결국 재설계를 허락한다.
4. 새로운 팀 타이거가 구성된다. 모두가 타이거 팀에 합류하고 싶다. -> 처음부터 시작해 아름다운 코드를 지닌 작품을 창조할 기회니깐
5. 가장 유능하고 똑똑한 사람들만 차출된다. 나머지는 계속 현재 시스템을 유지보수하게 된다.
6. 두 팀은 경주를 시작한다. 타이거팀은 새 시스템을 내놓아야하며, 기존 시스템에 가해지는 변경 또한 따라잡아야 한다.
   • 기존 시스템을 100% 혹은 그 이상 제공해야 기존 시스템을 대체할 것이니
7. 해당 경주는 몇년 ~ 10년 이상이 소요될 수도 있다.

이러한 이야기를 한번이라도 겪었다면 시간을 들여 깨끗한 코드를 작성하려는 노력이 결국 비용을 절약하는 방법이라는 것을 인정할 수 밖에 없다.

태도

코드가 정말 엉망이라 몇 시간짜리 업무를 몇 주동안 진행하게 된 경험이 있는가?
코드 한 줄만 고치면 될 줄 알았는데, 수백개의 모듈을 건드린 경험이 있는가?
-> 많은 변명이 있다.

1. 일정이 촉박했다.
2. 요구사항이 너무 변했다. 설계에 반하는 요구사항이 많았다.
3. 멍청한 관리자와 조급한 고객과 쓸데없는 통화 탓 등등

하지만 전적으로 프로그래머의 잘못이란 것을 인정해야 한다.
관리자와 마케팅은 약속과 공약을 내걸며 '우리에게' 정보를 구한다.
정보를 요구하지 않더라도 '우리가' 적극적으로 정보를 제공해야 마땅하다.
사용자는 요구사항을 내놓으며 '우리에게' 현실성을 자문한다.
관리자는 일정을 잡으며 '우리에게' 도움을 청한다.
결국 우리(프로그래머)는 프로젝트 전부분에 대해 참여하고 관여한다. -> 따라서 프로젝트의 실패는 우리에게도 큰 책임이 있다.

일정을 설정/조율하는 관리자의 압박에 못이겨 어쩔 수 없이 나쁜 코드를 작성하게 되었다는 사람들도 있을 것이다.
BUT, 관리자 또한 일정에 쫓기더라도 좋은 코드를 원한다.
그들의 업무는 일정과 요구사항을 밀어붙이는 것이다.
우리의 업무는 좋은 코드를 사수하는 것이다.
해당 두 업무가 어쩔 수 없이 상충한다. 당연한 것이다.

ex) 환자가 의사에게 수술 전에 손을 씻지 말라고 요구한다. 왜? 수술을 최대한 빨리 끝내고 싶어서.
BUT, 의사는 이를 거부한다. 감염의 위험은 의사가 더 잘 아니까, 해당 행동은 전문가답지 못하니까(물론 범죄)

원초적 난제

1~2년 이상 일을 한 프로그래머라면 누구나 나쁜 코드가 생산성을 늦춘다는 사실을 알게 된다.
그들은 기한을 맞추기 위해 나쁜 코드가 양산된다고 느낀다.

진짜 전문가들은 나쁜 코드를 양산하면 기한을 맞추지 못한다고 생각한다.
엉망진창인 상태로 인해 속도가 늦어지고, 결국 기한을 놓친다.

결국, 기한을 맞추는 유일한 방법은 코드를 항상 깨끗하게 유지하는 것이다.

깨끗한 코드라는 예술?

깨끗한 코드가 중요하다는 것은 이제 알겠다. 그렇다면 어떻게 작성해야하나?
-> 깨끗한 코드가 무엇인지 모르면 애써봤자 무쓸모다.

나쁜 코드와 깨끗한 코드를 구분하는 능력이 있다고해서 깨끗한 코드를 작성할 줄 아는 것은 아니다.

장인 정신을 익히기 위해서는 2단계가 필요하다.

1. 이론
2. 실전

이론 : 필요한 원칠, 패턴, 기법, 경험이라는 지식을 습득해야 한다.

실전 : 열심히 일하고 연습하여 지식을 나의 것으로 만든다.

ex) 자전거 타기 : 물리적인 식을 통해 자전거를 '처음타는 사람도 자전거를 탈 수 있다' 라는 식은 설명이 가능하다.
해당 식을 증명하면 그 사람은 자전거를 탈 수 있다는 것이 된다.

하지만 자전거를 처음 타는 사람은 100%(내 생각은 99%, 안넘어지는 사람도 있긴 있다...) 넘어진다.

깨끗한 코드를 작성하는 방법은 배우기 어렵다.
이론적으로 모든 것을 안다고 해서 깨끗한 코드가 나오기는 어렵다. 고생을 해야 한다.

책 자체는 3부분으로 나뉜다.

1. 깨끗한 코드를 작성하는 원칙, 패턴, 실기를 설명
2. 사례 연구를 알아보며 코드 복잡도가 증가한다. -> 코드를 깨끗하게 고치는 연습
3. 수집한 휴리스틱을 마지막 장에서 열거한다.