[우아한테크코스 6기] 프리코스 1주차 숫자야구 미션 후기

1주차 미션 - 숫자야구

GitHub - woowacourse-precourse/java-baseball-6

 

지난 우아한테크코스 5기 숫자야구 미션과 동일한 미션이었다. 다만, 조금 다른 점이 있다면 

• 'JDK 17 버전에서 실행 가능해야 한다.' 는 점.
• 5기 숫자야구 미션의 프로그래밍 요구사항(indent depth를 2로 제한, 3항 연산자 사용 제한, 메소드는 한 가지 일만 하도록 제한)이 없어졌다는 점.

 

+ 대신 꼭 지켜야 할 컨벤션 4가지는 가이드로 제시해주었다.

[JAVA] Google Java Convention, 구글 자바 코드 작성규칙에 대하여

 

자바 컨벤션 중에서 다음 네 가지는 반드시 준수하라는 요구사항이 있었다.

 

1. 블록 들여쓰기 : 줄바꿈을 하고 나면 최초 행보다 최소 4자를 들여쓰기 하자.

2. 열 제한 : 하나의 문장은 최대 100글자로 제한한다.

3. 들여쓰기 지속은 최소 +8 스페이스 : indent의 depth가 커질 때 +4자의 들여쓰기를 하자.

4. 수직 빈 줄 : 클래스의 첫 번째 멤버나 초기화 앞에 있는 빈 줄을 강제하지 않는다.

 

위 네 가지는 반드시 지키되, 공식 문서에 제시된 자바 코드 컨벤션 또한 지키는 것을 목표로 했다. 

---

Day 1

프리코스를 시작하기 전, 자바 코드 컨벤션과 커밋 컨벤션을 숙지하고 객체지향 생활체조 9가지 원칙들을 숙지하는 정도까지만 해두었고, 자기소개서 작성이 생각보다 길어진 탓에 지난 5기의 프리코스 문제들을 살펴만 보고 풀어보지는 못한 상태였다.

 

그래서 미션을 처음 확인할 때 동일한 숫자야구 미션인 것을 확인하고, 미리 한 번 풀어볼걸 하는 후회도 있었지만, 어찌보면  이전 기수 분들이 이 문제를 어떻게 풀었는지 코드를 살펴보지 않은 것은 다행이었다. 

 

1. JDK 17 세팅

본론으로 들어가 미션을 받고 요구사항들을 한 번 쭉 읽다가, 'JDK 17 버전에서 실행 가능해야 한다.'는 프로그래밍 요구사항을 발견했다. 이 전까지 쭉 11 Version을 사용해왔어서 버전을 바꾸는 방법을 찾고 바꾸는 데까지 대략 3-40분정도 소요한 것 같다.

 

버전 변경에는 아래 자료가 도움이 많이 되었다.

[Java] MacOS 환경에서 Java JDK 설정 및 변경하기 : homebrew, 다운로드 파일

 

2. 기능 요구사항 정리

JDK 17을 세팅하고, 기능 요구사항들을 정리하니 대략 어떤 클래스에 어떤 기능을 구현해야 할 지 어렴풋이 감은 잡을 수 있었다. 클래스 네이밍을 하고 클래스에 어떤 기능을 넣을지 가볍게 메모를 하였고, 이제부터는 어떤 순서, 어떤 구조로 만들어 나가야 할 지 고민이었다.

 

 

3. 설계를 어떻게 할지

구현을 어떻게 해야할지 막막했다. 손이 가는대로 구현해볼까라는 생각도 했지만, 설계를 초기에 잘 해두어야 나중에 고생을 덜 할 것 같았기에 태블릿으로 여러 번 구조를 그렸다가 지웠다가 반복하며 초안을 어떻게 그려나갈지에 집중했다.

 

요런식으로 

 

4. MVC 패턴에 입각해서 짜보자.

• 도메인 - 도메인 구조

처음에는 MVC 패턴이 아닌 'Computer'와 'Player'라는 두 가지 도메인을 만들고 이런 흐름대로 해보려고 생각했다.

1. main에서 Computer를 호출
2. Computer에서 Player에게 Input 요청
3. Player에서 입력과 동시에 Input 값을 검증한 후 Computer에게 값을 전달
4. Computer에서 전달 받은 값을 통해 Score를 계산해서 Player에게 전달..

이렇게 두 도메인이 서로 문답하는 방식을 생각했었다. 문제는 이렇게 하면 볼륨이 커질수록, 도메인 코드가 너무 길어지기 때문에 클래스를 분리해야 하고 그렇게 되면 구조가 직관적으로 보이지 않을 우려가 있어 이 방식을 채택하지 않았다.

찾아보니 이와 같은 설계 방식을 도메인 주도 설계(Domain Driven Design)방식이라고 한다고 한다.

• MVC 패턴

MVC 패턴

MVC 패턴을 생각하니 Controller에 어떤 걸 만들고, View에 어떤 걸 만들고, Model에 어떤 데이터를 담을 지 등등 종합하여 대략 어떻게 구현을 해야할 지 보이기 시작했다.

 

5. 개인 연습용 브랜치 생성

아직 기능마다 커밋하는데 익숙치 않았고, 언제든지 구조가 변경될 수 있었기에 우선 연습을 해보고자 연습용 브랜치를 하나 생성하고 진행했다.

 

우선 요구사항에 대해 구현해야 할 기능들을 하나씩 구현하고 조립하는 방식으로 진행했다. 

 

먼저 다음 네 가지 클래스를 만들었다.

1) 우선 프로그래밍 요구사항에 작성된 라이브러리를 이용해 난수 3개를 생성하는 클래스 생성 (NumberGenerator)

