클린코드 7~9장

7장 - 오류처리

1. 오류보다 예외를 사용하라

- 오류가 발생하면 예외를 던지는 편이 낫다. 호출자 코드가 더 깔끔해지기때문

2. ry-catch-finally문 부터 작성하라

3. 미확인 예외를 사용하라(내용이해안감)

4. 예외에 의미를 제공하라

5. 호출자를 고려해 예외 클래스를 정의하라

6. 정상 흐름을 정의하라

7. null을 반환하지마라 

- null을 반환하는 코드는 일거리를 늘리고 호출자에게 문제를 떠넘기는 격

스쳐지나가는 null 반환하던 코드들,,,ㅠ

8. null을 전달하지 마라

- null을 반환하는거보다 더 나쁜 코드

 

 

 

8장. 경계

시스템에 들어가는 모든 소프트웨어를 직접 개발하는 경우는 드물다.

패키지를 사고, 오픈소스를 이용하고, 때로는 다른 팀이 제공하는 컴포넌트를 사용함

이러한 외부코드들을 깔끔하게 처리하는 기법들 정리

 

 

 

9장. 단위테스트

1. TDD법칙(Test Driven Development)  : 테스트 기반 개발

- 실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다

- 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트 작성한다

- 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다

위 세가지 규칙을 따르면 개발과 테스트가 대략 30초 주기로 묶인다.

테스트 코드와 실제 코드가 함께 나올뿐더러, 테스트 코드가 실제 코드보다 불과 몇초전에 나온다

 

2. 깨끗한 테스트 코드 유지하기

- 테스트는 유연성, 유지보수성, 재사용성을 제공한다(테스트 케이스가 있으면 변경이 쉬워지기 때문)

3. 깨끗한 테스트 코드

- 가독성이 제일 중요

4. Test당 assert 하나

- assert문이 하나인 함수는 결론이 하나라서 코드를 이해하기 쉽고 빠르다

5. F.I.R.S.T

- F(ast) 빠르게. 테스트는 빨리 돌아야한다

- I(ndependent) 독립적으로. 각 테스트는 서로 의존하면 안된다. 한 테스트가 다음 테스트가 실행될 환경을 준비해서는    안된다. 각 테스트는 독립적으로, 그리고 어떤 순서로 실행히도 괜찮아야 한다

  (서로에게 의존하면 하나가 실패할 때 나머지도 잇달아 실패하므로 원인을 진단하기 어려워짐)

- R(epeatable) 반복가능하게. 테스트는 어떤 환경에서도 반복 가능해야한다. 실제환경, QA환경, 버스를 타고 집으로 가    는 길에 사용하는 노트북 환경 등등

- S(elf-Validateing) 자가 검증하는. 테스트는 bool값으로 결과를 내야한다. 성공 아님 실패

 통과 여부를 알려고 로그 파일을 읽게 만들어서는 안된다

- T(imely) 적시에. 테스트는 적시에 작성해야한다. 단위 테스트는 테스트하려는 실제 코드를 구현하기 직전에 구현한다    실제 코드를 구현한 다음에 테스트 코드를 만들면 실제 코드가 테스트하기 어렵다는 사실을 발견할지도 모른다