[우아한 테크코스 5기 프리코스] FE 4주차 회고록

우아한 테크코스 포스터

우아한 테크코스 프리코스 4주차까지 모두 끝났다. 이번 미션을 할 때 코로나에 확진이 되어서 사실 제대로 집중하지 못했다. 아니 거의 못했다. 이번 미션을 겨우 하면서 가장 어려운 것은 테스트 코드 통과다. 첫 번째 테스트 단계도 겨우 통과했다. 그 다음 테스트 단계를 통과하지 못했는데 그 이유를 아직도 찾고 있다. 

1. 우아한 테크코스 프리코스 4주차 과제

다리 건너기

4주차 과제 내용

전 세계적으로 유명한 시리즈 "오징어 게임"을 아는가? 그렇다면 오징어 게임에서 다리를 건너는 게임도 알 것이다. 바로 그 다리 건너기 게임을 구현하는 것이 4주차 미션이었다. 0부터 1까지 랜덤 숫자가 주어지며 0이면 Down, 1이면 Up에 해당이 된다. 성공하면 O, 실패하면 X를 출력하며 게임을 재시작할지 아니면 끝낼지 결정하면 끝이다.

 

이번 미션에는 저번 미션과 비슷하지만 추가된 것은 클래스 혹은 메소드를 분리하는 것과 리팩토링이다. 메소드를 기능마다 더욱 세세하게 나누는 연습을 하고 리팩토링을 진행하는 것이 이번 미션의 목적이었다. 이번 미션을 진행하면서 저번보다 시간이 더 부족하였기 때문에 리팩토링보다는 메소드를 기능마다 세세하게 나누는 연습에 집중했다. 메소드마다 10줄을 넘으면 안됐기 때문에 더욱 나눌 수 밖에 없었다. 추가적으로 매개변수가 3개가 넘으면 안됐다. 조건이 많아지니 구현이 매우 어려웠다. 기능마다 메소드를 나누는 것보다 매개변수가 3개까지 사용하는 것이 어려웠다. 구현을 할수록 메소드를 나누고 메소드를 나눌수록 필요한 인자가 있었는데 3개가 넘는 경우도 있었다. 그래서 클래스의 Constructor에 전체적으로 사용할 변수를 선언해 최대한 매개변수를 줄이도록 노력했다.

 

미션을 진행하면서 구현을 마쳤는데 막상 실행을 해보니 테스트 코드에서 모두 통과하지 못했다. 도저히 알 수가 없었다. 첫 번째 테스트 코드의 문제점을 알아내는데 며칠이 걸렸다. 나중에야 알았는데 테스트 코드에서 진행할 때는 문자열로 진행하고 실제 구현한 코드에서는 숫자로 진행해 에러가 날 수 밖에 없었다. 그래서 실제 구현한 코드도 문자열로 수정해 구현했더니 통과가 됐다. 문제는 그 다음이었다. 기능 테스트가 있는데 처음에는 잘 진행이 됐지만 코드가 수정되면서 더 이상 진행이 되지 않았다. 에러가 계속 발생하였다. 도저히 문제점을 찾을 수가 없어서 다른 사람들의 코드를 참고하였지만 그래도 문제를 해결하지 못했다. 결국 제출 마감 시간이 되어 실패한 상태로 제출하게 됐다.

 

비록 미션은 실패했지만 배운 것은 많았다.

• 단위 테스트에 대해 더 고민하게 됐다는 것
• 메소드(함수)를 짧게 작성하는 연습을 했다는 것
• 매개 변수를 최소한으로 사용하는 연습을 했다는 것

2. 코드로 기능 구현

이번 미션은 시간이 부족했기 때문에 리팩토링을 생각하지 않고 구현에만 집중했다. 기능 구현을 하고 나서 나중에 시간이 있으면 리팩토링을 하는 것으로 계획을 세웠다.

class App {
  constructor() {
    this.tryCount = 1;
    this.bridgeArray = [[], []];
    this.bridgeGame = new BridgeGame();
  }
}

