TDD, 클린 코드 with Java (미션 2. 로또 - TDD)

지난번 미션 1. 자동차 경주 - 단위 테스트를 진행하고, 이어서 미션 2. 로또를 진행했습니다.

 

미션 1보다는 빠르게 진행했지만, 모든 미션을 끝내기 위해서는 조금 더 속도를 내야겠네요... 😭

 

 

1단계 - 문자열 실습

1단계는 간단한 문자열 사칙 연산 계산기를 구현하는 미션입니다.

• 예를 들어 2 + 3 * 4 / 2와 같은 문자열을 입력할 경우 2 + 3 * 4 / 2 실행 결과인 10을 출력해야 합니다.

 

파일 끝에는 개행을 추가하자

Github - 파일 끝에 개행이 없는 경우

Github - 파일 끝에 개행이 존재하는 경우

아래 링크를 참고해 보면 개행은 하나의 행을 정의하는 표준으로 개행이 없다면 끝나지 않은 행으로 간주하기 때문에 파일의 끝에는 개행을 추가하는 것이 좋다고 합니다.

• https://velog.io/@doondoony/posix-eol

그동안 파일 끝에 개행을 추가하는 것을 무심코 했었는데, 이번 기회에 정확한 원인을 알 수 있었습니다.

 

전체 문자열을 입력받아서 계산

테스트하려는 수식이 길어지면 해당 테스트 클래스의 라인도 점점 길어질 것 같은데요, 2 + 3 * 4 / 2를 전달했을 때 10이 잘 나오는지 한 눈에 볼 수 있도록 개선해보면 어떨까요?

최초 주어진 문자열인 2 + 3 * 4 / 2 을 검증하기 위해 테스트 코드에서 하나씩 계산하여 검증하는 코드를 작성을 했었습니다.

하지만, 위 리뷰처럼 수식이 길어진다면 테스트 코드 또한 길어질 수 있기에 입력받은 문자열 자체를 계산할 수 있는 방식으로 개선해도 좋을 것 같습니다.

 

 

2단계 - 로또(자동)

• 1차 PR
• 2차 PR

2단계의 요구사항은 본격적으로 로또를 구현하는 과정으로 로또 구입 금액을 입력받고, 자동으로 구매하며, 로또 당첨 번호를 입력받은 후 당첨 통계를 출력하기입니다.

 

로또 당첨의 상태를 가져야 할까? 상태를 변경할 수 있는 게 맞을까?

클래스 다이어그램

미션을 진행하면서 최초에 고려했던 방식은 위 이미지처럼 LottoTicket이 Lotto, LottoPrize를 필드로 가지는 방식이었습니다.

 

LottoPrize를 상태로 유지해야 할 필요가 있을지 고민해보시면 좋을 것 같아요. 구매한 로또와 당첨 번호를 갖는 로또를 비교해서 얻어지는 결과물로 생성되어도 충분하지 않을까요? 또한 changeLottoPrizeStatus()와 같은 setter 메서드가 public으로 열려 있는 상태라면 외부에서 쉽게 당첨 상태를 변경할 수 있는 문제점도 있을 것 같네요.

하지만 위 코드처럼 LottoTicket에는 상태를 변경하는(setter) 메서드가 존재하고, 결국 이러한 메서드가 public 이면 (리뷰처럼) 외부에서 당첨 상태를 조작할 수 있는 문제점이 존재합니다.

 

로또를 구매한 후 당첨 번호를 입력받기 때문에 로또를 발급받았을 때 당첨 상태를 바로 비교하는 건 불가능합니다.

당첨 상태를 비교하는 메서드에서 기존에는 setter를 통해 값을 변경했다면, 개선된 코드에서는 당첨 상태를 나타내는 List<LottoPrize>를 만들어서 반환하도록 수정했습니다. 

 

위 코드도 무분별한 getter 사용, 객체에게 메시지 전달, 일급 컬렉션 사용 등 개선 여지가 많지만 1차적으로는 위와 같이 개선을 했습니다.

 

