1 장 - 깨끗한 코드
- 출시에 바빠 코드를 마구 짜고 기능을 추가할수록 코드는 엉망이 되어가고, 결국엔 감당이 불가능한 수준에 이른다. 결국엔 대가를 치른다.(최악의 상황일 경우 서비스 종료 등)
- 나쁜 코드가 쌓일수록 팀 생산성은 0이된다. 기억해라. 생각날 때 바로 나쁜 코드를 리팩토링하자. 나중에는 오지 않는다.
- 빨리 가는 유일한 방법은, 언제나 코드를 깨끗하게 유지하는 습관이다.
- 깨끗한 코드란?
- 보기에 즐거운 코드, 세세한 사항(오류 등)까지 꼼꼼하게 처리하는 코드
- 단순하고 직접적이다.깨끗한 코드는 결코 설계자의 의도를 숨기지 않는다. 명쾌한 추상화와 단순한 제어문으로 가득하다.
- 다른 사람이 고치기 쉽다.
- 테스트 하기 좋은 코드, 테스트케이스가 없으면 깨끗하지 않다.
- 중복 줄이기, 한 메소드가 한 기능만 수행하기, 작게 추상화하기
2장 - 의미있는 이름
- 의도를 분명히 밝혀라 - 좋은 이름(클래스,함수,매개변수 등)을 지어라.
- 불분명한 불용어(data,info,a,an,the,Processor 등)를 사용하지말아라.
- 발음하기 쉬운 이름/검색하기 쉬운 이름을 사용해라.
- 클래스 이름 - 명사나 명사구가 적합하다. (Customer, WikiPage,Account)
- 메서드 이름 - 동사나 동사구가 적합하다. (postPayment,deletePage,save) 접근자(get),변경자(set),조건자(is) 같은 경우는 표준에따라 get,set,is를 붙인다.
- 한 개념에 한 단어를 사용해라 - fetch,retrieve,get 같이 제각각으로 부르면 혼란스럽다.
- 기술 개념에는 기술이름이 가장 적합하다 - Visitor패턴인 경우 AccountVisitor
3장 - 함수
- 함수를 만드는 첫째 규칙은 "작게!" 짜라. 둘째 규칙은 "더 작게!" 짜라.
- 함수는 한가지를 해야한다. 그 한가지를 잘 해야한다. 그 한가지만을 해야한다.
- 길어도 상관없다 함수 기능을 잘 표현하는 서술적인 이름을 사용해라.
- 함수에서 이상적인 parameter개수는 0, 다음 1개, 그 다음은 2개이다. 3개와 4개는 최대한 피하고 사용하지 말아라. parameter가 많을수록 테스트하기 부담스럽고 어렵다.
- 명령과 조회를 분리해라.
if(set("username","unclebob"))..
보단
if(attributeExists("username")){
setAttribute("username","unclebob");
...
}
이 명확하다.
4장 - 주석
- 프로그래밍 언어를 사용해 의도를 표현할 능력이 있다면 주석이 필요없다. -> 주석을 사용하는 것은 코드로 의도를 잘 표현하지 못했기 때문이다.
- 주석은 믿기 어렵다. 코드는 진화하고 변해도 주석은 코드를 따라가지않는다. -> 프로그래머들이 주석을 유지보수하기란 현실적으로 불가능하다....
- 주석을 달기보단 코드를 어떻게 하면 더 깔끔하고 의도를 표현할지에 신경을 쓰는게 훨씬 낫다.
// 직원에게 복지 혜택을 받을 자격이 있는지 검사한다.
if((employee.flags & HOURLY_FLAG) && (employee.age > 65))
위에 코드보단 밑에 코드가 주석이 없어도 이해하기 쉽다.
if (employee.isEligibleForFullBenefits())
- 적절한 상황에 주석을 사용하는 것은 괜찮다. 구분을 잘 해야한다. 밑과 같은 주석은 정적초기화 함수를 사용하려던 프로그래머가 주석을 보고 실수를 면한다.
public static SimpleDateFormat makeStandardHttpDateFormat(){
// SimpleDateFormat은 스레드에 안전하지 못한다.
// 따라서 각 인스턴스를 독립적으로 생성해야 한다.
SimpleDateFormat df = new SimpleDateFormat("EEE, dd MMM yyyy HH:mm:ss z");
df.setTimeZone(TimeZone.getTimeZone("GMT"));
return df;
}