우선 공통적으로 사용할 변수들을 선언했다. 게임 시도를 위한 변수와 Up, Down을 저장할 2차원 배열 변수 그리고 실제 게임을 구동할 클래스를 호출해 선언하였다.

 play() {
    OutputView.printStartMessage();
    InputView.readBridgeSize();
  }

  makeLength() {
    const bridgeLength = InputView.readBridgeSize();
    this.makeBridge(bridgeLength);
  }

  makeBridge(length) {
    const makeBridge = BridgeMaker.makeBridge(length, BridgeRandomNumberGenerator.generate());
    let resultBridge = [[], []];
    this.userMove(length, makeBridge, resultBridge);
  }

그리고 App 클래스에서 호출해 테스트 코드에서 실행할 play 메소드에서 게임 시작 메세지와 그 다음 단계 진행을 담당하는 메소드를 호출하였다.

그리고 사용자가 다리 건너기 게임을 위해 다리 개수를 지정하는 입력값을 받도록 하였다.

그 다음에 0과 1이 랜덤으로 호출되어 해당 값으로 다리를 생성하는 BridgeMaker의 makeBridge 메소드에 입력받은 다리 개수와 랜덤 숫자 발생 메소드를 매개변수로 지정해 생성된 다리를 호출받도록 하였다.

그리고 게임이 진행되는 동안 다리들을 저장할 2차원 배열을 선언해 실제로 사용자가 움직임을 입력할 메소드에 전달하였다.

userMove(length, Bridges, resultBridge) {
    for (let i = 0; i < length; i++) {
      const userMoveInput = InputView.readMoving();
      resultBridge = this.bridgeGame.move(userMoveInput, Bridges, this.bridgeArray);
      OutputView.printMap(resultBridge);
      if (this.failCheck(resultBridge)) return this.restartCheck(length, Bridges, resultBridge);
    }
    OutputView.printResult(SUCCESS_MESSAGE, this.tryCount, resultBridge);
  }

  failCheck(resultBridges) {
    if (resultBridges[0].includes('X') || resultBridges[1].includes('X')) return true;

    return false;
  }

  restartCheck(length, Bridges, resultBridge) {
    const userDecision = InputView.readGameCommand();
    const userResult = this.bridgeGame.retry(userDecision);
    if (!userResult) {
      OutputView.printResult(FAIL_MESSAGE, this.tryCount, resultBridge);
    }
    if (userResult) {
      this.tryCount += 1;
      this.bridgeArray = [[], []];
      resultBridge = [[], []];
      this.userMove(length, Bridges, resultBridge);
    }
  }

그리고 사용자가 입력한 다리 개수, 랜덤 숫자로 생성된 다리가 저장된 배열, 사용자가 입력한 움직임과 다리 배열을 비교해 저장할 2차원 배열을 인자로 받아서 게임을 동작하도록 했다. 다리 길이만큼 반복해서 사용자가 Up 혹은 Down을 입력받도록 하였다. 사용자의 움직임, 생성된 다리 배열, 공통적으로 저장된 다리를 담은 2차원 배열을 매개변수로 실제 게임을 위한 메소드로 전달하였다. 여기서 사용자 입력값과 배열에 저장된 값을 같은 값인지 다른 값인지 비교해 전달받은 2차원 배열에 담도록 하였다. 그리고 비교 후 담겨진 배열을 실제로 Console에 출력하였고 그 다음 전달받은 값이 같은 값인지 다른 값인지 체크하도록 하였다.

 

다른 값이라면 True를 Return 받도록 하였으며 다른 값이라면 재시작을 확인할 메소드가 출력되도록 하였다. 다른 값인지 확인하는 방법은 2차원 배열에 'X' 값이 있는지 확인하여 처리하였다.

 

재시작을 위한 사용자의 입력값을 받고 Retry 메소드에 입력값을 체크하도록 하였다. 'R'을 입력하면 재시작을, 'Q'를 입력하면 종료하도록 하였다. 종료를 입력한다면 지금까지 생성된 다리를 출력하고 게임 시도 횟수와 게임 실패 메세지를 출력하도록 하였다. 반대로 재시작을 선언하면 게임 시도 횟수를 하나 더하고 생성된 다리를 저장할 2차원 배열을 초기화해 게임 구동을 담당하는 메소드를 재호출하도록 하였다.

3. 4주차 과제를 하고 나서 느낀 것

(1) 기능마다 메소드를 나누는 것

