[우아한 테크코스 8기] 2주차 프리코스 회고

따로 블로그에는 올리지 못했던 ...!! 이미 반년이 지났지만 뒤늦게라도 올립니당 ..

 

2주차 미션 : racingcar

 

2주차 미션에서는 자바의 단일 책임 원칙과 MVC 패턴의 의존성을 고민하면서 코드를 설계하고, 테스트 가능성을 높이는 데 집중했습니다.

다음은 고민했던 점을 정리해 보았습니다.

 

 

 

 

 

 

1. 클래스 설계와 책임 분리

처음에는 Car와 Cars 두 클래스만으로 게임을 구성했지만, 게임 진행 로직이 컨트롤러에 노출되어 재사용이 어렵다는 문제를 발견했습니다.

 

 

그래서 게임의 핵심 흐름을 제어할 RacingGame 클래스를 추가하여, 컨트롤러는 입력과 출력, 게임 흐름만 관리하고, 실제 도메인 로직은 도메인 클래스가 책임지도록 구조를 바꿨습니다.

이 구조를 통해 각 클래스가 자신의 책임에만 집중하도록 하였고, 게임 흐름과 도메인 로직을 명확히 분리했습니다.

 

2. 입력 검증과 유틸 클래스

설계초반에는 컨트롤러에서 자동차 이름과 시도 횟수 검증, 예외 처리를 모두 수행했지만, 테스트 코드를 작성하면서 문제점을 발견했습니다. 예외를 어디에서 던질 것인지 고민하게 되었고, 컨트롤러는 흐름 제어에만 집중하고 검증 로직은 Validator가 담당하는 것이 적절하다고 판단했습니다.

그래서 NameValidator와 AttemptValidator를 나누어 검증과 예외 처리 책임을 분리했고, 불필요한 객체 생성을 막기 위해 메서드를 static으로 선언했습니다. 이번처럼 검증 로직처럼 상태를 가지지 않는 순수 기능은 static 메서드로 선언하면 객체 생성 없이 바로 호출할 수 있어 코드가 간결하고 효율적이라고 판단했습니다.

 

* 장점

    * 객체를 생성하지 않아도 메서드를 호출할 수 있어 메모리와 성능 효율이 좋음

    * 기능이 독립되어 재사용성이 높음

    * 유틸리티성 클래스 설계에 적합

* 단점

    * 상속이나 인터페이스를 통한 유연한 설계가 어려움

    * 상태를 가지는 기능과 혼합될 경우 테스트나 확장이 어려움

 

따라서 이번 미션에서는 검증 로직이 상태를 가지지 않고, 변경 가능성이 낮다고 판단했기 때문에 static 메서드를 사용했습니다.

 

3. 예외 처리 구조

이번 미션에서는 커스텀 예외(CarException)를 적극적으로 활용했습니다. 예외가 발생했을 때 의도를 명확하게 전달하기 위해서 사용했습니다.
ErrorMessage 클래스를 통해 메시지를 상수로 관리하여, 예외 메시지 중복을 줄이고 유지보수를 용이하게 만들었습니다.

 

4. MVC 패턴과 의존성 관리

랜덤 값 생성 위치를 어디에 둘지 고민했습니다. 처음에는 Cars가 RandomNumberGenerator를 직접 의존하도록 설계했으나, 이는 Cars가 "랜덤 생성"이라는 외부 관심사를 가지게 되어 테스트가 어렵고 책임이 과중해지는 문제가 있었습니다. 따라서 RacingGame이 랜덤 값을 생성하고, Cars에게는 생성된 숫자 리스트만 전달하도록 설계를 변경했습니다. 이를 통해 Cars는 여러 자동차의 컬렉션 관리, 이동 처리, 우승자 판별을 책임지고, RacingGame은 게임 진행 흐름과 랜덤 값 생성을 담당하여 각 클래스의 책임을 명확히 분리했습니다.

 

5. 테스트 코드 설계

테스트 코드를 학습하면서 AssertJ를 사용하면 예외 메시지 검증이나 흐름 검증이 더 직관적이고 가독성이 높아, 테스트 코드를 통해 요구사항을 명확하게 확인할 수 있다는 점을 학습했습니다.  따라서 테스트 코드를 작성하면서 JUnit의 assertEquals 대신 AssertJ의 assertThat()을 활용했습니다. 또한 RacingGame 테스트 시에는 실제 랜덤 값 대신 고정된 값을 반환하는 Mock 객체를 주입하여 예측 가능하고 안정적인 테스트를 작성했습니다. 이를 통해 랜덤성으로 인한 테스트 불안정성을 제거하고 원하는 시나리오를 검증할 수 있게 하였습니다.

 

 

 

저번 계산기 미션보다 복잡해진 로직을 구현하며, 더욱 느낀점과 배운점이 많았던 것 같습니다. 구현하면서 어려웠던 부분은 단일 책임에 관한 부분입니다. 어느 도메인이 어느 책임까지 가져야 하는지, 어디까지 책임을 분리해야 하는지에 대한 고민이 많았던 것 같습니다.

 또한 지난 미션에서는 다소 아쉬웠던 설계와 테스트 관점의 부족함을 개선하고자 노력했습니다. 미션을 진행하며 왜 이렇게 설계를 해야 하는지, 책임을 어디에 둬야 하는지, 테스트 가능성은 어떻게 확보할 수 있는지에 대해 고민하면서 자연스럽게 TDD에 대한 관심도 생기게 된 것 같습니다.
 앞으로 MVC 구조와 단일 책임 원칙을 지키면서, 테스트 가능성을 고려한 코드를 설계하는 습관을 들이기 위해 노력해야겠다고 느꼈습니다.