clean code(클린 코드) 정리

1. 변수, 함수, 이름을 분명하게 짓기

2. 함수는 최대한 작게 하나의 기능만 담당(들여쓰기 수준은 1단이나 2단을 넘어서지 않도록 한다.)
   - 함수당 추상화 수준은 하나로!
   - 내려가기 규칙(추상화가 높은순 부터 낮은순 대로)
   - 서술적인 이름 사용
   - 모듈 내에서 함수 이름은 같은 문구 명사 동사 ex(inclusePages,setPages..)
   - 인수(매개변수) 3개는 가능한 피하고 4개이상은 이유가 필요하지만, 이유가 있어도 사용하면 안된다.
   - 플래그 인수는 안좋다. 이미 그걸 인수로 준 것 자체가 함수가 두 역할을 한다는 것 이기 떄문
   - 오류 코드보다 예외를 사용하라!
   - try/catch 블록 뽑아내기 (함수로 따로 분리 해 내기)

3.주석을 가능한 줄이도록 꾸준히 노력해야 한다.
    - 코드로 의도를 표현하라(많은 경우데 주석을 함수로 만들어 표현해도 충분하다.)
    - 좋은 주석
        - 법적인 주석(저작권 정보, 소유권 정보) ex) 첫머리 
        - 정보를 제공하는 주석 
        - 의도를 설명하는 주석  //스레드를 대량 생성하는 방법으로 어떻게든 경쟁 조건을 만들려 시도한다.
        - 의미를 명료하게 밝히는 주석// a==a a!=b .....
        - 결과를 경고하는 주석 // 여유시간이 충분하지 않다면 실행하지 마십시오.
        - TODO 주석 '앞으로 할일' 프로그래머가필요하다 여기지만 당장 구현하기 어려운 업무를 기술
        - 중요성을 강조하는 주석
        - 공개 API를 구현한다면 Javadocs를 작성하라!

종속함수 한 함수가 다른 함수를 호출한다면 두 함수는 세로로 가까이 배친한다. 또한 가능 하다면 호출하는 함수를 호출되는 함수보다 먼저 배치한다.
    - 호출되는 함수를 호출하는 함수보다 나중에 배치한다. 그러면 소스 코드 모듈이 고차원에서 저차원으로 자연스럽게 내려간다.

개념적 유사성 개념적은 친화도가 높을수록 코드를 가까이 배치한다. ex)함수에서 다른 함수호출 , 비슷한 기능을 하는 함수들 

4. 객체 
    자료의 추상화 
        객체는 추상화 뒤로 자료를 숨긴 채 자료를 다루는 함수만 공개한다.
        자료구조는 자료를 그대로 공개하며 별다른 함수는 제공하지 않는다.

5. 오류 코드보다 예외를 사용하라
    - 오류 함수 사용 (분리)
    - try catch finally 문부터 작성하라
    - 미확인(unchecked) 예뢰를 사용하라
        - checked 예외 는 컴파일 단계에서 확인되며 반드시 처리해야 하는 예외입니다.
            IOException
            SQLException
        - Unchecked 예외 는 실행 단계에서 확인되며 명시적인 처리를 강제하지는 않는 예외입니다.
            NullPointerException
            IllegalArgumentException
            IndexOutOfBoundException
            SystemException
            단점 : 해당 함수 뿐만아니라 호출하는 함수도 수정을 해줘야 하기 때문에 OCP를 위반하게된다
        
        - 예외에 의미를 제공하라 (예외를 던질 때는 전후 상황을 충분히 덧붙인다. 오류 메시지에 정보를 담아 예외와 함께 던진다)
    - 감싸기 클래스 작성
    - 정상 흐름을 정의하라.
       외부 API를 감싸 독자적인 예외를 던지고, 코드 위에 처리기를 정의해 중단된 계산을 처리한다. 때로는 중단이 적합하지 않은 때도 있다.
       예외가 발생한다면 기본 값 객체를 만들어서 반환한다. 이를 특수 사례 패턴이라고 한다 그러면 따로 예외적인 상활을 처리할 필요가 없다.
    - null을 반환하지 마라!
        예외를 던지거나 특수 사례 객체를 던져라!!
    - null을 전달하지 마라!!

6.경계
    외부 코드를 우리 코드에 깔끔하게 처리 하는 기법과 기교

7. TDD 법칙
    F.I.R.S.T.
        빠르게(테스트는 빨리 돌아야한다.), 독립적으로(각 테스트 서로 의존 x), 반복가능하게(어느 환경에서라도 테스트가 돌아야한다.), 자가 검증하는(테스트는 성공 아니면 실패로 결과를 알수 있어야한다.),
        적시에(테스트는 적시에 작성해야 한다. 단위테스트는 테스트하려는 실제 코드를 구현하기 직전에 구현한다.)

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

    테스트는 유연성, 유지보수성, 재사용성을 제공한다. (테스트 케이스가 있다면 변경이 쉬워진다)
    
    깨끗한 테스트 코드를 만들려면 가독성이 좋아야 한다.
    명확한 분류 (ex 세가지 부분으로 나뉜다 1. 테스트 자료를 만든다. 2. 테스트 자료를 조작한다 3. 조작한 결과가 올바른지 확인한다.)
    
    테스트 당 assert 하나 보다는 --> 테스트 당 개념 하나!!
        - 저자: 훌륭한 지침이라고 생각한다 하지만 떄로는 함수 하나에 여러 assert 문을 넣기도 한다. 단지 assert문 개수는 최대한 줄여야 좋다는 생각

8. 클래스
    - 클래스는 작아야한다!
    - 캡슐화
        변수와 유틸리티 함수는 가능한 공개하지 않는 편이 낫다 하지만 반드시 숨겨야 한다는 법칙도 없다.(테스트 코드를 위해 protected로 선언)
        하지만 캡슐화를 풀어주는 결정은 언제나 최후의 수단
9. 시스템
    시스템 제작과 시스템 사용을 분리하라
        - 소프트웨어 시스템은 (애플리케이션 객체를 제작하고 의존성을 서로 '연결'하는) 준비 과정과 (준비과정 이우헤 이어지는) 런타임 로직을 분리하여야 한다.