객체에게 메시지 전달

(아마도..?) 이번 리뷰에서 가장 많이 받은 피드백인 듯 합니다.. 😂

객체에게 메시지를 전달하도록 코드를 구현하는 연습이 잘 안되어 있어서 관련 피드백을 많이 받았고, 코드를 구현하면서 로직의 책임이 어느 객체에 있는지를 판단하는 것도 어려워서 놓친 것 같습니다.

getter로 값을 꺼내는 대신에, 객체에게 메시지를 보내는 방식으로 구현해보면 어떨까요? 유틸리티 클래스 사용도 좋지만, getter를 자주 호출하는 절차지향적인 코드가 되는 경우가 종종 있습니다. Controller를 담당하는 Application에서 객체 간에 메시지를 주고 받는 구조도 고민해보시면 좋을 것 같아요.

위 getter처럼 값을 꺼내는 방식이 아닌 해당 객체에게 메시지를 전달하는 방식으로 개선하려고 보니 로또 번호와 당첨 번호를 비교하는 역할을 Lotto가 스스로 하는 것이 맞을까? 라는 생각이 많이 들었습니다.

관련해서는 아래 포스팅을 보며 많이 도움이 되어 첨부합니다. (두 번째는 저와 동일한 생각을 가지신 분의 질문 및 토론입니다.)

• https://tecoble.techcourse.co.kr/post/2020-04-28-ask-instead-of-getter/
• https://github.com/orgs/woowacourse-precourse/discussions/1177

교육 과정이 종료되면 객체 지향의 사실과 오해 및 오브젝트를 읽어보면서 다시 정리하는 시간을 가져야겠네요. 

 

출력에 대한 하드 코딩 제거

하드 코딩하는 대신 LottoPrize 를 활용해보는 건 어떨까요?

당첨 통계를 출력하기 위해 모든 당첨 개수를 하나씩 출력하는 부분이 존재했었는데 enum 클래스에 출력과 관련된 문장을 추가하여 반복 하드 코딩 부분을 제거할 수 있었습니다.

 

테스트 코드 중복 제거

@ParameterizedTest 를 활용하여 코드 중복을 줄여보면 어떨까요?

로또 번호가 한두 개씩 달라지고, 이에 따라 당첨 상태가 달라지는 테스트를 전부 작성하다 보니 중복 부분이 많이 존재하여 @ParameterizedTest, @MethodSource 어노테이션을 활용하여 중복 코드를 제거했습니다.

 

시스템에 독립적인 개행 문자 사용

https://www.baeldung.com/java-string-newline#3-using-platform-independent-newline-characters

 

 

3단계 - 로또(2등)

3단계의 요구 사항은 2등을 위한 보너스 번호가 추가되고, 당첨 통계에도 2등이 추가되어야 합니다.

보너스 번호 하나 추가하는 요구사항이 뭐가 어렵겠어?라고 생각했지만, 기존 코드를 리팩터링 하면서 단순히 기능 추가하는 작업도 쉬운 일이 아니라는 것을 깨닫게 되었습니다.. 😭

 

도메인 객체를 추가하자

As-Is) 당첨 번호와 보너스 번호를 갖는 도메인 객체를 추가해보는 건 어떨까요?

기존 로직에서 당첨 번호를 의미하는 WinnerLotto 객체를 추가하여 다음과 같은 이점을 가질 수 있었습니다.

• 메서드 인수의 갯수 감소
• 객체의 책임 및 역할 분리

※ 참고로 교육자료의 가이드는 다음과 같습니다.

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

 

 

4단계 - 로또(수동)

객체에게 메시지 전달

객체에게 메시지를 전달하는 것은 결국 객체를 객체스럽게 사용한다는 뜻이기도 하고, 이는 객체의 책임과 역할이 잘 분리되어 코드의 가독성 향상이나 테스트 코드 작성의 용이함, 유지 보수 편의 등 다방면으로 이점이 있을 듯 합니다.