우테코 프리코스 2주차 회고 - 숫자 야구

프리코스 2주차

1주차와 동일한 부분

1주차와 동일한 부분이 있어서 해당 부분은 1주차 글로 참고 하도록 하겠습니다.

• 진행방식
• 미션 제출 방법
• 과제 제출 전 체크리스트 - 0점 방지
• 프로그래밍 요구 사항(추가된 요구사항은 아래에 적어 두었습니다.)

https://takim0070.tistory.com/25

우테코 프리코스 1주차 회고 - 온보딩

 

기능 요구 사항

기본적으로 1부터 9까지 서로 다른 수로 이루어진 3자리의 수를 맞추는 게임이다.

• 같은 수가 같은 자리에 있으면 스트라이크, 다른 자리에 있으면 볼, 같은 수가 전혀 없으면 낫싱이란 힌트를 얻고, 그 힌트를 이용해서 먼저 상대방(컴퓨터)의 수를 맞추면 승리한다.
  • 예) 상대방(컴퓨터)의 수가 425일 때
    • 123을 제시한 경우 : 1스트라이크
    • 456을 제시한 경우 : 1볼 1스트라이크
    • 789를 제시한 경우 : 낫싱
• 위 숫자 야구 게임에서 상대방의 역할을 컴퓨터가 한다. 컴퓨터는 1에서 9까지 서로 다른 임의의 수 3개를 선택한다. 게임 플레이어는 컴퓨터가 생각하고 있는 서로 다른 3개의 숫자를 입력하고, 컴퓨터는 입력한 숫자에 대한 결과를 출력한다.
• 이 같은 과정을 반복해 컴퓨터가 선택한 3개의 숫자를 모두 맞히면 게임이 종료된다.
• 게임을 종료한 후 게임을 다시 시작하거나 완전히 종료할 수 있다.
• 사용자가 잘못된 값을 입력할 경우 IllegalArgumentException을 발생시킨 후 애플리케이션은 종료되어야 한다.

입출력 요구 사항

입력

• 서로 다른 3자리의 수
• 게임이 끝난 경우 재시작/종료를 구분하는 1과 2 중 하나의 수

출력

• 입력한 수에 대한 결과를 볼, 스트라이크 개수로 표시

1볼 1스트라이크

• 하나도 없는 경우

낫싱

• 3개의 숫자를 모두 맞힐 경우

3스트라이크
3개의 숫자를 모두 맞히셨습니다! 게임 종료

• 게임 시작 문구 출력

숫자 야구 게임을 시작합니다.

실행 결과 예시

숫자 야구 게임을 시작합니다.
숫자를 입력해주세요 : 123
1볼 1스트라이크
숫자를 입력해주세요 : 145
1볼
숫자를 입력해주세요 : 671
2볼
숫자를 입력해주세요 : 216
1스트라이크
숫자를 입력해주세요 : 713
3스트라이크
3개의 숫자를 모두 맞히셨습니다! 게임 종료
게임을 새로 시작하려면 1, 종료하려면 2를 입력하세요.
1
숫자를 입력해주세요 : 123
1볼
...

 

프로그래밍 요구사항(추가된 요구사항만 있음)

• indent(인덴트, 들여쓰기) depth를 3이 넘지 않도록 구현한다. 2까지만 허용한다.
  • 예를 들어 while문 안에 if문이 있으면 들여쓰기는 2이다.
  • 힌트: indent(인덴트, 들여쓰기) depth를 줄이는 좋은 방법은 함수(또는 메서드)를 분리하면 된다.
• 3항 연산자를 쓰지 않는다.
• 함수(또는 메서드)가 한 가지 일만 하도록 최대한 작게 만들어라.
• JUnit 5와 AssertJ를 이용하여 본인이 정리한 기능 목록이 정상 동작함을 테스트 코드로 확인한다.
  • 테스트 도구 사용법이 익숙하지 않다면 test/java/study를 참고하여 학습한 후 테스트를 구현한다.

라이브러리

• camp.nextstep.edu.missionutils에서 제공하는 Randoms 및 Console API를 사용하여 구현해야 한다.
  • Random 값 추출은 camp.nextstep.edu.missionutils.Randoms의 pickNumberInRange()를 활용한다.
  • 사용자가 입력하는 값은 camp.nextstep.edu.missionutils.Console의 readLine()을 활용한다.

사용 예시

List<Integer> computer = new ArrayList<>();
while (computer.size() < 3) {
    int randomNumber = Randoms.pickNumberInRange(1, 9);
    if (!computer.contains(randomNumber)) {
        computer.add(randomNumber);
    }
}

 

과제 진행 요구사항

• 기능을 구현하기 전 docs/README.md에 구현할 기능 목록을 정리해 추가한다.
• Git의 커밋 단위는 앞 단계에서 docs/README.md에 정리한 기능 목록 단위로 추가한다.
  • 커밋 메시지 컨벤션 가이드를 참고해 커밋 메시지를 작성한다.

 

2주차 공통 피드백

• README.md를 상세히 작성한다.
• 기능 목록을 재검토한다.
  • 클래스 이름, 함수 시그니처와 반환값과 같은 것들을 상세하게 작성하지 않는다
  • 정상적인 경우도 중요하지만, 예외적인 상황도 기능 목록에 정리한다
• 기능 목록을 업데이트한다.
  • 시작할 때 모든 기능 목록을 완벽하게 정리해야 한다는 부담을 가지기보다 기능을 구현하면서 문서를 계속 업데이트한다.
