우테코 마지막 4주차 미션이 끝이 났다.
이번 미션은 메서드당 10줄 이내라는 제한과 예외가 발생한 부분부터 다시 입력을 받는 등 여러 조건들이 추가되어서 더 까다로웠고 요구 사항을 지키다보니 주요 목표였던 클래스 분리와 리펙토링에 대한 고민도 자연스레 많이 하게 되었다.
다리 건너기 게임은 다리 길이(3 ~ 20)를 입력 받으면 왼쪽에서 오른쪽으로 건너가는 다리를 생성한 뒤에 플레이어로부터 위, 아래 방향 입력을 받으면서 맞추면 건너가는 게임이다. 위, 아래 방향은 RandomGenerator를 통해 1 또는 0을 랜덤하게 생성하고 1이면 위, 0이면 아래 방향이 길이 되도록 만들면 된다. 이동할 수 있으면 O, 이동할 수 없으면 X를 출력하고 실패 시 재도전도 가능하다.
RandomGenerator를 통해 1이면 위를 나타내는 "U", 0이면 아래를 나타내는 "D"로 바꿔야 하기 때문에 Enum 클래스로 생성을 했다.
개인적으로 고민을 많이 한 부분은 이동할 때마다 다리 이동 결과를 출력하는 기능이었다. 맨 처음 입력을 받아 생성 되는 다리(맵)은 프로그램이 종료 될 때까지 변경되지 않고 유지되기 때문에 불변의 일급 컬렉션으로 관리를 하고 싶었다. 그래서 다리 이동 결과를 보관할 또 다른 객체가 필요했고 플레이어(Player) 클래스를 새로 생성하였다.
위 방향: [ O | X ]
아래 방향: [ | ]
위와 같이 이동할 때마다 출력을 해야 되는데 처음에는 StringBuilder로 append를 해가면서 만들려고 하다가 너무 지저분하고 하드 코딩을 하는 느낌이 들어서 이동 결과 문자인 'O', 'X', ' '를 Enum 클래스인 MoveResult로 생성을 해서 List<MoveResult>를 만들었다.
이번 미션에서는 Enum를 많이 사용했는데 적절하게 사용하고 있는지는 아직 잘 모르겠지만 개인적으로 많은 이점을 느낄 수 있었다.
플레이어는 Bridge한테 다리를 건너갈 수 있는지 요청을 하고 MoveResult를 반환 받아서 이동 결과('O', 'X')를 누적해나가고 이동하지 않은 반대 방향에는 OTHER(' ') 공백 문자를 넣는다.
List<MoveResult>를 toString해서 리스트의 구분자인 콤마를 출력 형식 문자에 맞춰 바꿔주었다. 리스트의 toString은 양 끝을 [, ] 괄호로 출력하기 때문에 이전처럼 StringBuilder로 하나하나 append() 하지 않고 출력을 할 수 있었다.
(지금 보니 Player를 그대로 전달하지 않고 이동 결과만 전달하거나 Dto를 따로 만들었으면 좋았을텐데..)
다음으로 어려웠던 부분은 예외 상황에 대한 요구사항이었다.
이전 미션에서는 예외 발생 시 프로그램 로직 진입점에서 try, catch로 잡아서 에러 메시지를 출력하고 종료했었는데 이번에는 예외가 발생한 부분부터 다시 입력을 받아야 됐다.
먼저 예외 메시지를 Enum으로 생성했다.
그리고 메서드마다 try, catch를 쓰자니 억지로(?) 막는 것 같아서 고민을 하다가 간단하게 게임 진행 상태를 나타내는 Enum 클래스를 만들었다.
게임 진행 상태를 단계적으로 바꿔가면서 문제가 발생하면 그 부분부터 다시 시작할 수 있도록 choiceGameMode() 메서드를 추가했는데 다시 보니 프론트 컨트롤러 클래스를 만드는 것도 괜찮았을 것 같다
이렇게 if문을 나열하니 너무 절차적인 것 같은데 더 나은 방법이 떠오르지 않아서 조금 아쉬웠다. 그리고 마지막날 리펙토링을 하다가 마감 직전에 오류를 발견해서 아슬아슬하게 고쳐서 제출했는데 단위 테스트도 중요하지만 통합 테스트도 신경을 많이 써야겠다 느꼈다. 물론 테스트 코드를 최대한 빈틈이 없도록 만들어야겠지만 놓친 부분이 있을 수 있기 때문에 직접 돌려보면서 눈으로 확인하는 테스트도 꼭 필요한 것 같다.
프리코스에서 만약에 기능 목록을 작성하고 커밋을 쪼개라는 등 이런 말 없이 그냥 미션을 풀라고 했으면 과연 어떻게 했을까
이전 경험들을 떠올려보면 나한테 정말 필요한 부분은 어려운 문제를 하나 하나 쪼개나가면서 풀어내는 연습이 아니었나 생각이 들었다.