2) 입력값에 대한 검증기 클래스 생성 (InputValidator)

3) 입력값을 스코어로 측정하기 전 컬렉션으로 변환하는 컨버터 클래스 생성 (StringToListConvertor)

4) 입력값에 대한 스코어를 측정 (ex. 1볼 1스트라이크, 3스트라이크, 낫싱) 하는 클래스와 메소드 생성 (ScoreCalculator)

 

 

이 후 Domain 패키지를 만들고 패키지 내부에 Baseball, Computer, Player을 만들고, Baseball 도메인에서 인스턴스 멤버를 Computer, Player로 설정하였는데 이렇게 하니 도메인이 도메인을 의존하여 어색한 느낌을 주었다.

 

그래서 결국 구조를 다음과 같이 새로 정립했다.

main에서 Controller를 통해 게임을 실행 -> Controller에서 Service를 통해 난수 생성 -> View를 통해 입력과 동시에 검증 -> Controller에서 Service를 통해 스코어 계산 -> View를 통해 출력  

6. 구현

구현 자체만 보면 그리 오래 걸리지 않았다.

다만 컨벤션에 어긋나는 아직 고치지 못한 습관들이 코드에 드문드문 조금씩 남아 있었다. 

 

 제일 큰 문제는 Controller의 start() 메소드 내부 while문 안에 if문, if문안에 또 if문이 들어가 indent가 3이 되어, 이로 인해 가독성이 나빠지고, 메소드의 응집도가 올라갔던 것. -> 구조를 바꾸면 고칠 수 있을 것 같다.

 

2023.10.16 - [📕 Spring/Java] - [Java] 객체지향 생활체조 원칙 9가지에 대해 알아보자 - indent 는 2 이상을 넘어가지 않도록 하자.

 

---

Day 2

코드를 리펙토링하고, 구조 변경점에 대해 생각해보았다.

1. 리펙토링

1. rename : (Output) 상수 PASS -> SUCCESS 변경

// private static final String PASS = "3개의 숫자를 모두 맞히셨습니다! 게임 종료";
 private static final String SUCCESS = "3개의 숫자를 모두 맞히셨습니다! 게임 종료";

게임에서 이겼을 때 출력할 메시지의 상수 이름을 PASS라고 네이밍 했었는데, PASS 보다는 SUCCESS나 WIN이 더 직관적인 네이밍이라고 생각해 변경했다.

 

2. ref : (BaseballGameController) 지역 변수 answer 필드 -> 인스턴스 필드로 변경 

• '지역변수로 사용하느냐, 인스턴스 필드로 사용하느냐'에 대한 고민이 있었다.
• 아직 명백한 답은 찾지 못했지만 각 특징은 생각해 볼 수 있었다.
  • 인스턴스 필드로 사용할 때 : 일반적으로 객체의 상태를 유지하고 공유해야 할 때는 인스턴스 필드를 사용.
  • 지역 변수 : 메소드가 종료되면 GC에 의해 메모리가 해제된다.
• 작성하면서 깨달은건데, 여기서는 인스턴스 필드로 사용하는 것보다, 지역 변수로 사용하는게 맞는 것 같다. 인스턴스 필드로 사용하면 멀티스레드 환경에서의 필드가 공유될 수 있다는 점을 간과했다.
  • 이렇게 수정했던 이유는 필드를 인스턴스 필드로 통일하여 가독성을 높이려는 의도였는데, 추후 지역변수로 다시 변경해야겠다. (answer 뿐만 아니라 result 또한)

 

3. ref : (BaseballGameController) indent depth 가 3 인 메소드 분리

수정 전

    public void start() {
        output.printStartMessage();
        List<Integer> answer = randomNumberGenerateService.getGeneratedNumbers();

        while (true) {
            output.printInputRequestMessage();
            result = scoreService.calculateScore(input.getInput(), answer);
            output.printResult(result);
            if (isAllStrike(result)) {
                output.printRestartOrExitMessage();
                if (input.getExit() == 1) {
                    answer = randomNumberGenerateService.getGeneratedNumbers();
                    continue;
                }
                break;
            }
        }
    }

 
수정 후

public void start() {
    output.printStartMessage();
    while (true) {
        answer = makeNewAnswer();
        playOneRound(answer);
        if (input.getRestartOrExit() == EXIT) {
            break;
        }
    }
}

private void playOneRound(List<Integer> answer) {
    while (true) {
        output.printInputRequestMessage();
        result = scoreService.calculateScore(input.getSubmit(), answer);
        output.printResult(result);
        if (scoreService.isAllStrike(result)) {
            output.printRestartOrExitMessage();
            break;
        }
    }
}

• indent 가 커지면서 가독성이 떨어지고, 응집도가 높아져 유지보수가 어려워 질 우려가 있었다.
  • 당장은 메소드를 분리하면서 depth를 2로 바꾸었지만 while문 내부의 if문도 메소드로 빼는 방안도 생각해봐야 할 것 같다.

4. InputValidator

InputValidator 클래스에서 변경점이 좀 있었다.
 
1. 우선 메소드 이름을 숫자가 아닌 문자열로 변경하였다.

