잘못알고 있는 말들이나 지식들을 정리(?)
주석
부적절한 정보
- 다른 시스템(소스 관리 시스템, 버그 추적 시스템, 이슈 추적 시스템 등)에 저장할 정보는 주석으로 적절하지 못하다.
- 예를 들어
- 변경 이력은 장황한 날짜와 따분한 내용으로 소스코드를 번잡하게 만든다.
쓸모 없는 주석
오래된 주석, 엉뚱한 주석, 잘못된 주석은 더 이상 필요가 없다.
주석은 빨리 낡는다. 금방 필요없어질 주석은 달지 않는 편이 좋다.
중복된 주석
코드만으로도 충분한데 구구절절 설명하는 주석
i++; // i 증가
성의없는 주석
필요한 주석은 잘 작성되어야 한다.
주석에도 시간을 들여 멋지게 작성해야 한다.
단어를 신중하게 선택한다. 당연한 소리를 반복하지 않고 간결하고 명료하게 작성한다.
주석처리된 코드
코드를 읽다가 주석처리된 코드가 나오면 불편하다.
중요한 코드인지, 필요없는 코드인지 알 길이 없다.
하지만 아무도 삭제할 수 없다. 누군가에게는 필요한 코드일수도 있으니
따라서 해당 코드는 매일매일 낡아간다.
시간이 지나면서 주석처리된 코드 내에 사용된 변수/함수 등의 이름은 바뀌지만 주석코드를 수정하지는 않는다.
주석처리된 코드는 지워라. 필요한 사람이 이전버전을 확인할테니
환경
여러 단계로 빌드해야 한다
빌드는 간단히 한 단계로 끝나야 한다.
여러 단계로 테스트해야 한다
모든 단위 테스트는 한 명령으로 돌려야한다.
IDE에서 버튼 하나로 모든 테스트를 돌린다면 가장 이상적이다.
함수
너무 많은 인수
함수에서 파라미터의 개수는 적을수록 좋다.
출력 인수
Swift에서는 Stored Property를 사용하는 것이 좋을 듯
플래그 인수
Boolean 인수는 함수가 여러 기능을 수행한다는 명백한 증거이다.
죽은 함수
아무도 호출하지 않는 함수는 삭제한다.
주석처리된 코드랑 같은 느낌
일반
한 소스 파일에 여러 언어를 사용한다
오늘날 프로그래밍 환경은 한 소스 파일에서 다양한 언어를 지원한다.
자바 소스 파일 내에 HTML, JS 등을 포함한다.
이상적으로는 소스 파일 하나에 언어 하나만 사용하는 방식이 좋다.
당연한 동작을 구현하지 않는다
함수나 클래스는 '이름'과 연관된 혹은 당연하게 여길만한 동작을 해야 한다.
경계를 올바로 처리하지 않는다
코드는 올바로 동작해야 한다.
하지만 우리는 올바른 동작이 아주 복잡하다라는 말을 간과한다.
부지런함을 대신할 지름길은 없다.
모든 경계 조건, 구석진 곳, 예외는 우아하고 직관적인 알고리즘을 좌초시킬 암초다.
모든 조건들을 커버할 수 있는(커버리지 넓은) TC를 작성해서 테스트하라.
안전 절차 무시
예전 '체르노빌 원전 사고'는 책임자가 안전 절차를 무시하는 바람에 일어났다.
귀찮고 번거롭다는 이유로...
중복
이 책에서 나오는 가장 중요한 규칙 중 하나
DRY 법칙
- Don't Repeat Yourself
책에서 이 규칙은 "모든 테스트를 통과한다"는 규칙 다음으로 중요하다고 꼽았다.
코드에서 중복을 발견할 때마다 추상화할 기회로 간주하다.
중복된 코드를 하위 클래스로 분할하라.
이렇듯 추상화로 중복을 처리하면 설계 언어의 어휘가 늘어난다.
- 가장 뻔한 유형으로는 똑같은 코드가 여러 차례 나오는 중복이다.
Ctrl + C/V 처럼 보이는 코드이다.
- 여러 모듈에서 일련의 switch/case, if/else 문으로 똑같은 조건을 거듭 확인하는 중복이다.
이런 중복은 다형성으로 대체해야 한다.
- 알고리즘이 유사하나 코드가 서로 다른 중복이다.
중복은 중복이므로 템플릿 메소드 패턴이나 전략 패턴으로 제거한다.
최근에 나온 디자인 패턴의 대다수는 중복을 제거하기 위한 방법이다
추상화 수준이 올바르지 못하다
추상화는 저차원 상세 개념에서 고차원 일반 개념을 분리한다.
추상화로 개념을 분리할 때는 철저해야 한다.
예를 들어, 세부 구현과 관련한 상수, 변수, 유틸리티 함수는 기초 클래스에 넣으면 안된다.
기초 클래스는 구현 정보에 무지(알고 있지 않는 것이)해야 마땅하다.
EX
public interface Stack{
Object pop() throws EmptyException;
void push(Object o) throws FullException;
double percentFull();
class EmptyException extends Exception{}
class FullException extends Exception{}
}
percentFull() 은 추상화 수준이 올바르지 못하다
Stack을 구현하는 방법은 다양하다.
기초 클래스가 파생 클래스에 의존한다.
개념을 기초 클래스와 파생 클래스로 나누는 이유는 독립성을 보장하기 위해서다.
일반적으로 기초 클래스는 파생 클래스를 몰라야 마땅하다.
과도한 정보
잘 정의된 모듈은 인터페이스가 아주 작다. 하지만 작은 인터페이스로도 많은 동작이 가능하다.
잘 정의된 인터페이스는 많은 함수를 제공하지 않는다. -> 결합도가 낮다.
부실하게 정의된 인터페이스는 많은 함수를 제공한다. -> 결합도가 높다.
클래스는 제공하는 메서드가 작을수록 좋다.
함수는 알고 있는 변수 수도 작을수록 좋다.
자료, 유틸리티 함수, 상수, 임시 변수를 숨겨라
죽은 코드
죽은 코드란 실행되지 않는 코드이다.
불가능한 조건을 확인하는 if / throw 문이 없는 try 문에서 catch 블록
해당 코드는 제거하라
수직 분리
변수와 함수는 사용되는 위치에 가깝게 정의한다.
지역 변수는 처음으로 사용하기 직전에 선언하며 수직으로 가까운 곳에 위치해야 한다.
선언한 위치로부터 몇백줄 아래에서 사용되면 안된다.
일관성 부족
어떤 개념을 특정 방식으로 구현했다면 유사한 개념도 같은 방식으로 구현하라.
착실하게 적용한다면 간단한 일괄성만으로도 코드를 읽고 수정하기 쉬워진다.
잡동사니
비어 있는 기본 생성자가 왜 필요한가?
아무도 사용하지 않는 변수, 호출되지 않는 함수, 정보를 제공하지 않는 주석 등
제거하라
인위적 결합
서로 무관한 개념을 인위적으로 결합하지 않는다.
일반적으로 enum은 특정 클래스에 속할 이유가 없다.
enum이 클래스에 속한다면 enum을 사용하는 코드가 특정 클래스를 알아야만 한다.
범용 static 함수도 마찬가지이다.
편한 곳에 두지 않고, 필요한 곳에 시간을 들여 놓아라
기능 욕심
'마틴 파울러'가 말하는 코드 냄새 중 하나이다.
클래스 메서드는 자기 클래스의 변수와 함수에 관심을 가져야지 다른 클래스의 변수와 함수에 관심을 가져서는 안된다.
메서드가 다른 객체의 참조자와 변경자를 사용해 그 객체 내용을 조작한다면 메서드가 그 객체 클래스의 범위를 욕심내는 것이다.
EX
public class HourlyPayCalculator{
public Money calculateWeeklyPay(HourlyEmployee e){
int tenthRate = e.getTenthRate().getPennies();
int tenthsWorked = e.getTenthsWorked();
...
return new Money(straightPay + overtimePay);
}
}
calculateWeeklyPay 메서드는 HourlyEmployee 객체에서 온갖 정보를 가져 온다.
즉, calculateWeeklyPay 메서드는 자신의 클래스인 HourlyPayCalculator 범위를 넘어 선다.
EX
public class HourlyPayCalculator{
private HourlyEmployee employee;
//생성자(){
this.employee = e;
}
String reportHoues(){
return String.format("Name : %s.....", employee.getName(), employee.getTenthWorked()/10...)
}
}
해당 reportHours() 역시 HourlyEmployee 클래스를 욕심낸다. 하지만 HourlyEmployee 클래스가 리포트 형식을 알 필요는 없다.
함수를 HourlyEmployee 클래스로 옮기면 OOP의 여러 원칙을 위반한다.
따라서 이와 같은 예외 케이스에는 다른 클래스를 욕심내는 상황이 있을 수 있다.
선택자 인수
함수 호출 끝에 달리는 false 인수만큼이나 밉살 스런 코드도 없다.
예) 초과 근무 수당은 1.5배로 계산해야 하는 메소드 내에서
public int calculateWeeklyPay(boolean overtime){
...
double overtimeRate = overtime ? 1.5 : 1.0 * tenthRate;
...
}
-> straightPay(), overTImePay(), overTimeBonus() ... 로 쪼개는 것이 낫다.
enum, int, boolean 등의 인수로 함수의 동작을 제어하는 것은 바람직하지 않다.
모호한 의도
코드를 짤 때는 의도를 분명히 밝힌다.
잘못 지운 책임
개발자가 내리는 가장 중요한 결정 중 하나가 코드를 배치하는 위치다.
예) PI 상수는 어디에 들어갈까? -> 삼각함수를 선언한 클래스에 넣어야 한다.
부적절한 static 함수
Math.max(a, b)는 좋은 static 메서드다.
특정 인스턴스와 관련된 기능이 아니다.
new Math().max(a, b)나 a.max(b) 같은 형태가 오히려 더 우습다.
EX
HourlyPayCalculator.calculatePay(employee, overtimeRate);
언뜻 보면 static 함수로 여겨도 적당하다. 특정 객체와 관련이 없으면서 모든 정보를 인수에서 가져오니까
하지만 함수를 재정의할 가능성이 존재한다.
수당을 계산하는 알고리즘이 여러 개일지도 모른다.
OverTimeHourlyPayCalculator 와 StraightTimeHourlyPayCalculator 로 분리하고 싶을지도 모른다.
따라서 해당 메서드는 static이 아닌 인스턴스 메서드가 적절하다.
서술적 변수
프로그램 가독성을 높이는 가장 효과적인 방법 중 하나가 계산을 여러 단계로 나누고 중간 값으로 서술적인 변수 이름을 사용하는 방법이다.
이름과 기능이 일치하는 함수
Date newDate = date.add(5);
해당 코드는 5일, 5시간, 5주 등 어떻게 변경하는 함수인지 알 수가 없다.
또한, 있던 date객체를 변경하는 것인지 새로운 Date객체를 반환하는 것인지 알 수가 없다.
5일을 더하여 변경하는 함수라면 addDaysTo()
5일을 더하여 새 Date 객체를 반환하는 함수라면 daysLater() 가 적당하다.
알고리즘을 이해하라
대다수 괴상한 코드는 사람들이 알고리즘을 충분히 이해하지 않은 채 코드를 구현한 탓이다.
잠시 멈추고 실제 알고리즘을 고민하는 대신, 여기저기 if문과 print를 사용하여 코드를 돌리는 탓이다.
알고리즘을 다 안다고 하지만 실제는 코드가 '돌아갈' 때까지 이리저리 찔러본다.
논리적 의존성을 물리적으로 드러내라
한 모듈이 다른 모듈에 의존한다면 물리적인 의존성도 있어야 한다. 논리적 의존성만으로는 부족하다.
If/Else, Switch/Case 보다는 다형성을 사용하라
3장에서 새 유형을 추가할 확률보다 새 함수를 추가할 확률이 높은 코드에서는 switch가 적합하다 주장했다.
- 대다수 개발자가 switch 문을 사용하는 이유는 그 상황에서 가장 올바른 선택이기보다는 쉬운 선택이기 때문
- 유형보다 함수가 더 쉽게 변하는 경우는 극히 드물다.
표준 표기법을 따르라
팀은 구현 표준을 따라야 한다.
인스턴스 변수 이름을 선언하는 위치, 클래스/메서드/변수 이름 명명 방법 등을 명시해야 한다.
매직 숫자는 명명된 상수로 교체하라
SECONDS_PER_DAY 는 86,400이다.
하지만 TWO, WORK_HOURS_PER_DAY 같은 상수가 필요할 까?
확실히 TWO는 필요가 없다. 현재 법정 근무 시간이 8시간 이지만 바뀔수도 있으니 WORK_HOURS_PER_DAY는 필요할수도 있다.
정확하라
관례보다 구조를 사용하라
설계 결정을 강제할 때는 규칙보다 관례를 사용한다.
예를 들어, enum 변수가 멋진 ㄴwitch/case 문보다 추상 메서드가 있는 기초 클래스가 더 좋다.
조건을 캡슐화하라
부울 논리는 이해하기 어렵다.
조건의 의도를 분명히 밝히는 함수로 표현하라
if(shouldVeDeleted(timer)) 라는 코드는 아래의 코드보다 좋다
if(timer.hasEcpired() && !timer.isRecurrent())
부정 조건을 피하라
부정 조건은 긍정 조겅보다 이해하기 어렵다.
if(buffer.shouldCompact()) 가 아래 코드보다 좋다.
if(!buffer.shouldNotCompact())
함수는 한 가지만 해야 한다.
함수를 짜다보면 한 함수 안에 여러 단락을 이어, 일련의 작업을 수행하고픈 유혹에 빠진다.
EX
public void pay(){
for (Employee e : employees){
if(e.isPayday()){
Money pay = e.calculatePay();
e.deliverPay(pay);
}
}
}
위의 함수는 3가지 임루를 수행한다.
- 직원 목록을 루프로 돌며
- 각 직원의 월급일을 확인
- 해당 직원에게 월급을 지급
public void pay(){
for(Employee e: employees){
payIfNecessary(e);
}
}
private void payIfNecessary(Employee e){
if (e.isPayday()){
calculateAndDeliverPay(e);
}
}
private void calculateAndDeliverPay(Employee e){
Money pay = e.calculatePay();
e.deliverPay(pay);
}
숨겨진 시각적인 결합
때로는 시간적인 결합이 필요하다. 시간적인 결합을 숨기면 안된다.
public void dive(String reason){
saturateGradient();
reticulateSplines();
diveForMoog(reason);
}
보다는
public void dive(String reason){
Gradient gradient = saturateGradient();
List< Spline > splines = reticulateSplines(gradient);
diveForMoog(splines, reason);
}
가 더 좋다.
함수가 복잡해지기 하지만 시간적인 결합을 명백히 드러내어 수정을 방지하는 역할을 한다.
일관성을 유지하라
코드 구조를 잡을 때는 이유를 고민하라.
그 이유를 코드 구조로 명백히 표현하라.
구조에 일관성이 없어 보인다면, 다른 사람들이 맘대로 바꿔도 된다고 생각한다.
경계 조건을 캡슐화하라
경계 조건은 빼먹거나 놓치기 십상이다. 경계 조건은 한 곳에서 별도로 처리한다.
코드 여기저기에서 처리하지 않는다.
if(level + 1 < tags.length){
parts = new Parse(level + 1);
}
보다는
int nextLevel = level + 1;
을 사용해야 한다.
함수는 추상화 수준을 한 단계만 내려가야 한다
함수 내 모든 문장을 추상화 수준이 동일해야 한다.
그 추상화 수준은 함수 이름이 의미하는 작업보다 한 단계만 낮아야 한다.
설정 정보는 최상위 단계에 둬라
추상화 최상위 단계에 둬야 할 기본값 상수나 설정 관련 상수를 저차원 함수에 숨겨서는 안된다.
대신 고차원 함수에서 저차원 함수를 호출할 때, 인수로 넘긴다.
추이적 탐색을 피하라
일반적으로 한 모듈은 주변 모듈을 모를수록 좋다.
A가 B를 사용하고 B가 C를 사용한다 하더라도 A가 C를 알 필요는 없다.
이를 디미터의 법칙이라 부른다.
내가 아는 모듈이 연이어 자신이 아는 모듈을 따라가며 시스템 전체를 휘저을 필요가 없다는 의미이다.
여러 모듈에서 a.getB().getC() 라는 형태를 사용한다면 설계와 아키텍처를 바꿔 B와 C사이에 Q를 넣기가 어렵다.