대학교 4학년 때 처음 우테코의 프리코스를 진행하며 많은 코드 고민을하여 좋았던 경험이 있다. 올해도 우연히 모집 공고를 보게되었고 참가해 보았다.
1주차의 요구사항은 아래와 같다.
기능 요구사항
- 기본적으로 1부터 9까지 서로 다른 수로 이루어진 3자리의 수를 맞춘다
- 같은 수가 같은 자리에 있으면 스트라이크, 다른 자리에 있으면 볼, 같은 수가 전혀 없으면 낫싱이란 힌트 출력
- 3개의 숫자를 모두 맞출 시 게임이 종료된다.
- 게임을 종료한 후 게임을 다시 시작하거나 완전히 종료할 수 있다.
- 사용자가 잘못된 값을 입력할 경우 IllegalArgumentException을 발생시킨 후 애플리케이션은 종료되어야 한다.
기능목록
언뜻 보기에는 쉬운 프로그램이지만 만들다보니 생각보다 구현해야할게 추가되었고 최종적으로 내가 만든 기능목록과 디렉토리 구조는 아래와 같다
- 입력기능
- 서로 다른 3자리 수 입력을 받음
- 입력이 서로 다른 3자리 수 인지 검사
- 입력한 각각의 수가 1~9의 숫자인지 검사
- 게임을 재시작할지 종료할지 입력을 받음
- 입력이 1인지 2인지 검사
- 사용자가 잘못된 입력값을 입력 시 IllegalArgumentException 발생
- 출력기능
- 입력 파라미터에 따른 메시지 출력
- 사용자 입력에 따른 힌트 메시지 출력
- 숫자야구 기능
- 숫자야구 정답 리스트 생성
- 사용자 입력에 대한 볼, 스트라이크, 낫싱 결과 생성
- 사용자 입력이 정답인지 판단
- 게임 종료 후 사용자의 입력에 따라 재시작 혹은 종료
4.실행 기능
- 시작 메시지를 출력하고 정답 리스트 생성
- 사용자의 입력을 받고 힌트 메시지를 출력을 반복
- 사용자의 입력이 정답일 시 사용자의 입력에따라 게임 재시작 혹은 종료
- IllegalArgumentException 발생 시 메시지 출력후 게임 종료
baseBall
├── game
│ └── GameManager
├── io
│ ├── InputManager
│ └── OutputManager
├── Application
└── Runner구현 시 고민했던 부분
반복되어 출력되는 메시지를 단순히 System.out 안에 하드코딩하기보다는 하나의 파일 안에서 관리하고 싶었다.
이 과정에서 key와 value로 값들을 관리하는 properties 파일을 사용하여 출력 메시지들을 관리하였다.
Java에서는 이러한 properties 파일들을 관리하기 위해 Properties class를 제공하며 나도 해당 class를 사용하여 propeties 파일을 사용하였다.
commonMessage.properties
game.start=숫자 야구 게임을 시작합니다.
game.input=숫자를 입력해주세요 :
game.restart=게임을 새로 시작하려면 1, 종료하려면 2를 입력하세요
game.end=3개의 숫자를 모두 맞히셨습니다! 게임 종료
game.end.error=입력이 올바르지 않습니다 게임을 종료합니다.OutputManager.java
public OutputManager() throws IOException {
InputStream commonMessageProperties = this.getClass().getResourceAsStream("/commonMessage.properties");
this.commonMessage = new Properties();
this.commonMessage.load(commonMessageProperties);
}
public void printMessage(String messageCommand) {
System.out.print(commonMessage.getProperty(messageCommand));
}ERROR
위 코드처럼 properties 파일에 한글을 사용하고 IntelliJ에서 실행하면 아래와 같이 출력될 것이다.
IDE의 File Encoding 설정때문에 발생한 문제이며 해결 방법은 아래 글에 포스팅하였다.
1주차 피드백
space와 tab을 혼용하지 않는다
처음 이 말을 들었을때 이해가 잘 안되어서 찾아보니 많은 개발자들이 들여쓰기 시 space를 사용하고 있다는것을 알게 되었다. 각각의 장단점이 존재하였는데 tab은 적은 비트 수로 들여쓰기를 표현 가능하지만 IDE에 따라 표현하는 방식의 차이가 존재 할 수 있으며 space는 tab보다 많은 비트 수를 차지하지만 IDE에 독립적이라는 장점이 존재하였다.
배열 대신 Java Collection을 사용한다
성능측면에서는 인덱스를 사용하는 배열이 노드를 사용하는 Collection보다 뛰어나다 하지만 Collection은 데이터 조작과 관련된 다양한 API를 제공하기에 대용량의 데이터를 관리하는것이 아닌 이상 Collection을 사용하는걸 권장하는 것 같다.
느낀점
언뜻 간단해 보이는 요구사항이지만 만들다보니 생각보다 신경 쓸 부분이 많아지고 즉흥적으로 기능들을 추가하기 시작, 설계의 중요성을 깨닫게 되었다.
힌트 메시지를 출력 시 사용자의 입력에 따라 볼, 스트라이크의 위치가 달라질 수 있다고 생각하였지만 테스트 케이스를 실행중 틀린것을 알게되고 다시 수정하게되었다 이 이외에도 자잘한 부분에서 분석을 잘못해 다시 구현하는 일이 발생하였다. 구현 시작 전 충분한 설계가 필요하다는것을 느꼈다.