나는 하드코딩을 하는 유형이였다. 한 번에 작성하는 것이 집중력도 계속되고 생각을 적게 할 수 있기 때문이다. 그런데 나중에 보면 이해하기 어렵거나 오류를 찾을 때 어려움을 많이 겪었다. 이번에 제대로 배운 것은 메소드는 나눌 때마다 좋다는 것이다. 기능마다 메소드를 나누어 필요할 때마다 호출해 사용하면 코드도 짧아져 더 이해하기 쉽다는 것을 더욱 깨달았다. 물론 메소드가 많아지면 이해하는데 시간이 필요하긴 하지만 하드코딩한 것보다 훨씬 좋았다.

 

(2) 최소한의 매개변수를 사용하는 것

매개변수를 줄이는 것이 굉장히 어렵다는 것을 다시 한 번 느꼈다. 메소드를 많이 나눌수록 매개변수로 그 만큼 많이 전달하게 되는데 정해진 매개변수 갯수 안에서 전달해야 한다는 것이 쉬운 일이 아니었다. 코드를 최대한 수정해서 기존 매개변수를 없애거나 최대한 매개변수를 줄이는 방법을 고민하고 고민하고 계속 고민했다. 이번 미션에서는 매개변수 3개 제한이 조건이었고 겨우겨우 조건을 지키기 위해 노력했지만 만약 더 큰 프로젝트였다면 아마 어려웠을 것이다. 최소한의 매개변수를 사용하는 방법은 계속해서 고민하고 생각해야 될 것 같다.

 

(3) 리팩토링을 하는 것

이번 미션에서는 진행하지 못했지만 리팩토링을 해야겠다는 생각은 항상 하게 된다. 코드가 더러울수록 더 깨끗하게 보이도록 만들고 싶어졌다. 내가 작성한 코드를 다른 사람들이 이해하기 쉽도록 만들고 싶어졌다. 이것이 바로 리팩토링이 필요한 이유라는 것도 더 느꼈다. 미션은 끝이 났지만 못했거나 모자랐던 부분을 찾아서 하나씩 수정해보며 리팩토링을 해보려고 한다.

 

4. 부족한 것

(1) 집중력

핑계를 대자면 코로나 확진으로 몸도 정신도 힘들었다. 그래서 전보다 더 집중하기 어려웠다. 그러나 충분히 더 집중할 수 있었는데 스스로 아프다는 이유로 놓아버린 것도 있는 것 같다. 집중력을 더 키워야겠다는 생각이 많이 들었다. 아프다는 이유와 상관없이 문제를 해결하겠다는 목적을 이루기 위한 집중력을 키워야겠다.

 

(2) 문제점 찾기

테스트 코드로 미션을 진행하는데 정확한 문제가 어디서 발생했는지 알기 어려웠다. 디버그를 해서 문제점을 찾고 싶었지만 이마저도 쉽지 않았다. 문제점을 찾는 방법이 아직 미숙하다. 그래서 발생한 또 다른 문제인 것 같다. 디버그, 코드로 문제점을 발견하는 방법을 꾸준하게 몸으로 익히도록 해야겠다.

 

(3) 네이밍

메소드의 이름을 짓는 것은 날이 지날 때마다 어렵다고 느낀다. 어떻게 지어야 모두가 쉽게 이해할 수 있을지 고민을 해도 정답이 나오지가 않는다. 이름을 제대로 짓는다는 것이 이렇게 어려운 줄 몰랐다. 네이밍을 할 때 동사형으로 지어야한다는 것, 네이밍이 길어도 된다는 것을 머리속에 있지만 쉽지가 않다. 나만 이해하는 네이밍이 아닌 모두가 이해하기 쉬운 네이밍을 짓는 고민을 계속해서 필요한 것 같다.

 

5. 마무리

마지막을 아쉽게 끝냈다. 제대로 미션을 완료하지 못했다. 그렇지만 결과보다 과정 속에서 얻는 배움이 많았다. 그 동안 내가 해보지 않았던 프로그래밍을 해봤고 정보들도 습득했다. 대략적으로 어떻게 구현을 해야되는지 어떤 방향으로 나아가야 하는지 이해할 수 있었다. 1주차부터 4주차까지 진행한 미션들을 끝내지 않고 다시 복습하여 부족하다고 보이는 부분을 수정해가며 더 좋은 방향으로 나아가는 연습을 해야겠다. 4주간 좋은 경험을 했다.