프리코스 2주차(숫자 야구 게임 미션) - 우아한 테크코스

1. 📃 미션 설명

  2주 차의 미션은 '숫자 야구 게임'을 구현하는 것이다. 숫자 야구 게임의 기본적인 규칙은 아래와 같다.

  기본적으로 1부터 9까지 서로 다른 수로 이루어진 3자리의 수를 맞추는 게임이다. 같은 수가 같은 자리에 있으면 스트라이크, 다른 자리에 있으면 볼, 같은 수가 전혀 없으면 낫싱이 되게 된다.

  정답이 425인 경우를 생각해보자. 123을 제시하면 '1 스트라이크', 456을 제시하면 '1 볼 1 스트라이크', 789를 제시하면 '낫싱'을 얻게 된다. 이 같은 과정을 반복해 3개의 숫자를 모두 맞힌 경우(3 스트라이크)에 게임이 종료된다.

 

  추가된 요구 사항은 아래와 같다.

1. indent(인덴트, 들여 쓰기) depth를 3이 넘지 않도록 구현한다. (예를 들어 while문 안에 if문이 있으면 들여 쓰기는 2이다.)
2. 3항 연산자를 쓰지 않는다.  (삼항 연산자 → 변수 ? 값 1 : 값 2)
3. JUnit 5와 AssertJ를 이용하여 본인이 정리한 기능 목록이 정상 동작함을 테스트 코드로 확인한다.

 

2. 📢 공통 피드백

1) README.md를 상세히 작성한다.

  해당 프로젝트가 어떠한 프로젝트이며, 어떤 기능을 담고 있는지 기술한다.

2) 기능 목록을 재검토한다.

  기능 목록을 클래스 설계와 구현, 함수(메서드) 설계와 구현과 같이 너무 상세하게 작성하지 않는다. 클래스 이름, 함수(메서드) 시그니처와 반환 값은 언제든지 변경될 수 있기 때문이다. 너무 세세한 부분까지 정리하기보다 구현해야 할 기능 목록을 정리하는 데 집중한다. 정상적인 경우도 중요하지만, 예외적인 상황도 기능 목록에 정리한다. 특히 예외 상황은 시작 단계에서 모두 찾기 힘들기 때문에 기능을 구현하면서 계속해서 추가해 나간다.

3) 기능 목록을 업데이트한다.

  시작할 때 모든 기능 목록을 완벽하게 정리해야 한다는 부담을 가지기보다 기능을 구현하면서 문서를 계속 업데이트한다. 죽은 문서가 아니라 살아있는 문서를 만들기 위해 노력한다.

4) 값을 하드 코딩하지 않는다.

  문자열, 숫자 등의 값을 하드 코딩하지 마라. 상수(static final)를 만들고 이름을 부여해 이 변수의 역할이 무엇인지 의도를 드러내라.

private static final String STRIKE = "스트라이크";
private static final String BALL = "볼";
private static final String NOTHING = "낫싱";

5) 구현 순서도 코딩 컨벤션이다.

  클래스는 상수, 멤버 변수, 생성자, 메서드 순으로 작성한다.

class Game{
    private static final STRING STRIKE = "스트라이크";
    
    private final Player;
    
    public void Game(Player player){
        this.player = player;
    }
    
    public void play(){
    }
}

6) 변수 이름에 자료형은 사용하지 않는다.

  변수 이름에 자료형, 자료 구조 등을 사용하지 않는다.

String carNameList = Console.readLine(); // X
String[] arrayString = carNameList.split(","); // X

7) 한 함수가 한 가지 기능만 담당하게 한다

  함수 길이가 길어진다면 한 함수가 여러 일을 하려고 하는 경우일 가능성이 높다. 아래와 같이 한 함수에서 안내 문구 출력, 사용자 입력, 유횻값 검증 등 여러 일을 하고 있다면 이를 적절하게 분리한다. (이게 말처럼 쉽지 않음...😥) 

