[TDD, 클린 코드] (1) TDD, OOP 맛보기

June Lee·2023년 4월 8일

좋은 코드

목록 보기

3/8

TDD

TDD = Test First Development + Refactoring

TDD는 단순 테스트 기법이 아니라, 요구사항을 분석하고 설계하는 기법이다.

방법

요구 사항을 작은 단위로 쪼갠다
각 요구 사항에 맞는 테스트 코드를 작성한다.
테스트 코드를 하나 완성할 때마다(최소 요구 사항 단위) 테스트를 통과하기 위한 실제 기능 코드를 구현한다.(이 과정에서는 코드가 더러워져도 괜찮다)
일단 pass 했다면 리팩토링을 한다 (객체지향 생활 체조 원칙 참고)
이 과정을 반복한다.

객체지향 생활 체조 원칙

규칙 1: 한 메서드에 오직 한 단계의 들여쓰기(indent)만 한다.
규칙 2: else 예약어를 쓰지 않는다.
규칙 3: 모든 원시값과 문자열을 포장한다.
규칙 4: 한 줄에 점을 하나만 찍는다.
규칙 5: 줄여쓰지 않는다(축약 금지).
규칙 6: 모든 엔티티를 작게 유지한다.
규칙 7: 3개 이상의 인스턴스 변수를 가진 클래스를 쓰지 않는다.
규칙 8: 일급 콜렉션을 쓴다.
규칙 9: 게터/세터/프로퍼티를 쓰지 않는다.

-> 리팩토링을 해야할 곳을 찾는 것이 쉽지 않기 때문에 위와 같은 정량적인 기준에 맞춰 코드를 보며 고칠 부분을 찾는 연습을 하자.
-> 위 규칙에 따르다보면 자연스레 메서드 분리 / 클래스 분리가 가능하다.

클래스(class)

객체지향에서 클래스는 객체의 능동적인 관리자이다.
즉 getter, setter를 남발하며 클래스를 자료구조로만 이용하는 건 바람직하지 않다.
객체는 캡슐화된 데이터의 대표자(representative)이다. 따라서 객체를 스스로 결정을 내리고 행동할 수 있는 자립적인 엔티티로 생각하자(코드를 읽어봤을 때 객체가 독립된 사람인 것처럼 읽힌다면 올바른 방향)

cf) 클래스의 이름

-er로 끝나는 이름(무엇을 하는지에 기반한 이름)을 쓰지 말라 (ex. cashFormatter)
무엇인지에 기반한 이름을 지어라 (ex. cash)

예시 코드

/* 리팩 전 */
public static void main(String[] args) {
  // 데이터베이스 연결
  DBConnection connection = new DBConnection();

  // 상품 금액 확인
  Milk milk = connection.findItem(“우유”);
  int price = milk.getPrice();

  // 결제
  Person pobi = connection.findPerson(“포비”);
  Wallet wallet = pobi.getWallet();
  wallet.setAmount(wallet.getAmount() - price);

  // 상품 지급
  pobi.setItem(milk);

  // 데이터베이스 저장
  connection.save(pobi);
}

/* 리팩 후 */
public static void main(String[] args) {
  // 데이터베이스 연결
  DBConnection connection = new DBConnection();

  // 상품 및 구매자 조회
  Milk milk = connection.findItem(“우유”);
  Person pobi = connection.findPerson(“포비”);

  // 결제 및 상품 지급
  milk.sellTo(pobi);

  // 데이터베이스 저장
  connection.save(pobi);
}