바위타는 두루미

코드의 표현력과 그 코드로 이루어진 함수에 아무리 신경을 쓰더라도 더 높은 차원의 단계까지 신경쓰지 않으면 깨끗한 코드를 얻기 어렵다. 이 장에서는 깨끗한 클래스에 대해 다룬다. - 클래스 체계 - 자바의 경우 정적공개상수 -> 정적 비공개상수 ->비공개 인스턴스변수 ( 공개 변수가 필요한 경우는 거의 없음 ) 순으로 나오고 - 변수 다음에는 공개함수, 비공개함수는 자신을 호출하는 공개 함수 직후에 넣는다. - 캡슐화 - 변수와 유틸함수는 공개하지 않는 편이 낫지만, protected로 선언해 테스트 코드에 접근을 허용하기도함. - 클래스는 작아야 한다. - 얼마나 작아야하는가 ? -> 클래스가 맡은 책임을 센다. - 클래스 이름은 그 클래스의 책임을 기술해야하고 간결해야한다 ( 책임의 크기가 작도록 )..

TDD 법칙 세가지 1. 실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다. 2. 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위테스트를 작성한다. 3. 현재 실패하는 테스트를 통과할 정도만 실제 코드를 작성한다. => 이렇게 일하면 테스트케이스가 너무많아지고, 많은 테스트케이스는 관리 문제를 유발하기도 한다. 깨끗한 테스트 코드 유지하기. - 지저분한 테스트 코드일수록 실제 코드가 변경할때 함께 변화하기 어렵다. 테스트는 유연성, 유지보수성, 재사용성을 제공한다. - 이를위해서는 단위테스트가 필요하다. 단위테스트가 없다면 수정이 두렵다. 깨끗한 테스트코드란 ? - "가독성" - 테스트는 명확히 세부분으로 나뉨 : 테스트자료를 만들기 -> 테스트자료 조작하기 -> 결과가 올바른지..

오류처리 때문에 프로그램의 논리를 이해하기 어렵다면 그것은 깨끗한 코드가 아니다. -오류코드보다 예외를 사용하라. - Try-Catch-Finally 문부터 작성하라 강제로 예외를 일으키는 테스트 케이스를 작성한 후 테스트를 통과하게 코드를 작성하는 방법을 권장한다. - 미확인 예외를 사용하라. 확인된 예외는 OCP를 위반한다. 하위단계에서 코드를 변경하면 상위단계 메서드 선언부를 전부 고쳐야한다. 아주 중요한 라이브러리를 작성한다면 확인된 예외를 이용해 모든 예외를 잡아야하지만, 일반적인 어플리케이션은 의존성이라는 비용이 매우크다. - 예외의 의미를 제공하라. -예외를 던질때에는 정보를 담아 예외와 함께 던지자. - 실패한 연산 이름과 실패 유형도 언급한다. - logging을 사용한다면 catch블록..