[클린코드]15.JUnit 들여다보기

지난 장과 마찬가지로 순차적으로 리팩터링을 하는 과정을 보여주는 장이다. 단일 모듈을 예시로 보여주어서 훨씬 이해하기가 용이했다.
JUnit은 가장 유명한 프레임워크 중 하나인데, 그런 모듈의 소스도 처음 훑어볼 때 프로세스가 직관적으로 이해되지 않았다. 최종 리팩터링 버전을 읽으면서 훨씬 직관적으로 이해되었고, 클린코드가 왜 중요한지 체감할 수 있었다.

📆TIL(Today I Learned) 날짜

2022.05.02

📑오늘 읽은 범위

15.JUnit 들여다보기

✍🏻책에서 기억하고 싶은 내용

가장 먼저 눈에 거슬리는 부분은 멤버 변수 앞에 붙인 접두어 f다. 오늘날 사용하는 개발 환경에서는 이처럼 변수 이름에 범위를 명시할 필요가 없다. 접두어 f는 중복되는 정보다. 그러므로 접두어 f를 모두 제거하자.

다음으로 compact 함수 시작부에 캡슐화되지 않은 조건문이 보인다.

public String compatc(String message) {
  if (expected == null || actual == null || areStringsEqual())
    return Assert.format(message, expected, actual);
}

의도를 명확히 표현하려면 조건문을 캡슐화해야 한다. 즉, 조건문을 메서드로 뽑아내 적절한 이름을 붙인다.

public String compatc(String message) {
  if (shouldNotCompact())
    return Assert.format(message, expected, actual);
  // 실행구문
}

부정문은 긍정문보다 이해하기 약간 더 어렵다. 그러므로 첫 문장 if를 긍정으로 만들어 조건문을 반전한다.

  if(shouldNotCompact())
    return Assert.format(message, expected, actual);
  // 실행구문

  if(shouldBeCompacted()) {
    // 실행구문
  } else {
    return Assert.format(message, expected, actual);
  }

findCommonSuffix를 주의 깊게 살펴보면 숨겨진 시간적인 결합(hidden temporal coupling) 이 존재한다. findCommonSuffix라는 이름을 findCommonPrefixAndSuffix로 바꾸고, findCommonPrefixAndSuffix에서 가장 먼저 findCommonPrefix를 호출한다. 그러면 두 함수를 호출하는 순서가 앞서 고친 코드보다 훨씬 더 분명해진다.

코드를 주의 깊게 살핀다면 내가 이 장 초반에서 내렸던 결정 일부를 번복했다는 사실을 눈치채리라. (…) 흔히 생기는 일이다. 코드를 리팩터링 하다 보면 원래 했던 변경을 되돌리는 경우가 흔하다. 리팩터링은 코드가 어느 수준에 이를 때까지 수많은 시행착오를 반복하는 작업이기 때문이다.

세상에 개선이 불필요한 모듈은 없다. 코드를 처음보다 조금 더 깨끗하게 만드는 책임은 우리 모두에게 있다.

❓궁금한 내용, 잘 이해되지 않는 내용

• 없음