객체지향 생활 체조 9가지 원칙
('소트웍스 앤솔러지'라는 책)
규칙 1: 한 메서드에 오직 한 단계의 들여쓰기(indent)만 한다.
규칙 2: else 예약어를 쓰지 않는다.
규칙 3: 모든 원시값과 문자열을 포장한다.
규칙 4: 한 줄에 점을 하나만 찍는다.
규칙 5: 줄여쓰지 않는다(축약 금지).
규칙 6: 모든 엔티티를 작게 유지한다.
규칙 7: 3개 이상의 인스턴스 변수를 가진 클래스를 쓰지 않는다.
규칙 8: 일급 콜렉션을 쓴다.
규칙 9: 게터/세터/프로퍼티를 쓰지 않는다.
Clean Code
깨끗한 코드
1. 우아하고 효율적인 코드를 작성하자.
나쁜 코드는 나쁜 코드를 불러온다. (나쁜코드를 고치면서 더 나쁜코드를 작성한다.)
깨진 유리창 이론(broken windows theory)
-깨진 유리창 하나를 방치해두면 그 지점을 중심으로 범죄가 확산되기 시작한다는 이론
오류처리를 철저하게 하라.
⇒메모리 누수, 경쟁 상태(race condition), 일관성 없는 명명법
한 가지를 잘하는 코드를 작성하라.
⇒ 하나의 메소드에 여러가지 로직이 들어가는것은 좋지 않다.
2. 가독성이 좋은 코드를 작성하자.
깨끗한 코드는 잘 쓴 문장처럼 읽혀야 한다.
코드는 추측이 아닌 사실 기반으로 반드시 필요한 내용만 담아야 한다.
설계자의 의도를 한 눈에 볼 수 있도록 하자.
3. 다른 사람이 고치기 쉬운 코드를 작성하자.
의미가 있는 이름을 짓자.(메소드명)
의존성은 최소한으로 해 객체(메소드)간 결합도를 낮추자.
테스트케이스가 있는 코드를 작성하자.
4. 코드를 주의깊게 작성하라.
시간을 들여 깔끔하고 단정하게 정리해서 작성하라.
5. 중복이 없는 코드를 작성하라.
메서드가 여러 기능을 수행한다면 기능을 명확히 기술하는 메서드 하나와 기능을 실제로 수행하는 메소드 여러개라 분리하라.
중복을 피하라
한 기능만 수행하라
제대로 표현해라(가독성)
작게 추상화해라.
보이스카우트 규칙
캠프장은 처음 왔을 때보다 더 깨끗하게 해놓고 떠나라.
—로버트 스테펜슨 스미스 바덴-파웰이 스카우트에게 남긴 작별인사
한 번에 너무 많은 노력을 하기보다는 작은 것 하나씩 고쳐보자.
중복제거, 메소드 분리, 복잡한 if문 정리
6. 클래스명은 명사나 명사구
메소드명은 동사나 동사구
접근자(Accessor), 변경자(Mutator), 조건자(Predicate)는 값 앞에 get, set, is를 붙힌다.
7. 한 단어를 두 가지 목적으로 사용하지 마라.
: 일관성을 지킨다는 미명아래 add라는 단어를 기존에는 두 값을 더한 값을 반환하거나 기존의 값에 새로운 값을 더해서 쓰다가 새로 작성하는 add에서는 집합에 값을 추가하는기능으로 사용한다면 일관성을 깨트린다. 차라리 insert나 append가 적당하다.
함수
1. 작게 만들어라.
함수를 작게만들 수록 하나의 함수를 이해하는데 필요한 해석능력이 줄어든다.
들여쓰기 수준은 1~2단을 넘지 않도록 하라.
2. 한 가지만 해라.
함수는 한 가지를 해야 한다. 그 한 가지를 잘 해야 한다. 그 한 가지만을 해야 한다.
메소드로 분리할 수 있는 유의미한 코드가 있다면 한 가지만 하는 함수가 아니다.
3. 함수당 추상화 수준은 하나로 맞춰라.
//높은 추상화 수준
getHtml();
//중간 추상화 수준
String pagePathName = PathParser.render(pagepath);
//낮은 추상화 수준
pagePathName.append("\n");
Java하나의 함수에 추상화 수준이 다른 코드들이 뒤섞여있다면, 가독성이 떨어진다.
이렇게 근본 개념과 세부사항이 뒤섞이기 시작하면 다른 개발자들이 함수에 세부사항을 점점 더 추가한다.
위에서 아래로 코드읽기: 내려가기 규칙
코드는 위에서 아래로 이야기처럼 읽혀야 좋다.
위에서 아래로 프로그램을 읽으면 함수 추상화 수준이 계속해서 한 단계씩 낮아지는 것을 내려가기 규칙이라 부른다.
4. 서술적인 이름을 사용하라.
: 이름이 길어진다고 걱정하지않아도 된다. 길고 서술적인 이름이 짧고 어려운 이름보다 좋다.
길고 서술적인 이름이 길고 서술적인 주석보다 좋다.
5. 함수 인수는 적을수록 좋다.
인수는 정말 '특별한' 이유가 없는한 3개 를 넘기지 않도록 하자.
6. 오류 코드보다 예외를 사용하라!
오류 코드로 반환을 하게되면 그에 대한 처리로직을 따로 조건문을 통해 처리해줘야 하는데, 이는 코드의 indent를 증가시킬 뿐 아니라 오류를 바로 처리해야한다는 문제가 생긴다.
그렇기에 오류코드를 사용하기보다는 예외를 사용하면 try/catch를 통해 catch에서 관리할 수 있다.
외부 API를 사용할 때는 감싸기 기법이 최선이다. 외부 API를 감싸면 외부 라이브러리와 프로그램 사이에서 의존성이 크게 줄어든다.
오류 처리
1. 정상 흐름을 정의하라.
예외가 발생하는 특수상황자체가 없도록 구현을 하자.
try {
MealExpenses expenses = expenseReportDAO.getMeals(employee.getID());
m_total += expenses.getTotal();
} catch (MealExpensesNotFound e) {
m_total += getMealPerDiem();
}위와 같이 getMeals 메소드에서 예외가 발생하지 않았다면 반환된 인스턴스에서 getTotal()을 호출하여 더하고 만약 getMeal에서 이러가 MealExpensesNotFound예외가 발생한다면 getMealPerDien() 메소드를 호출해 반환된 값을 더해주는데, 차라리 특수한 예외상황 자체가 안나도록 만들어주면 코드가 더 간결해질 수 있다.
public class PerDiemMealExpenses implements MealExpenses {
public int getTotal(){
//기본값으로 일일 기본 식비를 반환한다.
}
}이와 같이 기본적으로 기본 식비를 반환하는 객체를 반환하게 한다면 예외는 발생하지 않고 더 간단하게 로직을 짤 수 있다. 그러면 클라이언트 코드가 예외적인 상황을 처리할 필요가 없어지는데 이를 특수 사례 패턴(SPECIAL CASE PATTERN)이라 부른다.
2. 수직 거리
서로 밀접한 개념은 세로로 가까이 둬서 코드를 트레이싱할 때 함수간을 오가며 소스 코드를 위 아래로 중구난방 돌아다니는 일은 없어야 한다.
변수 선언
인스턴스 변수
종속 함수
개념적 유사성단위 테스트
1. 테스트당 assert 하나
최대한 하나의 테스트에서는 하나의 assert만 할 수 있도록 한다.
하지만, 테스트를 억지로 분리하며 중복되는 코드가 많아질 경우 합치는 것도 좋다.
assert 문을 최대한 줄이는 것에 초점을 맞춘다.
2. F.I.R.S.T
깨끗한 테스트가 되기 위해서는 다음 다섯 가지 규칙을 따릅니다.
빠르게(First)
: 테스트는 빨라야 합니다. 테스트가 느리면 자주 돌리지 못하고 그 시간만큼 코드를 정리하지 못 할뿐 아니라 테스트를 자주 수행할 수 없습니다.
독립적으로(Independent)
: 각각의 테스트가 서로 의존하면 안됩니다. 한 테스트가 다음 테스트가 실행될 환경을 준비해서는 안됩니다.
반복가능하게(Repeatable)
: 테스트는 어떤 환경에서든 반복 가능해야 합니다.
실제 환경, QA환경, 오프라인 환경 모두 가능해야 합니다. 테스트가 돌아가지 않는 환경이 있다면 핑계꺼리가 되며 테스트를 수행하지 못해도 넘겨야하는 상황이 생깁니다.
자가검증하는(Self-Validating)
: 테스트는 Boolean 값으로 결과를 내야 합니다. (성공 or 실패)
통과했는지를 알기 위해 로그 파일이나 콘솔창을 봐야하는것은 잘 못된 것입니다.
적시에(Timely)
: 테스트는 적시에 작성해야 합니다.
즉, 테스트하려는 실제 코드를 구현하기 직전에 구현합니다.
실제 코드를 작성 한 뒤에 테스트 코드를 작성하려 하면 테스트하기가 어려울 수도 있고, 테스트가 불가능하도록 실제 코드를 설계할 수도 있다.
