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

🍀 도입해봤어요

- git commit template 플러그인을 사용하여 더욱 의미 있는 커밋 메시지를 작성하려고 했어요

- 작성자마다 클래스들이 의미하는 바와 게임의 흐름이 다양할 것이라고 예상되어 게임의 흐름을 정리해봤어요

- 기능을 구현 사항을 정리하며 파일의 디렉토리도 함께 구상해보려고 노력했어요 

- 삼항 연산자를 쓰지 않았어요

 

작성한 게임 흐름

1. 컴퓨터가 랜덤한 숫자를 이용해 답 생성하기
   1-1. 유효성 검사하기 (통과될 시에만 넘어가기)
2. (문구 출력) 숫자 야구 게임을 시작합니다.
3. (문구 출력) 숫자를 입력해주세요
4. 사용자가 숫자를 입력하기
   4-1. 유효성 검사하기 (통과될 시에만 넘어가기)
5. 답과 사용자의 입력값을 비교해 게임의 결과 출력하기
   5-1. 정답인지 확인하기  
   - 정답인 경우 7번으로
   - 정답이 아닌 경우 힌트를 출력하고 6번으로
6. 다시 사용자의 숫자를 입력받기 
   - 2번으로 돌아가서 반복하기
7. (문구 출력) 3개의 숫자를 모두 맞히셨습니다! 게임 종료
8. (문구 출력) 게임을 새로 시작하려면 1, 종료하려면 2를 입력하세요.
9. 사용자에게 게임 진행 여부 입력받기
   9-1. 1일 경우 1번으로 돌아가기
   9-2. 2일 경우 10으로
10. 게임을 종료하기

https://velog.io/@outstandingboy/Git-%EC%BB%A4%EB%B0%8B-%EB%A9%94%EC%8B%9C%EC%A7%80-%EA%B7%9C%EC%95%BD-%EC%A0%95%EB%A6%AC-the-AngularJS-commit-conventions

[Git] 커밋 메시지 규약 정리 (the AngularJS commit conventions)

 

🍀 집중해봤어요

- 캡슐화에 집중해봤어요

- 변수명과 메서드명을 신중히 고민했어요

- 각 클래스의 역할을 명확히 하고자 노력했어요

- 촘촘하고 의미 있는 테스트코드를 짜고자 노력했어요

 

🍀 클래스별 역할 정리

Answer : AnswerGenerator가 생성한 답을 저장 및 조회

Game : 하나의 게임 객체 / 게임 하나의 흐름을 관리 및 상태를 저장

Judge : 사용자의 입력값이 볼인지, 스트라이크인지, 답인지 확인 및 판단

AnswerGenerator : 중복 없는 난수 생성을 통한 답 배열 생성

Constants : 전역에서 주로 사용되는 상수들을 정의

InputValidator : 입력값이 유효한지 확인

UserInputAdapter : 사용자의 입력값을 상황에 따라 알맞게 변환

GameView : 문구 출력 및 사용자 입력값 받음

Score : 점수 저장

🍀 고려한 지점들

1. User / Computer / Answer 클래스명

- 클래스명을 User 과 Computer (참가자라는 의미에서) 로 클래스명을 지을지, Answer 로 두고 사용자의 입력값은 따로 클래스를 두지 않을지에 대하여 고민했습니다. 결과적으로는 후자를 선택했는데, 그 이유는 전자의 경우에는 User 가 입력한 숫자, Computer 가 선정한 답안 등 클래스 자체로 숫자를 나타내지 않는다는 생각이 들어서였습니다.

 

2. Constants 로 상수를 관리

- 전역적으로 사용되는 상수들이 있었습니다. 예를 들어 유효한 배열의 길이, 정답으로 판단되는 스트라이크의 개수, 숫자의 범위 등이 있었습니다. 따라서 이를 매번 클래스 내의 상수로 사용할지 전역 상수로 사용할지 고민하다가 매번 사용되는 상수들의 경우에는 따로 클래스를 생성해 전역 상수로 선언하는 것이 효율적이라고 생각해 따로 뺐습니다.

 

3. AnswerGenerator 와 Answer의 분리

- 처음에는 Answer 클래스 내부에 랜덤 + 중복 없는 숫자들을 이용해 배열을 만드는 메서드를 따로 뒀었습니다. 그러나 이렇게 될 경우, 유틸리티적인 숫자를 생성하는 부분과 Answer 정답 클래스의 결합이 강해질 것이라고 예상해 이를 느슨하게 해줘야겠다고 생각했습니다. 따라서 utils/AnswerGenerator 클래스를 따로 두게 되었습니다. 또한, 이렇게 하게 된 이유는 랜덤한 숫자에 대한 테스트를 어떻게 진행해야 할까 고민하다가 찾아본 게시글에서 랜덤한 수를 생성하는 객체를 만들고, 이를 클래스에 주입시키도록 한 코드를 참고하게 되었습니다. 이가 더 테스트하기에도 좋은 코드라고 생각해 내린 결정이었습니다.

 

4. Game 과 UserInputAdapter 의 분리

