형식 맞추기
목적
코드 형식은 너무 중요하다. 내가 생각하기에도 실무를 하면서 여러 팀원들과 프로젝트를 진행할 때 내가 어제 공부한 신기술, 나의 실력을 뽐내는 장소는 아니라고 생각한다. 팀이 합의해 규칙을 정하고 모두 그 규칙을 따라야한다.
프로젝트의 코드가 일치하면 가독성도 높아질 것이고 의사소통도 쉽게 될 것이다.
적절한 행의 길이
1. 개념은 빈 행으로 분리하라
2. 세로 밀집도 : 줄바꿈이 개념을 분리하면 세로 밀집도는 연관성을 의미한다.
3. 수직거리 : 서로 밀접한 개념은 세로로 가까이 둔다.
4. 들여쓰기
객체와 자료구조
디미터 법칙
모듈은 자신이 조작하는 객체의 속사정을 몰라야 한다는 법칙이다. 객체는 자료를 숨기고 함수를 고갱한다. 즉, 객체는 조회 함수로 내부 구조를 공개하면 안된다는 의미다.
결론
객체는 동작을 공개하고 자료를 숨긴다. 기존 동작을 변경하지 않으면서 새 객체 타입을 추가하기는 쉬운 반면, 기존 객체에 새 동작을 추가하기는 어렵다. 자료구조는 별다른 동작 없이 자료를 노출한다. 그래서 기존 자료 구조에 새 동작을 추가하기는 쉬우나, 기존 함수에 새 자료구조를 추가하기는 어렵다.
오류처리
오류 코드보다 예외를 사용하라
오류가 발생하면 예외를 던지는 편이 낫다. 호출하는 쪽의 코드가 더 단순해진다. 논리와 오류 처리 코드가 분리된다.
Try-Catch-Finally 문부터 작성하라
미확인(Unchecked) 예외를 사용하라
Checked 예외는 OCP를 위반한다.
예외에 의미를 제공하라
오류 메시지에 정보를 담아 예외와 함께 던진다.
호출자를 고려해 예외 클래스를 정의하라
감싸기Wrapper 클래스를 사용한다. 외부 API를 사용할 때는 감싸기 기법이 최선이다. 의존성이 크게 줄어든다.
정상 흐름을 정의하라
null을 반환하지 마라
null 확인이 너무 많아 문제다. null 대신 빈리스트를 반환
null을 전달하지 마라
경계
외부 코드 사용하기
인터페이스 제공자와 인터페이스 사용자 사이에는 특유의 긴장이 존재한다. 이런 긴장으로 인해 시스팀 경계에서 많은 문제가 생길 소지가 있다.
경계 살피고 익히기
곧바로 우리 코드를 작성해 외부 코드를 호출하는 대신 테스트 케이스를 작성하여 외부 코드를 익힌다. 학습 테스트라 한다.
깨끗한 경계
경계에 위치하는 코드는 깔끔히 분리한다. 또한 기대치를 정의하는 테스트 케이스를 작성한다. 새로운 클래스로 경계를 감싸거나, ADAPTER 패턴을 사용해 우리가 원하는 인터페이스를 패키지가 제공하는 인터페이스로 변환하자.
단위 테스트
TDD법칙 세가지
1. 실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다.
2. 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다.
3. 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다.
깨끗한 테스트 코드 유지하기
실제 코드가 변하면 테스트 코드도 변경되어야 하는데, 테스크 코드가 더러우면 테스트 코드를 유지보수 하는 비용도 늘어난다.
테스트는 유연셩, 유지보수성, 재사용성을 제공한다.
테스트 당 assert 하나
F.I.R.S.T
Fast
테스트는 빨라야 한다.
Independent
각 테스트는 서로 의존하면 안된다.
Repeatable
테스트는 어떤 환경에서도 반복 가능해야 한다.
Self-Validating
테스트는 부울(bool) 값으로 결과를 내야 한다. 성공 아니면 실패다.
Timely
테스트는 적시에 작성해야 한다. 단위 테스트는 테스트하려는 실제 코드를 구현하기 직전에 구현한다.
