Skip to content

Latest commit

 

History

History
113 lines (100 loc) · 7.36 KB

1주차 단위테스트.md

File metadata and controls

113 lines (100 loc) · 7.36 KB

Clean Code 가이드

함수(메소드)

작게 만들어라.

  • 함수를 만드는 첫 번재 규칙은 '작게'다. 함수를 만드는 두 번째 규칙은 '더 작게'다.

한 가지만 해라.

  • 함수는 한 가지를 해야 한다. 그 한 가지를 잘 해야 한다. 그 한 가지만 해야 한다.

함수 당 추상화 수준은 하나로

  • 함수가 확실히 '한 가지' 작업만 하려면 함수 내 모든 문장이 동일한 추상화 수준에 있어야 한다.
  • 코드는 위에서 아래로 이야기처럼 일해야 좋다.

서술적인 이름을 사용하라

  • 이름이 길어도 괜찮다.
  • 이름을 정하느라 시간을 들여도 괜찮다.
  • 이름을 붙일 때는 일관성이 있어야 한다.

함수 인수

  • 함수에서 이상적인 인수 개수는 0개(무항)이다. 다음은 1개이고, 다음은 2개이다.
  • 3개는 가능한 피하는 편이 좋다.
  • 4개 이상은 특별한 이유가 있어도 사용하면 안된다
  • 인수가 2 ~ 3개 필요한 경우가 생긴다면 인수를 독자적인 클래스를 생성할 수 있는지 검토해 본다.

side effect를 만들지 마라.

  • side effect는 많은 경우 예상치 못한 버그를 발생시킨다.

명령과 조회를 분리하라.

  • 함수는 뭔가를 수행하거나 답하거나 둘 중 하나만 해야 한다. 둘 다 하면 안된다.
  • 개체 상태를 변경하거나 아니면 개체 정보를 반환하거나 둘 중 하나다.

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

  • 오류 처리도 한 가지 작업이다.
    • 함수는 '한 가지' 작업만 해야 한다. 오류 처리도 '한 가지' 작업에 속한다.
    • 그러므로 오류를 처리하는 함수는 오류만 처리해야 마땅하다.
  • try/catch 블록은 원래가 추하다. 코드 구조에 혼란을 일으키며, 정상적인 동작과 오류 처리 동작을 뒤섞는다. try/catch 블록을 별도 함수로 뽑아내는 편이 낫다.
public void delete(Page page) {
    try {
        deletePageAndAllReferences(page);
    } catch (Exception e) {
        logError(e);
    }
}

반복하지 마라.

  • 중복은 소프트웨어에서 모든 악의 근원이다.

함수를 구현하는 방법은?

소프트웨어를 구현하는 행위는 여느 글짓기와 비슷하다. 논문이나 기사를 쓸 때는 먼저 생각을 기록한 후 읽기 좋게 다듬는다. 초안은 대개 서투르고 어수선하므로 원하는 대로 읽힐 때까지 말을 다듬고 문장을 고치고 문단을 정리한다.

필자는 함수를 구현할 때도 마찬가지다. 처음에는 길고 복잡하다. 들여쓰기 단계도 많고, 중복된 루프도 많다. 인수 목록도 아주 길다. 이름은 즉흥적이고 코드는 중복된다. 하지만 필자는 그 서투른 코드를 빠짐없이 테스트하는 단위 테스트 케이스도 만든다.

그런 다음 필자는 코드를 다듬고, 함수를 만들고, 이름을 바꾸고, 중복을 제거한다. 메소드를 줄이고, 순서를 바꾼다. 때로는 전체 클래스를 쪼개기도 한다. 이 와중에도 코드는 항상 단위 테스트를 통과한다.

결국에는 앞에서 다룬 규칙을 따르는 함수를 얻을 수 있다. 처음부터 딱 짜내지 않는다. 그게 가능한 사람은 없으리라.

code convention, format 맞추기

