[자동차 경주 게임] 송인봉 미션 제출합니다.

[sinb57]

프로그래밍은 끊임없이 고민하는 것이 매력 포인트라고 생각합니다.
이번 2주차에서는 아래의 두 가지에 대해 고민하며 과제를 진행했습니다.

Git 히스토리 관리

1주차와 달리 2주차 과제에서는 squash를 통해 Git 히스토리를 관리했습니다. 지난 과제를 돌이켜보면 기능 구현에 따라 테스트코드 작성, 메소드 구현, 리팩토링 등을 하나씩 커밋했습니다. 커밋의 단위가 작은 만큼 각 시점의 변경 사항을 확인하기는 좋았지만 각 커밋이 어떤 기능 구현과 연관되어 있는지 확인하기 어려웠습니다. 그래서 이번에는 기존의 커밋 방식을 유지하되 기능 구현이 끝나면 관련 커밋들을 squash 하는 방식을 택했습니다. 그 결과 기능 단위의 커밋을 직관적으로 확인할 수 있었으며 기능 구현과 관련된 내용은 커밋 메시지를 통해 파악할 수 있었습니다.

추상 팩토리 패턴

1주차 과제 당시 스트라이크/볼 판별 로직에 대한 테스트코드를 작성했습니다. 항상 동일한 결과를 반환해야하는 테스트코드 특성상 랜덤값의 존재는 골칫거리였습니다. 랜덤값에 따라 매번 다른 비교값을 대입할 수 없는지라, Referee 클래스에 setter 메소드를 생성하여 랜덤값을 특정값으로 강제 삽입하는 방법을 택했습니다. 하지만 사용하지 않는 setter 메소드를 테스트코드를 위해 생성해놓는 것은 명백히 좋지 않은 행위였습니다. 비록 1주차 과제 기간 동안 대체 방법을 생각해내지 못했지만, 이번 2주차 과제에서는 추상 팩토리 패턴을 통해 이 문제를 해결했습니다. GameService와 NumberPicker의 관계에 추상 팩토리 패턴을 적용함으로써, 테스트코드에서 CustomNumberPicker 클래스를 통해 전진 조건에 사용되는 랜덤값을 특정 지을 수 있었습니다. 그리고 이와 같은 방식으로 InputView 테스트코드에서도 CustomReader 클래스를 통해 사용자 입력값을 직접 삽입할 수 있었습니다. 이 방식을 채택하자 기존의 클래스를 변경할 필요없이, DI를 통해 원하는 행위를 유도할 수 있었습니다.