//    public static boolean isBetween1And9(String input) {
    public static boolean isBetweenOneAndNine(String input) {
        if (input.chars().anyMatch(c -> c < '1' || c > '9')) {
            throw new IllegalArgumentException("입력값이 1~9 사이의 숫자가 아닙니다.");
        }

//    public static boolean isEqualTo1or2(String line) {
//        return line.charAt(0) == '1' || line.charAt(0) == '2';
    public static boolean isEqualToOneOrTwo(String line) {
        if (line.charAt(0) != '1' || line.charAt(0) != '2') {
            throw new IllegalArgumentException("1 또는 2만 입력해야 합니다.");
        }
        return true;
    }

 
2. InputValidator 클래스에서는 Player로부터 두 종류의 입력을 받는다.

• 첫 번째는 숫자 야구 게임에 대한 답을 제안하는 값
• 두 번째는 재시작/종료에 대한 값 이렇게 두 가지의 입력값.

이 두 가지의 입력값을 검증하는 로직들이 통일이 되어있지 않아 한 로직으로 통일하였다.

• 통일한 로직 : if문에서 예외조건을 검사하고 예외가 발생하는 케이스면 IllegalArgumentException을 던지고, 예외가 발생하지 않으면 true를 리턴하는 방식으로 통일

 

Before 

public static boolean isEqualTo1or2(String line) {
        return line.charAt(0) == '1' || line.charAt(0) == '2';
    }

 
After

public static boolean isEqualToOneOrTwo(String line) {
    if (line.charAt(0) != '1' && line.charAt(0) != '2') {
        throw new IllegalArgumentException("1 또는 2만 입력 가능합니다.");
    }
    return true;
}

 
 
 3. void validateXXX -> boolean isXXX

• 기존 : validateXXX 메소드를 Input 클래스에서 입력에 대한 검증을 할 때 validateXXX(line)를 호출하여 검증
• 변경 : 직관적으로 와닿지 않을 우려가 있어 boolean으로 변경하고 if(isXXX(line))으로 변경하였다.

 
Before

public static boolean validateInput(String input) {
    if (isThreeChar(input) && isNumber(input) && isBetween1And9(input) && isNotDuplicate(input)) {
        return true;
    }
    return false;
}

public static void validateExit(String line) {
    if (!isLengthOne(line)) {
        throw new IllegalArgumentException("1 또는 2만 입력해야 합니다.");
    }
    if (!isEqualTo1or2(line)) {
        throw new IllegalArgumentException("1 또는 2만 입력해야 합니다.");
    }
}

 
After

public static boolean isSubmitValid(String input) {
    if (isThreeChar(input) && isNumber(input) && isBetweenOneAndNine(input) && isNotDuplicate(input)) {
        return true;
    }
    return false;
}

public static boolean isRestartOrExitValid(String input) {
    if (isLengthOne(input) && isEqualToOneOrTwo(input)) {
        return true;
    }
    return false;
}

 

5. 패키지 구조 변경

Before / After

• util의 validator를 exception 패키지로 빼고, converter를 상위 패키지로 올렸다.
  • 근거 : util 패키지라고 이름 짓기에 직관적이지 않고, validator는 따지고 보면 예외를 검증하는 패키지기 때문에 exception 패키지로 빼는 것이 더 가독성이 좋다고 판단 

---

2. 구조 변경

현재 구조를 살펴보면
Model에는 Result 뿐이고, Domain이 하나도 없다. Model에는 View에 담을 데이터만 담으면 된다고 생각해서 Result 클래스 하나만 만들었는데, 상태를 저장하는 객체도 모델이 될 수 있다는 것을 간과하고 있었다.

 

Domain에 Player와 Computer를 생성하고 이 두 객체를 현재 상태를 담는 모델로 사용해서 Controller에서 이 두 모델로부터 데이터를 주고받도록 설계하는 것도 좋은 방법 중 하나인 것 같다.

 

이렇게 하면 점수를 계산하는 로직과 정답을 생성하는 로직을 Computer에 담고 Service 계층 자체를 삭제할 수 있다. 우선 내일 도메인은 만들어 서비스 로직을 두어 도메인에서 서비스의 역할을 하도록 할 지, 아니면 Computer, Player 도메인을 사용하지 않고 기존 방식대로 갈 지 고민해보아야 할 것 같다.

---

10/21 - Day 3

1. 리펙토링

어제 아이디어를 토대로 구조를 바꿔서 한 번 진행해보았다.

Before / After

• 구조가 바뀌면서 서비스 계층을 없앨 수 있었다. MVC 패턴이라 함은 스프링에서는 Controller 계층이 Service 계층을 통해 비즈니스 로직을 실행하지만, 지금 하는 미션은 순수 자바로 클리어해야하는 미션이니 Service 계층을 두는 것 보다 Model-Controller-View  3 Layer로 구현하는 것이 맞는 것 같다.

 

1. 새로 생성한 Model : Computer.class

public class Computer {
    private static final Integer BALL_SIZE = 3;
    private final static Integer FIRST_NUMBER = 1;
    private final static Integer LAST_NUMBER = 9;

    public List<Integer> getGeneratedNumbers() {
        List<Integer> answer = new ArrayList<>();
        while (answer.size() < BALL_SIZE) {
            int randomNumber = Randoms.pickNumberInRange(FIRST_NUMBER, LAST_NUMBER);
            addIfNotInList(answer, randomNumber);
        }
        return answer;
    }

 

Computer 모델에서 난수 3개(정답)를 생성하는 메소드, 점수를 계산하는 메소드를 두었다. 이렇게 하여 Service 계층을 삭제할 수 있었다. 두 기능을 한 클래스에 담으니 코드가 길어질 수 밖에 없었다. 추후 이 두 메소드를 클래스를 분리하여 짧게 줄여야겠다.

 

 

2. 새로 생성한 Model : Player.class

public class Player {

    private List<Integer> numbers;
    private Integer restartOrExit;

    public void inputNumbers() {
        String input = Console.readLine();
        if (!isInputNumbersValid(input)) {
            throw new IllegalArgumentException();
        }
        this.numbers = StringToList(input);
    }

    public void inputRestartOrExit() {
        String input = Console.readLine();
        if (!isRestartOrExitValid(input)) {
            throw new IllegalArgumentException();
        }
        this.restartOrExit = Integer.parseInt(input);
    }

    public List<Integer> getNumbers() {
        return numbers;
    }

    public Integer getRestartOrExit() {
        return restartOrExit;
    }
}

• Player는 두 가지 상태(필드)를 가진다.
  • 첫째, 숫자 야구 게임의 답을 제시하는 필드
  • 둘째, 숫자 야구 게임에서 승리하였을 때, 재시작/종료 여부를 제시하는 필드

inputXXX() 메소드로 현재 상태를 Console을 통해 입력받아 검증까지 마친 후 저장하고, getXXX()을 통해 현재 상태를 가져올 수 있다.

+ 이렇게 수정함으로써 BaseballGameController의 start() 메소드에서 indent depth를 1로 줄일 수 있었다.

 

 

수정 전 BaseballGameController.start() 

public void start() {
    output.printStartMessage();
    while (true) {
        answer = makeNewAnswer();
        playOneRound(answer);
        if (input.getRestartOrExit() == EXIT) {
            break;
        }
    }
}

 

수정 후  BaseballGameController.start() 

public void start() {
    printStartMessage();
    while (player.getRestartOrExit() != EXIT) {
        playOneRound(computer.getGeneratedNumbers());
        player.inputRestartOrExit();
    }
}

 

3. 기존의 Result(Model) 변경점 

1. Result 보다 Score 라는 이름이 더 직관적이여서 이름을 바꾸었다.

 

2. isAllStrike()를 ScoreService에서 검사했는데 서비스 계층을 없애고, 객체 자체에서 검증하도록 변경하였다.

• 생각해보면 Score를 ScoreService에서 검사하는 것 보다, Score에서 검증하는 것이 더 객체 지향적인 설계라고 볼 수 있다. (서비스 계층을 지우면서 자연스럽게 얻어걸린 느낌)
• 객체 지향적인 설계 방식을 체화하는 연습이 필요할 것 같다.

public class Score {

    private static final Integer THREE_STRIKE = 3;

	...

    public boolean isAllStrike() {
        return getStrike() == THREE_STRIKE;
    }
}

 

4. InputView 삭제 .. 이게 맞는걸까? 고민이지만 우선 바꾸어보았다.

View에는 '사용자마다 다르게 보여주어야 하는 데이터'를 담아야 한다. 그렇다면 공통으로 보여주어야 하는 데이터는 어떻게 처리해야 할까? 아직 고민이지만 바꾸어보았다.

 

기존 InputView에서 사용자에게 공통으로 보여주어야 하는 '입력에 관한 안내 메시지'를 담았다. 하지만 View에는 사용자마다 '다르게' 보여 주어야하는 데이터를 담아야 한다고 생각하니, InputView에서 수행하는 역할을 컨트롤러에서 수행하는 것이 맞는 것 같다고 생각해서, 컨트롤러로 메소드를 이동하고, InputView를 삭제했다.

 

게임 시작 메시지 출력 ( BaseballGameController.class )

public void printStartMessage() {
    System.out.println(START_MSG);
}

숫자 입력 요청 메시지 출력 ( BaseballGameController.class )

public void printSuggestNumberMessage() {
    System.out.print(REQUEST_NUMBER_MSG);
}

종료 여부 입력 요청 메시지 출력 ( BaseballGameController.class )

public void printRestartOrExitMessage() {
    System.out.print(REQUEST_RESTART_OR_EXIT_MSG);
}

 

 

2. 수정해야 할 사항들

1. BaseBallGameController의 playOneRound() 메소드의 indent depth가 2 

private void playOneRound(List<Integer> answer) {
    while (true) {
        printSuggestNumberMessage();
        player.inputNumbers();
        Score score = computer.calculateScore(player.getNumbers(), answer);
        outputView.printResult(score);
        if (score.isAllStrike()) {
            printRestartOrExitMessage();
            break;
        }
    }
}

• start() 메소드의 indent depth는 1로 줄일 수 있었지만, 아직 playOneRound()의 indent depth는 2로 유지되고 있다. 어떻게 바꿔야 indent를 1로 유지할 수 있을 지 생각해보아야 겠지만, 현재로선 좋은 아이디어가 떠오르지 않는다. 계속 고민해봐야 하는 문제이다. 

2. OutputView의 printResult() 메소드에서 score를 인자로 받아 score를 조건분기로 "검사" 하고 있다. 

public void printResult(Score score) {
    if (score.getBall() == 0 && score.getStrike() == 0) {
        System.out.println(NOTHING);
        return;
    } else if (score.getStrike() == 3) {
        System.out.println(THREE_STRIKE);
        System.out.println(SUCCESS);
        return;
    }
    System.out.println(score.getBall() + BALL + score.getStrike() + STRIKE);
}

• printResult라고 하면 result로부터 결과를 받아와 '출력'에 중점을 둔 메소드인데, 이 메소드에서 score를 '검사'하여 조건에 따라 출력을 달리하고 있는데, '출력'과 '검증'의 분리가 필요할 것 같다. 이 또한 아직 좋은 아이디어가 떠오르지 않아 고민해봐야 할 것 같다.

 

3. 아까도 언급했지만, Computer가 두 가지 기능을 담당하면서 코드가 길어지고 있다. 클래스 분리가 필요.

public class Computer {
    private static final Integer BALL_SIZE = 3;
    private final static Integer FIRST_NUMBER = 1;
    private final static Integer LAST_NUMBER = 9;

    public List<Integer> getGeneratedNumbers() {
        List<Integer> answer = new ArrayList<>();
        while (answer.size() < BALL_SIZE) {
            int randomNumber = Randoms.pickNumberInRange(FIRST_NUMBER, LAST_NUMBER);
            addIfNotInList(answer, randomNumber);
        }
        return answer;
    }

    private void addIfNotInList(List<Integer> answer, int randomNumber) {
        if (!answer.contains(randomNumber)) {
            answer.add(randomNumber);
        }
    }

    public Score calculateScore(List<Integer> playerInput, List<Integer> answer) {
        Integer strike = calculateStrike(playerInput, answer);
        Integer ball = calculateBall(playerInput, answer);
        return new Score(strike, ball);
    }

    public Integer calculateStrike(List<Integer> playerInput, List<Integer> answer) {
        return (int) IntStream.range(0, answer.size())
                .filter(index -> playerInput.get(index)
                        .equals(answer.get(index)))
                .count();
    }

    public Integer calculateBall(List<Integer> playerInput, List<Integer> answer) {
        return (int) IntStream.range(0, answer.size())
                .filter(index -> excludeStrike(playerInput, answer, index) && includeBall(playerInput, answer, index))
                .count();
    }

    private boolean excludeStrike(List<Integer> playerInput, List<Integer> answer, int index) {
        return !playerInput.get(index).equals(answer.get(index));
    }

    private boolean includeBall(List<Integer> playerInput, List<Integer> answer, int index) {
        return playerInput.contains(answer.get(index));
    }
}

• 50 line이 넘어갈 정도로 라인이 길어지고 있는데, 클래스를 분리해서 엔티티를 작게 유지해야 할 지 고민중이다.

 

4. Player의 필드들을 포장해야 할 지 고민. 

1. ’입력‘을 기준으로 보면 공통되는 필드인 두 필드를 하나의 클래스로 묶은 이후, 묶은 클래스 내부에서 값을 검증하도록 하여 상위 클래스에 과도한 책임을 주는 것을 막을 수 있을 것 같다.

public class Player {

    private List<Integer> numbers;
    private Integer restartOrExit;

 

+ 시도해본 결과, Player 도메인에서 필드의 상태에 대한 검사를 하는 '책임'이 과중되는 것을 막을 수 있었다. 

But 가독성이 떨어져 보였다..

Before

 

After

---

10/22 - Day 4

1.  제출용 브랜치 생성

어느정도 감을 잡았으니 본격적으로 제출용 브랜치를 만들고 진행했다. 

2.  리펙토링 

0. 어제 래핑한 Input 클래스를 래핑을 풀기로 결정.

다시 원래대로 ..

가독성이 떨어져 보이는 건 둘째치고 코드에 확신이 없어서 우선 다시 원래대로 바꾸었다. 

1. Controller에서 수행하던 입력 요구 메시지 출력 기능을 InputView 클래스를 생성해서 역할 위임

public class InputView {

    private static final String REQUEST_RESTART_OR_EXIT_MSG = "게임을 새로 시작하려면 1, 종료하려면 2를 입력하세요.";
    private static final String REQUEST_NUMBER_MSG = "숫자를 입력해주세요 : ";

    public void printSuggestNumberMessage() {
        System.out.print(REQUEST_NUMBER_MSG);
    }

    public void printRestartOrExitMessage() {
        System.out.println(REQUEST_RESTART_OR_EXIT_MSG);
    }
}

 

• View가 모델로부터 데이터를 받을 때, '사용자마다 다르게 보여주어야 하는 데이터에 대해서만 받아야 한다'는 룰을 "'뷰'에는 다르게 보여주어야 하는 데이터만 담을 수 있다"고 잘못 이해하고 있었다.
• InputView는 '모델로부터 데이터를 받지 않는다'. 그렇다면 다르게 보여주어야 하는 데이터를 출력하는 것은 문제가 없다..!
• 그래서 컨트롤러에서 수행하던 입력 요청 메시지 출력 기능을 InputView로 빼주었다. (사실 이것까지 컨트롤러가 수행하는 것도 너무 과중된다.)

+ 게임 시작에 관한 메시지 출력은 InputView로 빼지 않고 Controller에서 수행하도록 두었다. 

이유는 InputView는 입력에 관한 메시지, OutputView는 결과에 관한 메시지를 담고 있지만 게임 시작에 관한 메시지는 두 곳 모두 해당하지 않기 때문이기도 하고, 게임 시작에 관한 메시지는 하나 뿐이라 이를 위한 클래스를 파는 것 보다, 컨트롤러에서 이 하나쯤은 수행해도 문제없을 거라 생각해서.

public class BaseballGameController {

    private static final String START_MSG = "숫자 야구 게임을 시작합니다.";
    
    ...
   public void printStartMessage() {
        System.out.println(START_MSG);
    }
}

 

2. Controller의 playOneRound 메소드의 indent depth 줄이는 데 성공

수정 전

public void start() {
    printStartMessage();
    while (player.getRestartOrExit() != EXIT) {
        playOneRound(computer.getGeneratedNumbers());
        player.inputRestartOrExit();
    }
}

private void playOneRound(List<Integer> answer) {
    while (true) {
        printSuggestNumberMessage();
        player.inputNumbers();
        Score score = computer.calculateScore(player.getNumbers(), answer);
        outputView.printResult(score);
        if (score.isAllStrike()) {
            printRestartOrExitMessage();
            break;
        }
    }
}

 

수정 후

public void start() {
    printStartMessage();
    while (player.getRestartOrExit() != EXIT) {
        playOneRound(computer.generateNumber(), new Score(INIT_STRIKE, INIT_BALL));
        player.inputRestartOrExit();
    }
}

private void playOneRound(List<Integer> answer, Score score) {
    while (!score.isAllStrike()) {
        inputView.printSuggestNumberMessage();
        player.inputNumbers();
        score = computer.calculateScore(player.getNumbers(), answer);
        outputView.printResult(score);
    }
    inputView.printRestartOrExitMessage();
}

• score에 initial 값을 넣고 argument로 넘기니 if문을 써주지 않고 바로 while문에서 검사하게 변경할 수 있었다. 이로써 indent depth는 1이 되었다. 뿌듯하다.

 

+ 가독성을 위해 메소드명을 바꾸고, 컨벤션에 맞지 않는 코드들을 수정해 나가면서 제출용 브랜치에 기능별로 커밋하니 하루가 다 지나갔다. 

---

10/23 - Day 5

원래 오늘은 약간의 리펙토링 이후 테스트 코드 작성에 힘을 주려 했지만 어찌하다보니 리펙토링과 디버깅하는데 많은 시간을 쏟게 되었다.

1. util 패키지

model도아니고 view도아니고 controller도 아닌 클래스들은 'util'이라는 패키지로 묶으니 직관성이 떨어져 보였다. 무엇보다도 util에 많은 클래스들이 분포하다 보니, 이 역할을 도메인에서 수행할 수 있지 않을까 싶기도 했다.

util 패키지를 보면 NumberGenerator, ScoreCalculator는 Computer에서 사용하고, InputValidator, StringToIntegerListConverter는 Player에서 사용한다.  NumberGenerator가 하는 기능을 Computer에 구현하면 NumberGenerator 클래스를 삭제해도 되지 않을까? 생각하다가 떠올린 것이 '일급 컬렉션'이다. 

 

"일급 컬렉션"을 적용한 구조는 이렇다.

Computer가 GameAnswer, Score의 인스턴스 멤버변수를 가진다.

 

하나씩 알아보자.

 

Computer

 

GameAnswer

• 이 때 GameAnswer는 List<Integer> answer와, makeAnswer()라는 인스턴스 멤버를 가지는데, makeAnswer()에 NumberGenerator가 하는 역할을 구현하여 answer필드에 생성한 숫자를 할당해주는방식이다.

Score

• Integer strike, Integer ball이라는 필드와, calculate()라는 메소드를 가지고 있다.
• calculate() 메소드에 ScoreCalculator가 하는 역할을 구현하여 점수를 계산한다. 계산한 값은 strike, ball에 값을 할당해준다.

 

Player

 

GuessNumbers

• List<GuessNumber> guessNumbers 필드와, validateGuessNumbers() 메소드를 가진다.
• 여기서 GuessNumber는 사용자가 입력한 3개의 숫자 중 하나의 숫자를 말한다. 
  • GuessNumber
  • Integer number 필드와 validateGuessNumber() 메소드를 가진다.
  • validateGuessNumber() 메소드로 입력한 숫자 '하나'에 대한 검증이 이루어진다. 
• validateGuessNumbers()에서는 입력한 숫자 3개에 대한 검증이 이루어진다. 검증에 성공하면 List<GuessNumber> guessNumbers에 값이 할당된다.

 

일급 컬렉션을 적용하니 클래스가 분리됨으로써 책임이 분리되니 코드가 조금 더 객체지향적으로 바뀌는 것을 볼 수 있었다.

 

2. ApplicationTest의 테스트코드가 돌아가지 않는 문제

• 구현이 완료되면 ApplicationTest의 모든 테스트가 성공해야 한다. 
• 문제는 미션에서 제시한 두 가지의 테스트 코드를 하나씩 돌리면 성공하는데, 전체를 실행하니 두 번째 테스트코드가 동작하지 않는 것이었다.

실행 결과

분명 메인 코드를 실행하면 길이가 3초과인 입력에 대해서 예외가 잘 발생하는데 도저히 알 수 없는 노릇이었다.

결국 이전 테스트가 다음 테스트에 영향을 준다는 것인데.. 왜 영향을 주는 것일까?

 

"하나씩 돌아가면 성공" + "전체를 돌리면 실패" + "예외를 잡지 못했다는 메시지만 출력"  + "메인에서는 예외를 잘 잡음" =  도대체 문제가 무엇인가..

 

메인 로직에 문제가 있나 살펴봤지만 문제도 없었다.

 

결국 이것저것 시도해보다가 혹시나 GameStateNumber enum이 문제인가 싶어, enum을 class로 변경해 보았다.

public enum GameStateNumber {

    DEFAULT(0), RESTART(1), EXIT(2);

    private Integer stateNumber;

    GameStateNumber(Integer stateNumber) {
        this.stateNumber = stateNumber;
    }

    public void input() {
        String input = Console.readLine();
        validateGameStateNumber(input);
        this.stateNumber = Integer.parseInt(input);
    }

    private void validateGameStateNumber(String input) {
        if (!isGameStateNumberValid(input)) {
            throw new IllegalArgumentException();
        }
    }

    public boolean isExit() {
        if (this.stateNumber == EXIT.stateNumber) {
            return true;
        }
        return false;
    }
}

 

추측컨데, 제시해 준 테스트 코드에서는 enum에서 던진 예외를 받지 못하는 것 같았다. 제시해준 테스트 코드를 수정할 수는 없는 상황이라 그냥 enum을 class로 바꾸어서 진행하기로 했다.

 

수정 후

public class GameStateNumber {

    private static final Integer START = 1;
    private static final Integer EXIT = 2;

    private Integer stateNumber;

    public GameStateNumber() {
        this.stateNumber = START;
    }

    public void input() {
        String input = Console.readLine();
        validateGameStateNumber(input);
        this.stateNumber = Integer.parseInt(input);
    }

    private void validateGameStateNumber(String input) {
        if (!isGameStateNumberValid(input)) {
            throw new IllegalArgumentException();
        }
    }

    public boolean isExit() {
        if (this.stateNumber == EXIT) {
            return true;
        }
        return false;
    }
}

 

'설마 이건가?' 했던 것이 얻어 걸린 느낌이라 후련하기도 했지만, 디버깅 과정이 참으로 순탄치 않았다. 

---

10/25 - Day 6

오늘은 기어코 테스트 코드를 작성하겠다고 다짐했건만, 자꾸 더 코드를 좋게 바꾸고 싶은 욕심이 더 컸다.

 

여러 시행착오가 많았지만, 굵직굵직한 리펙토링들만 모아서 살펴보자.

1. CommonView 도입

 OutputView에서는 게임에 대한 플레이어의 점수를, InputView에서는 입력에 대한 안내 메시지를 출력한다. 그렇다면 사용자에게 공통으로 보여주어야 할 메시지는 어디에 두어야 할까?

 

공통적으로 보여주어야 할 메시지가 하나뿐이라 이걸 위해 View를 만들기도 애매해 보였고, Controller에서 이 하나쯤은 수행해도 되지않나 싶기도 했다. 그래서 Controller에서 게임 시작에 관한 메시지를 출력하고 있었다. 하지만 공통으로 보여주어야 할 메시지가 많아지면  어차피 View 클래스를 하나 더 만들어야 한다고 생각하니, 미리 역할에 맞게 분리하는 것이 옳다고 생각하여 CommonView 클래스를 만들었다. CommonView에서는 사용자에게 공통으로 보여 주어야할 메시지의 출력을 담당하도록 설정했다.

 

 

2. InputValidator 분리  

기존 InputValidator에서 많은 기능을 담당하고 있었다. -> 숫자 1개에 대한 검증, 숫자 3개에 대한 검증, 게임 상태 숫자에 대한 검증 

 

그래서 이 InputValidator를 3개의 클래스로 나누어 숫자 1개에 대한 검증, 숫자 3개에 대한 검증, 게임 상태 숫자에 대한 검증을 분리하였다.

 

• GuessNumberValidator(숫자 하나를 검사 - 1~9사이의 숫자인지)
• GuessNumbersValidator(숫자 3개를 검사 - 중복, 길이 ) 
• GameStateNumberValidator(숫자 1 or 2인지 검사)

 

3. ScoreCalculator를 다시 만듦

Score에 ScoreCaluator가 하는 기능들을 구현하니 도메인 코드가 엄청 길어졌었다. 이대로 갈까, 다시 분리할까 고민하다가 ScoreCalculator를 util로 다시 뺴내고 Score 클래스의 calculate() 메소드는 ScoreCalculator의 정적 멤버 메소드를 사용하도록 변경했다. 

 

---

10/25 - Day 7

0. 테스트 코드 작성 

오늘은 테스트 코드 작성에 힘을 들였다.

원래라면  '1.구현 -> 2.테스트' 순서로 진행해야 하지만, 테스트 코드 작성에 익숙치 않아서 모든 구현이 끝난 후 테스트 코드를 작성하는 순서로 진행했다. 순서에 대해서 알아보다가 테스트를 먼저 작성하고 실제 코드를 구현하는 TDD(Test Driven Development)라는 방법론이 대해서도 알게 되었다.

 

TDD란? 테스트 주도 개발 - 하나몬

 

읽어보면 좋은 개발 방식이라고 생각은 되지만, 당장 프리코스에서 진행하기엔 개발 방식을 아예 바꾸어야 할 것 같아 생산성이 많이 떨어질 것 같다. 이 부분은 프리코스가 끝나면 한 번 공부해 봐야겠다.

 

각설하고 이번 미션에서 모든 구현이 끝난 후 테스트 코드를 작성했다고 했는데 테스트 코드를 작성하면서 이 순서는 정말 좋지 않다고 느꼈다. 코드에 버그가 발생하면 직접 메인을 실행시켜 버그가 발생하는 지점을 찾기 일쑤였는데, 기능 구현 이후 바로 테스트 코드를 작성한다면 이런 낭비되는 시간들을 많이 줄일 수 있을 것 같다. 2주차 미션부터는 이 테스트를 잘 활용해야겠다.

 

* 테스트 코드는 최하단 링크 참조

---

전반적인 1주차 후기 

자는 시간이 아까울 정도로 즐거웠던 한 주 였습니다.

 

알고리즘만 보면 첫 주차 미션의 기능적인 요구사항들은 어렵지 않았습니다. 그만큼 문제를 출제하신 분들께서 이번 미션에서는 분명 ‘좋은 설계’에 대해 고민하고 생각해보라는 취지로 미션을 내신 것이라 생각합니다. 그리하여 저는 이번 미션에서 ‘좋은 설계’라는 하나의 목표를 달성하기 위해서, 3가지의 목표로 세분화하여 진행했습니다.

 

1. 가독성 좋은 코드 작성하기

코드를 읽는 사람이 읽기 편하게 작성하는게 가장 중요하다고 생각했습니다. 이번 주차가 끝나면 피어 코드 리뷰를 진행할텐데, 제가 아무리 설계를 잘했다 한들, 가독성이 엉망이라면 누구라도 읽기 싫을 것이 분명하기 때문입니다.

 

프로그래밍 요구사항에 제시해주신 컨벤션 말고도 서칭해보니 자바 코드를 작성하면서 지켜야 할 컨벤션들이 문서화되어 있었습니다. 이 중에 알고 있던 것들도 있고, 모르고 있던 것들도 많았습니다. 가독성이 떨어져 보이는 제 코드들은 컨벤션을 어기고 있는 경우가 많았는데, 확실히 문서를 읽고 코드를 작성하고, 읽고 작성하고 반복하다 보니 컨벤션을 지키는 것이 가독성을 끌어올리는 데 많은 도움이 되는 것을 체감할 수 있었습니다. 컨벤션 뿐만 아니라 메소드명, 필드명, 클래스명에 대한 고민도 정말 많이했습니다. ‘어떻게 작성해야 이름을 보고 의도를 바로 캐치할 수 있을까?’에 대해 많이 생각하며, 더욱 가독성 좋은 코드가 될 수 있도록 노력할 수 있었던 한 주 였습니다.

 

 

2. 객체지향 생활체조 9가지 규칙 준수하기

프리코스를 시작하기 전, 객체지향 생활체조 9가지 규칙을 공부했었습니다. 처음에는 이 9가지 규칙을 보고 ‘이 규칙들을 어떻게 안 어기면서 코드를 짤 수가 있지..?’라고 생각했었습니다.

 

왜 이런 규칙들을 정해 놓았는 지는 구현을 하고 난 후 규칙에 입각해서 리펙토링을 진행할 때 정확히 캐치할 수 있었습니다.

특히 일급 컬렉션을 적용할 때 정말 크게 감명 받았습니다. 저는 숫자게임에서 플레이어가 입력하는 숫자게임에 대한 3개의 숫자를 일급 컬렉션으로 관리했는데, 이렇게 설계하니 “1개의 숫자”에 대한 검증을 단일 클래스에서 검증하고, “3개의 숫자”에 대한 검증은 일급 컬렉션에서 하니 기능도 분리되고, 역할과 책임이 깔끔하게 나누어졌다는 것을 크게 체감했습니다.

 

이런 규칙들이 어느정도 체화되고 좋은 설계에 대해 고민할 시점에는 이 규칙들을 적용하니 좋은 설계가 되었다는 느낌보다, “객체지향적인 설계를 지향하니 이런 규칙들이 자동적으로 따라온다” 느낌을 크게 받았습니다. 개인적으로 이번 한주간 '이런 코드 객체지향적인 설계구나, 이렇게 작성하면 좋은 코드가 될 수 있겠다.’고 많이 느꼈던 것 같습니다.

 

 

3. MVC 패턴 정립하기

처음에는 기능 요구사항들을 작성하고 컴퓨터와 플레이어 두 개의 클래스를 만들고 이 클래스를 서로 의존시킨 후, 컴퓨터와 플레이어가 서로 문답하는 방식으로 문제를 해결하려고 생각했습니다. 이러면 한 클래스에 코드가 엄청 길어지고 객체 지향적인 설계와는 거리가 멀어지기도해서 처음에 어떻게 구현할 지 테블릿에도 그려보면서 고민하는 시간이 정말 길었습니다.

 

각종 시행착오를 겪다가 Spring을 공부하면서 알게 된 MVC 패턴을 적용하면 좋을 것 같다는 생각으로 MVC 패턴을 채택해서 미션을 진행했습니다. 처음에는 단순하게 이 패턴을 적용하기만 하면 객체 지향적인 설계를 가져감과 동시에 미션을 클리어 할 수 있을 것 같았는데, 현실은 전혀 그렇지 않았습니다. MVC 패턴을 잘 알고 있다고 생각해 패턴에 맞춰서 구현하고 보니, 코드에 좋은 설계라 하기에는 조금씩 불편한 부분들이 있기도 했고, 놓치고 있는 부분들이 많았습니다. 앞으로의 미션들도 이 MVC 패턴에 입각하면 많은 도움이 될 거라 생각해 이번을 기회 삼아 확실하게 다시 한번 MVC 패턴을 공부할 수 있었습니다.

 

패턴을 다시 한번 공부하고 코드를 보니 리펙토링할 부분들이 보이기 시작했습니다. 사실 구현만 보면 정말 빨리 끝났는데, 리펙토링하는 과정이 정말 길었습니다. 추가로 MVC 패턴 내에서도 리팩토링 과정이 끝나고 코드를 보면 더 좋은 구조가 생각나고, 좋은 구조가 생각나면 과감하게 구조를 뜯어 고치면서 좋은 코드를 만들려고 노력했습니다. 이 덕에 생각하고 고쳐보고, 생각하고 고쳐보고 하는 과정에서는 객체지향적인 사고력을 많이 끌어 올릴 수 있었던 한 주였습니다.

 

+ 처음에는 리펙토링한 것들을 하나하나 모두 세부적으로 기록하려 했는데, 생각보다 글이 길어지기도 하고 처음부터 읽어보니 전체적으로 두서가 없는 느낌이 강해 2주차부터는 회고도 회고지만 미션에 온전히 더욱 집중하며 회고록은 굵직굵직한 리펙토링이나 사고과정에서 깨달은 것들 위주로 작성할 예정입니다. 감사합니다.

---

미션에 관한 제 코드는 아래 링크에서 확인하실 수 있습니다.
 

GitHub - Dongwoongkim/java-baseball-6

---

<이번 미션을 참여하면서 도움이 되었던 참고 자료>

 

2023.10.16 - [📕 Spring/Java] - [Java] 객체지향 생활체조 원칙 9가지에 대해 알아보자

[Java] 객체지향 생활체조 원칙 9가지에 대해 알아보자

https://www.youtube.com/watch?v=ogaXW6KPc8I

[IntelliJ] 코드 스타일을 설정해보자 (feat.우테코)

Google Java Style Guide 정리

MVC 패턴 , 5 Layer 패턴