- 처음에는 Game 클래스 내부에 사용자의 입력값을 문자열에서 배열로 변환하는 changeUserInputToArray 라는 메서드를 뒀었습니다. 그러나 Game 클래스의 역할을 따져봤을 때, 하나의 게임을 관리하고 상태를 저장하는 Game 클래스에서 문자열에서 배열로 변환하는 역할을 하는 것은 맞지 않다고 생각했습니다. 또한, 입력을 받고 문구를 출력하는 GameView 에서 이를 처리하는 것 역시도 맞지 않다고 생각했습니다. 이는 유틸리티적인 측면이 더 강하다고 생각하기도 했습니다. 따라서 utils/UserInputAdapter 라는 클래스를 두어 사용자의 입력값을 상황에 따라 알맞게 변환할 수 있도록 했습니다. 또한 decideRestart 메서드 내부에서 자체적으로 Integer.parseInt 를 이용해 문자열을 정수로 변환하였었는데 이 역시도 따로 메서드를 두어 처리해주었습니다. 이렇게 하니 메서드의 역할이 분리되었습니다. 

 

5. Score 클래스의 생성

Score 클래스를 생성하기 이전에는 Game 클래스 내부에서 strike 와 ball 의 횟수를 직접 호출하여 계산하고 힌트를 반환하도록 했습니다. 그러나 이렇게 될 경우 캡슐화가 지켜지지 않을 것을 우려하였고, 이에 따라 점수를 저장하는 Score 객체를 생성하여 해당 객체 내부에서 점수 관련 로직을 처리할 수 있도록 했습니다. 

 

🍀 소감문

저번 주차 미션을 하면서 함수를 최대한 분리하기 위해서는 하나의 메서드가 하나의 역할을 하는 것에 집중하면 된다는 것을 깨달은 경험이 있습니다. 따라서 이번주차에도 최대한 하나의 메서드의 책임을 가볍게 가져가면서도 확실한 책임을 질 수 있도록 했습니다. 예를 들어, 재시작 여부를 입력받는 메서드에서 사용자의 입력값을 문자열에서 정수로 파싱하는 역할까지 했었는데 파싱하는 역할을 하는 메서드를 추출해 재시작 여부를 입력받는 메서드의 역할을 가볍고 명확하게 하였습니다. 이에 집중하다보면 테스트코드 역시도 비교적 원활하게 짤 수 있다는 것을 깨달았습니다. 테스트코드를 짜는 과정에서 어떤 메서드에 대하여 검증할 것인지 고민하다보면 검증해야 하는 역할이 명확히 하나로 좁혀져야지만 테스트코드를 손쉽게 짤 수 있었습니다. 여러 역할을 해야 하는 경우 어떤 부분에 초점을 두어 테스트를 해야 할지 혼돈이 왔기 때문입니다. 이 과정을 통해 제가 직접 느낀 테스트 코드의 역할들은 다음과 같습니다.

1. 메서드의 역할에 대해 고민해볼 수 있습니다. 앞서 언급한 것과 같이 그 역할이 명확하게 하나인지, 이에 따라 메서드명이 이를 잘 나타내고 있는지도 부가적으로 고민할 수 있었습니다

2. 메서드 간의 결합도에 대해 고민하게 됩니다. 메서드 간의 결합도가 강한 경우에는 선뜻 테스트 코드를 짜기가 어려웠습니다. 다른 메서드에 대한 테스트 역시도 함께 고민해야 했기 때문입니다. 이를 토대로 결합도를 느슨하게 하는 방면을 고민할 수 있었습니다

3. 코드 수정 시에 지표가 됩니다. 코드를 수정하고 매번 습관적으로 기존의 테스트 코드를 돌려봤습니다. 하나의 클래스에서 수정된 메서드가 다른 클래스의 테스트코드에서 오류를 발생시킨다면 수정된 메서드가 다른 클래스에서도 사용되었다는 의미이므로 어디 부분을 함께 수정해야 할지 손쉽게 파악할 수 있고, 실수를 방지할 수 있었습니다.

이를 바탕으로 메서드를 짤 때에 무엇을 기준으로 기능을 분리해야 할지, 또한, 함수명과 클래스명을 다방면으로 고민해보았습니다. 참여자라는 의미에서 User 과 Computer 로 이름 지을지, 숫자 측면에 더 집중하여 Answer 과 UserInput 이라는 클래스를 생성할지 고민했습니다. 저는 후자로 선택했는데 그 이유는 조금 더 숫자라는 의미를 담기 위해서였습니다.

또한 이번 주차에는 getter 와 setter 를 두지 않기 위해 처음으로 점수의 상태를 나타내는 enum 을 사용해봤습니다. 볼과 스트라이크 횟수를 직접 판단하는 것이 아니라 상태로 저장하고 이에 따라 반환값을 다르게 하는 것으로 개선해봤습니다.

이번 주차 미션을 통해서 많은 어려움과 좌절감을 느꼈지만, 2주차 미션 안내에 쓰여 있는 대로 최대한 저의 고통과 좌절을 있는 그대로 받아들이고 배울 점을 찾고 성장해 나간다는 생각으로 즐기고자 노력했기에 만족합니다. 이번 주도 많은 성장을 이룬 한 주였습니다.