private List<Integer> userInput(){
    System.out.println("숫자를 입력해 주세요: ");
    String userInput = Console.readLine().trim();
    List<Integer> user = new ArrayList<>();
    for(char c : userInput.toCharArray()){
        user.add(Character.getNumericValue(c));
    }
    if(user.size() != 3){
        throw new IllegalArgumentException("[ERROR] 숫자가 잘못된 형식입니다.");
    }
    return user;
}

8) 처음부터 큰 단위의 테스트를 만들지 않는다.

  테스트의 중요한 목적 중 하나는 내가 작성하는 코드에 대해 빠르게 피드백을 받는 것이다. 시작부터 큰 단위의 테스트를 만들게 된다면 작성한 코드에 대한 피드백을 받기까지 많은 시간이 걸린다. 그래서 문제를 작게 나누고, 그중 핵심 기능에 가까운 부분부터 작게 테스트를 만들어 나간다.

• 큰 단위의 테스트
  숫자 야구 게임을 시작해서 사용자가 숫자를 입력하면, 컴퓨터 숫자와 비교하여 그 결과를 알려준다.
• 작은 단위의 테스트
  사용자의 숫자가 컴퓨터의 숫자와 하나도 일치하지 않으면 낫싱을 출력한다.
  사용자의 숫자가 컴퓨터의 숫자와 1개는 일치하고, 위치가 다르면 1 볼을 출력한다.

 

3. 💊 배운 점 & 느낀 점

1) 기능 목록 작성

  기능 목록을 작성하면서 생각보다 시간이 너무 많이 걸렸다. 시간이 많이 걸린 이유로는 '기능 목록을 처음 작성해봐서'와 '너무 자세하게 작성해서' 일 것이다. 

  기능 목록을 따라서 개발을 진행하니 신기하게도 뒤로 back(?)하는 일이 잘 없었다. 아마 큰 그림을 알고 있는 상태에서 개발을 진행했고 그리고 '기능 목록'을 작성하면서 이미 잘못될 경우를 고려했기 때문이다. 이 덕분에 기능 목록을 작성하면서 보낸 시간보다 더 많은 시간을 뒤에서 아낄 수 있었다.👊 

  또한, 기능 목록 단위로 commit을 진행하니 더 깔끔하게 git을 관리할 수 있었다.

2) 함수가 한 가지 기능을 하도록 설계

  이게 생각보다 어렵다... 생각보다 더 많이 분리해야 한다. 연습이 필요하다!

  함수가 한 가지 기능을 하는지 확인하는 기준으로 여러 가지가 있겠지만, 일단은 함수의 길이를 15라인을 넘어가지 않도록 구현하면서 함수를 분리하는 의식적인 연습을 진행할 것이다. 

3) 테스트 케이스 작성

  여기서 살짝 멘탈이 나갔다...

  '구현을 다 완성한 뒤 이제 테스트 케이스만 작성해서 제출하면 되겠구나!'라고 생각했다. 그런데 테스트 케이스를 만들면서 '다시 만들어야겠다...'라고 생각했다. 구현하는데 시간을 너무 많이 사용하여 아쉽게도 다시 만들지는 못했지만, 프리코스가 끝난 뒤 다시 만들 것이다.

  그 당시 겪었던 문제는 아래와 같다.

1. 작은 단위의 테스트를 만들려고 했다. 하지만 생각보다 기능의 크기가 컸고 내가 원하는 하나의 단위 테스트를 진행하지 못했다. → 이것이 '함수가 한 가지 기능만을 담당하지 않고 있다.'라는 것을 보여준다.
2. 접근 제어자(private 등)로 인하여 접근을 할 수 없었다. 물론 접근제어자가 있어도 테스트 케이스를 작성할 수 있는 방법이 있긴 하다.(베스트의 방법은 아닐 것이다.) 생성자에서 여러 가지 테스트를 할 수 있도록 하는 등의 방법이 필요하다.

class Number{
	private final List<Integer> answer;
    
    public Number(List<Integer> answer){
        if(!isValidSize()){
            throw new IllegalArgumentException("[ERROR] 크기가 적절하지 않습니다.");
        }
        if(!isDuplicatedNumber){
            throw new IllegalArgumentException("[ERROR] 중복된 숫자가 존재합니다.");
        }
        this.answer = answer;
    }
}