클린 코드 독서일지 - Day 41

G26: 정확하라

코드에서 뭔가를 결정할 때는 정확히 결정하고, 결정을 내리는 이유와 예외를 처리할 방법을 분명히 알아야 한다.
-> 모호성과 부정확은 제거해야 함

G27: 관례보다 구조를 사용하라

설계 결정을 강제할 때는 규칙보다 관례를 사용한다. 명명 관례도 좋지만 구조 자체로 강제하면 더 좋다.
ex) switch/case 문보다 추상 메서드가 있는 기초 클래스가 더 좋다.

G28: 조건을 캡슐화하라

부울 논리는 이해하기 어려우므로 조건의 의도를 분명히 밝히는 함수로 표현하라.
ex) if(timer.hasExpired() && !timer.isRecurrent()) -> if(shouldBeDeleted(timer))로 변경

G29: 부정 조건은 피하라

부정 조건은 긍정 조건보다 이해하기 어려우므로 가능하면 긍정 조건으로 표현한다.
ex) if(!buffer.shouldNotCompact()) -> if(buffer.shouldCompact())로 변경

G30: 함수는 한 가지만 해야 한다

함수 안에 여러 단락이 들어가며 여러 작업을 수행하게 된다면, 한 가지만 수행하는 작은 함수 여럿으로 나눠야 한다.

G31: 숨겨진 시간적인 결합

함수를 짤 때는 함수 인수를 적절히 배치해 함수가 호출되는 순서를 명백히 드러낸다.
ex)

//시간적 결합이 숨겨진 코드
satureGradient();
reticulateSplines();
diveForMoog(reason);

// 다음과 같이 변경
Gradient gradient = saturateGradient();
List<Spline> splines = retiiculateSplines(gradient);
diveForMoog(splines, reason);

각 함수가 내놓는 결과가 다음 함수에 필요하게끔 하면 순서를 바꿔 호출할 수 없으므로 시간적 결합을 드러낸다.

G32: 일관성을 유지하라

코드 구조를 잡을 때는 이유를 고민하고 명백히 표현하라.

G33: 경계 조건을 캡슐화하라

경계 조건은 한 곳에서 별도로 처리하고, 변수로 캡슐화하는 편이 좋다.

G34: 함수는 추상화 수준을 한 단계만 내려가야 한다.

함수 내 모든 문장은 추상화 수준이 동일해야 하며, 그 추상화 수준은 함수 이름이 의미하는 작업보다 한 단계만 낮아야 한다.

G35: 설정 정보는 최상위 단계에 둬라

추상화 최상위 단계에 둬야 할 기본값 상수나 설정 관련 상수를 저차원 함수에 숨겨서는 안 된다.
대신 고차원 함수에서 저차원 함수를 호출할 때 인수로 넘긴다.

설정 관련 상수를 최상위 단계에 둬야 변경하기가 쉽다.

G36: 추이적 탐색을 피하라

추이적 : x가 y와 관계가 있고 y가 z와 관계가 있으면, x가 z와 관계가 있는. 또는 그런 것.

 

일반적으로 한 모듈은 주변 모듈을 모를수록 좋다.
=> A가 B를 사용하고 B가 C를 사용한다 하더라도 A가 C를 알아야 할 필요는 없다. (디미터의 법칙, 부끄럼 타는 코드 작성)
ex) a.getB().getC()와 같은 형태는 좋지 않음 -> 설계와 아키텍처를 바꾸기 쉽지 않음
내가 사용하는 모듈이 내게 필요한 서비스를 모두 제공해야 하며, 원하는 메서드를 찾느라 객체 그래프를 따라 시스템을 탐색할 필요가 없어야 한다.