형식을 맞추는 목적

  • code convention은 중요하다! 너무 중요해서 무시하기 어렵다.
  • code convention은 의사소통의 일환이다. 의사소통은 전문 개발자의 일차적인 의무다.

적절한 행의 길이를 유지하라

가로 format 맞추기

  • 120자 정도로 행 길이를 제한한다.

팀 규칙

  • 모든 프로그래머는 자신이 선호하는 규칙이 있다. 하지만 팀에 속한다면 자신이 선호해야 할 규칙은 바로 팀 규칙이다.
  • 팀은 한 가지 규칙에 합의해야 한다. 그리고 모든 팀원은 그 규칙을 따라야 한다.

학습 목표

경험해야할 학습 목표

  • Github 기반으로 온라인 코드 리뷰하는 경험
  • JUnit 사용법을 익혀 단위 테스트하는 경험
  • 자바 code convention을 지키면서 프로그래밍하는 경험
  • 메소드를 분리하는 리팩토링 경험

경험할 객체지향 생활 체조 원칙

  • 규칙 1: 한 메서드에 오직 한 단계의 들여쓰기만 한다.
  • 규칙 2: else 예약어를 쓰지 않는다.
  • 이 두가지 원칙을 통해 메소드를 분리해 메소드가 한 가지 작업만 담당하도록 구현하는 연습을 목표로 한다.
  • 이 같은 원칙 아래에서 메소드의 라인 수를 15라인이 넘지 않도록 구현한다.

프로그래밍 요구사항

  • indent(인덴트, 들여쓰기) depth를 2를 넘지 않도록 구현한다. 1까지만 허용한다.
    • 예를 들어 while문 안에 if문이 있으면 들여쓰기는 2이다.
    • 힌트: indent(인덴트, 들여쓰기) depth를 줄이는 좋은 방법은 함수(또는 메소드)를 분리하면 된다.
  • 함수(또는 메소드)의 길이가 15라인을 넘어가지 않도록 구현한다.
    • 함수(또는 메소드)가 한 가지 일만 잘 하도록 구현한다.
  • 모든 로직에 단위 테스트를 구현한다. 단, UI(System.out, System.in) 로직은 제외
    • 핵심 로직을 구현하는 코드와 UI를 담당하는 로직을 구분한다.
    • UI 로직을 InputView, ResultView와 같은 클래스를 추가해 분리한다.
  • 자바 코드 컨벤션을 지키면서 프로그래밍한다.
  • else 예약어를 쓰지 않는다.
    • 힌트: if 조건절에서 값을 return하는 방식으로 구현하면 else를 사용하지 않아도 된다.
    • else를 쓰지 말라고 하니 switch/case로 구현하는 경우가 있는데 switch/case도 허용하지 않는다.

기능 목록 및 commit 로그 요구사항

  • 기능을 구현하기 전에 README.md 파일에 구현할 기능 목록을 정리해 추가한다.
  • git의 commit 단위는 앞 단계에서 README.md 파일에 정리한 기능 목록 단위로 추가한다.
  • 참고문서: AngularJS Commit Message Conventions
  • AngularJS Commit Message Conventions 중
  • commit message 종류를 다음과 같이 구분
fix (bug fix)
docs (documentation)
style (formatting, missing semi colons, …)
refactor
test (when adding missing tests)
chore (maintain)

리팩토링 요구사항

  • 핵심 비지니스 로직을 가지는 객체를 domain 패키지, UI 관련한 객체를 view 패키지에 구현한다.
  • MVC 패턴 기반으로 리팩토링해 view 패키지의 객체가 domain 패키지 객체에 의존할 수 있지만, domain 패키지의 객체는 view 패키지 객체에 의존하지 않도록 구현한다.
  • 테스트 가능한 부분과 테스트하기 힘든 부분을 분리해 테스트 가능한 부분에 대해서만 단위 테스트를 진행한다.

출처 : Next-Step TDD, Clean Code with Java 강의