[Clean Code] 정리

1. 깨끗한코드

어째서 나쁜코드를 짰는가?

• 급해서?서두르느라? 
• 대충 짠 프로그램이 돌아간다는 사실에 안도감을 느끼며 그래도 안 돌아가는 프로그램보다 돌아가는 쓰레기가 좋다고 스스로 위로한 경험이 있다. 다시 돌아와 나중에 정리하겠다고 다짐했었다. 물론 그때 그 시절 우리는 르블링의 법칙을 몰랐다. 나중은 결코 오지 않는다.

2. 의미 있는 이름

클래스 이름

• 명사/명사구 (ex. Customer, WikiPage)
• Data, Info 와 같은 단어는 피하고, 동사는 사용하지 않는다.

메서드 이름

• 동사/동사구 (ex. postPayment, deletePage)

• 접근자(get) , 변경자(set), 조건자(is) 는 javabean 표준에 따라 값 앞에 해당 동사를 붙인다.
• 생성자를 중복정의(overload) 할 때는 정적 팩토리 메서드를 사용한다.

검색하기 쉬운 이름을 사용하라

 

• ex. int WORK_DAYS_PER_WEEK = 5

불필요한 맥락을 없애라

3. 함수

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

Switch 문

• 다형적 객체를 생성하는 코드 안에서만 허용한다.

• 길고 서술적인 이름이 짧고 어려운 이름보다 좋다.
• 함수에서 이상적인 인수 개수는 0개(무항) 다.

4. 주석

• 나쁜 코드에 주석을 달지 마라. 새로 짜라.
• 주석은 나쁜 코드를 보완하지 못한다.
• 좋은주석? 법적인 주석

5. 형식 맞추기

• 적절한 행 길이를 유지하라. 세로 200줄 , 가로 180자 정도의 규칙을 지켜라.
• 개념은 빈 행으로 분리하라.

• 빈 행은 새로운 개념을 시작한다는 시각적 단서다.

6. 객체와 자료 구조

• 객체는 동작을 공개하고 자료를 숨긴다.

• 기본 동작을 변경하지 않으면서 새 객체 타입을 추가하기는 쉬운 반면, 기존 객체에 새 동작을 추가하기는 어렵다.

• 자료 구조는 별 다른 동작 없이 자료를 노출한다.

• 기존 자료 구조에 새 동작을 추가하기는 쉬우나, 기존 함수에 새 자료 구조를 추가하기는 어렵다.

7. 오류 처리

• Null 을 반환하지 마라.
• Null 을 전달하지 마라.
• 깨끗한 코드는 읽기도 좋아야 하지만 안정성도 높아야 한다.

8. 경계

 

9. 단위 테스트

TDD 법칙 세 가지

• 실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다.
• 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다.
• 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다.

• 깨끗한 테스트 코드를 만들려면? 가독성.가독성.가독성
• 테스트 당 assert 하나 == 테스트 당 개념 하나

F.I.R.S.T 규칙

• Fast : 테스트는 빨리 돌아야 한다.
• Independent : 서로 의존하면 안 된다.
• Repeatable : 어떤 환경에서도 반복 가능해야 한다.
• Self-Validating : 부울 값으로 결과를 내야 한다.
• Timely : 적시에 작성해야 한다. 실제 코드를 구현하기 직전!

10. 클래스

클래스는 작야아 한다!

• 단일 책임 원칙 (Single Responsibility Principle)
• 응집도를 유지하면 작은 클래스 여럿이 나온다.