• 값을 하드 코딩 하지 않는다. (magic number)
• 구현 순서도 코딩 컨벤션이다.
  • 클래스는 상수, 멤버 변수, 생성자, 메서드 순으로 작성한다.
• 변수 이름에 자료형은 사용하지 않는다
• 한 함수가 한 가지 기능만 담당하게 한다
  • 안내 문구 출력, 사용자 입력, 유효값 검증 등 여러 일을 하고 있다면 이를 적절하게 분리한다.
• 함수가 한 가지 기능을 하는지 확인하는 기준을 세운다
  • 만약 여러 함수에서 중복되어 사용되는 코드가 있다면 함수 분리를 고민해 본다. 또한, 함수의 길이를 15라인을 넘어가지 않도록 구현하며 함수를 분리하는 의식적인 연습을 할 수 있다.
• 테스트를 작성하는 이유에 대해 본인의 경험을 토대로 정리해본다
• 처음부터 큰 단위의 테스트를 만들지 않는다
  • 테스트의 중요한 목적 중 하나는 내가 작성하는 코드에 대해 빠르게 피드백을 받는 것이다. 시작부터 큰 단위의 테스트를 만들게 된다면 작성한 코드에 대한 피드백을 받기까지 많은 시간이 걸린다. 그래서 문제를 작게 나누고, 그 중 핵심 기능에 가까운 부분부터 작게 테스트를 만들어 나간다.
  • 큰 단위의 테스트
    • 숫자 야구 게임을 시작해서 사용자가 숫자를 입력하면, 컴퓨터 숫자와 비교하여 그 결과를 알려준다.
  • 작은 단위의 테스트
    • 사용자의 숫자가 컴퓨터의 숫자와 하나도 일치하지 않으면 낫싱을 출력한다.
    • 사용자의 숫자가 컴퓨터의 숫자와 1개는 일치하고, 위치가 다르면 1볼을 출력한다.

 

2주차 회고

README.md 작성

README.md에 너무 많은 시간을 할애 했었습니다.

클래스 이름부터 함수 시그내처, 상수 등등 클래스에 필요한 모든 것들을 작성 했었습니다. 그런데 이렇게 하다보니 정작 중요한 기능 구현이 너무 더뎌지게 되고 README 내용과 안 맞게 되었을 때 다시 수정하는 것도 너무 번거로웠습니다.

아니나 다를까 공통 피드백에 그런 내용이 들어 있었습니다.

 

다음 주차부터는 README는 기능 별로 간단히 작성하고 만약에 기능 구현 하면서 기능 구현이 달라졌다면 수정하면 될 것 같습니다. 공통 피드백에서 숫자 야구 피드백 강의가 있어서 내용을 확인 해보니 그런식으로 말씀해 주시는 것을 확인 했습니다.

 

클래스 나누기

저는 하나의 클래스에서 모든 작업을 하게 하였습니다. 그러나 그것도 공통 피드백에서 지양하라는 내용을 확인 했죠.😅

indent 2로 제한 되어 있다보니 나름대로 메서드 분리는 어느정도 한 것 같지만 클래스는 전혀 분리가 되지 않았습니다.

메서드 분리도 indent가 2이다 보니 어쩔수 없이 분리한 감이 없지 않아 있습니다. 억지로 한 게 티가 난다는 것이었죠..

 

 

테스트 코드 작성

이 부분이 어려웠는데요 클래스 분리가 세세히 되어 있지 않다보니까 테스트 코드 작성에도 어려움이 있었습니다.

하나의 기능을 확인하려면 private 멤버 변수를 제어 해야하는 상황이 오게 되어서 그것을 해결 하기 위해 여러가지 찾아 봤는데 너무 산으로 가버렸습니다.

 

간단히 이야기하면 Reflection Field를 받아서 해당 멤버 변수를 access = true로 바꾸어 주고 해당 멤버 변수를 처리하면 되는 것이었는데 막힌 부분이 primitive 자료형은 어떻게 하면 되는지 알겠는데 제네릭 Collection은 어떻게 해야 할지 너무 막막해서 처음 생각한 테스트 중에 절반 정도만 확인하게 되었습니다.

 

느낀점

확실히 이번 주차부터는 배울점이 많았습니다. TDD라는 것을 들어보기만 했지 그 내용에 대해 알지 못했습니다. 이번 기회에 그 내용이 궁금해져서 찾아보게 되었습니다. 내용이 딱 뭐다! 이렇게 나오는 글을 확인하지 못해서 이렇다 할 개념이 정립된 것은 아닙니다.

그래도, 우선적으로 할 수 있는 것이 무엇인지는 알게 되었습니다.

• 하나의 클래스에서 모든 것을 처리하지 않는다.
• 메서드에서는 하나의 기능만 수행한다.

이것만 지키면 테스트 코드 작성에 유리 할 것으로 예상 됩니다.

 

다행이라고 느껴지는 부분은 커밋 컨벤션이 그나마 익숙해 지고 있는게 너무 좋습니다.

이번 주에 배운 내용도 다음주가 되면 더욱 익숙해 지길 희망 합니다.

 

마지막으로 제가 작업 한 내용입니다.

https://github.com/takim52/java-baseball

GitHub - takim52/java-baseball: 숫자 야구 게임 미션을 진행하는 저장소