Clean Code 책 요약. 챕터 7~9 : 오류 처리, 경계, 단위 테스트

작성 : 2021-04-15수정 : 2021-04-15

목차 펼치기

 출처 : yes24

출처 : yes24

7장 - 오류 처리

dart
1깨끗한 코드는 읽기도 좋아야 하지만 안전성도 높아야 한다.
2이 둘은 상충하는 목표가 아니다.
  • 오류 처리는 중요하다.

  • 흩어친 오류 처리 코드는 이해하기 어렵게 만든다.


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

  • Exception 처리를 통해 로직과 오류 처리를 분리시킨다.


Try-Catch-Fianally 문 부터 작성하라.

  • 트랜잭션과 유사.

  • catch 블록은 프로그램 상태를 일관성 있게 유지해야 한다.

  • 강제로 예외를 일으키는 테스트 케이스 작성 후 이를 통과하게 코드를 작성하자.


미확인 예외를 사용하라.

  • 확인된 예외를 처리하는데 드는 비용을 따져보라.

    • 하위 함수에서 새로운 오류가 추가되면, 모든 상위 함수에 해당 오류에 대한 처리구문을 추가해야한다.

    • 때로 확인된 예외는 유용할 수 있지만, 이 비용을 잘 따져본 후 사용해야 한다.


예외에 의미를 제공하라.

  • 정보를 담아 예외를 발생시켜 전후 상황을 충분히 유추할 수 있도록 해야한다.


호출자를 고려해 예외 케이스를 정의하라.

  • 발생한 위치, 유형 등 오류를 분류하는 방법은 수없이 많다.

  • 외부 라이브러리를 호출하는 부분을 포함하는 것은 좋지 않다.

    • 외부 라이브러리에서 발생하는 오류들에 대해 모두 catch가 동작하기 때문이다.

    • 외부 라이브러리를 감싸는 Wrapper 클래스를 만들어 사용하면 상호의존성이 크게 줄어들 수 있다.


정상 흐름을 정의하라.

  • 예외 처리 영역을 정상 흐름 논리의 일부로 만들지 마라.

  • 특수 사례 패턴을 통해 클래스를 만들거나, 객체를 조작해 특수 사례를 처리하라.

  • 예외가 논리를 따라가기 어렵게 만들면 안된다.


null을 반환하지 마라.

  • null을 반환하는 코드는 관리를 어렵게 하고 호출자에 문제를 떠넘긴다.

  • 예외를 발생시키거나 특수 사례 객체를 반환해라.

  • 외부 API가 null을 반환한다면, Wrapper 클래스를 만들어 따로 처리한다.


null을 전달하지 마라.

  • null을 전달받아 처리하는데 드는 비용보다, 애초에 null을 전달하지 않는 방식이 훨씬 저렴하고 간편하다.



8장 - 경계

  • 시스템에 들어가는 외부 코드를 깔끔하게 통합해야 한다.


외부 코드 사용하기.

  • 제공자는 적용성을 넓히기 위해 노력한다.

  • 사용자는 자신의 요구에 집중하길 바란다.

  • Adapter 패턴의 클래스를 만들어 캡슐화하면 관리가 수월해진다.


경계 살피고 익히기.

  • 외부 코드를 익히고, 프로젝트에 통합하는 것은 어렵다.

    • 사용 및 디버깅 모두 어렵다.

  • 학습 테스트를 통해 외부 API를 호출해보며 사용하려는 목적에 맞춰본다.


log4j 익히기.

  • 로깅 기능은 중요하다.

  • 로깅 라이브러리를 독자적 클래스로 캡슐화 하여 사용하자.


학습 테스트는 공짜 이상이다.

  • 필요한 지식을 확보하고 이해도를 높여주는 정확한 실험이다.

  • 이런 경계 테스트가 있다면 패키지 새 버전으로의 이전이 수월해진다.


아직 존재하지 않는 코드를 사용하기.

  • 외부 인터페이스를 감싸는 Dummy를 생성하여 설계 및 작업한다.

  • 바라는 인터페이스를 구현하면 전적으로 통제 가능해지고, 가독성과 의도도 분명해지며 테스트도 수월해진다.


깨끗한 경계

  • 우수한 설계는 변경 시 많은 리소스를 요구하지 않는다.

  • 통제하지 못하는 코드를 사용할 때는 과도한 투자 및 향후 변경 가능성을 대비해야 한다.

  • 따라서 깔끔히 분리한 후 Adapter 패턴을 통해 우리 코드에 의존하는 편이 좋다.

    • 자칫하면 외부 코드에 과도하게 휘둘리게 된다.



9장 - 단위 테스트

  • 1997년만 해도 TDD라는 개념은 없었고, 단위 테스트란 프로그램이 '돌아간다'는 사실만 확인하는 일회성 코드에 불과했다.


TDD 3법칙

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

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

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


  • TDD는 테스트 코드와 실제 코드가 함께 나오고, 사실상 전부 테스트하는 테스트 케이스가 나온다.

  • 일회용 테스트 코드와 자동화된 단위 테스트 슈트 사이는 매우 큰 간극이 있다.

  • 테스트 코드가 복잡할수록 실제 코드를 짜는 시간보다 테스트 케이스를 추가하는 시간이 더 걸리고, 점차 유지보수 비용이 커지고 끝내 폐기하게 된다.

  • 테스트 코드가 폐기되면 결함율이 높아지기 시작하고, 개발자는 변경을 주저하여 더 이상 코드를 정리하지 않는다.

  • 테스트 코드는 실제 코드 못지 않게 중요하다.

    모든 변경이 잠정적인 버그다.


테스트는 코드에 유연성, 유지보수성, 재사용성을 제공한다.


  • 깨끗한 테스트 코드를 만들려면 가독성이 필요하다.

    • 최소의 표현으로 많은 것을 나타내야 한다.


테스트 함수마다 한 개념만 테스트하라.


깨끗한 테스트 코드, F.I.R.S.T

Fast

Independent

Repeatable

Self-Validating : bool 값 반환

Timely : 실제 코드 구현하기 직전에 구현

Contact Me

All Icons byiconiFy