📖우테코 5기 프리코스 2주차 회고

🎯주제

프리코스 2주차 주제는 숫자야구 게임이었다. 사실 4기 프리코스 미션을 미리 풀어봤었기 때문에 나름 익숙한 주제였다. 하지만 이번 미션은 4기 미션과는 달리 html을 전혀 다루지 않았고, 테스트 코드를 직접 작성하라는 요구사항이 추가되어 조금 색다른 느낌이었다.

😖어려웠던 점

❗테스트 코드 작성

지난주 미션과는 달리 이번주 미션은 추가된 요구사항이 꽤 많았다. 기능을 너무 복잡하지 않게 구현하는 요구사항들이 몇가지 있었고, 협업을 위해 컨벤션을 지키라는 요구사항과 테스트 코드 관련 요구사항이 추가되었다. 이 중 가장 생소한 내용은 테스트 코드 작성이었다. 그동안 개인 프로젝트를 진행하며 한번도 테스트 코드를 작성해본 적이 없었고, Jest라는 녀석도 이번에 처음 봤다. 그래서 당연하게도 가장 어려웠던 점 중 하나였다.

다행히도 이미 주어진 테스트 코드가 ApplicationTest.js, StringTest.js 이렇게 두 가지나 주어져 있었고

리드미에 친절히 그 내용을 참고해서 공부하라는 말도 적혀있었다. 공식문서도 나름 자세히 나와있는 것 같아 아주 가끔 공식문서의 내용도 참고했다.

Jest의 공식 문서를 보면 테스트 코드의 예시가 다음과 같이 주어진다.

사용 방식은 크게 어렵지 않았다. 먼저 package.json에

{
  "scripts": {
    "test": "jest"
  }
}

위와 같은 코드를 추가하고, npm test를 실행하면

위와 같은 결과를 확인할 수 있다고 나와있다.

이를 통해 test의 첫번째 인자로 주어진 문자열을 통해 어떤 테스트인지를 명시해주고, 두번째 인자로 주어진 콜백 함수 내부의 expect에 참값이 주어지면 테스트가 통과됨을 알 수 있었다.

test('볼과 스트라이크가 함께 있을 때는 "~볼 ~스트라이크"가 출력된다.', () => {
    const correctNumber = ["123", "456", "789", "159", "753"];
    const inputNumber = ["321", "461", "981", "519", "715"];
    const answer = [
      "2볼 1스트라이크",
      "1볼 1스트라이크",
      "1볼 1스트라이크",
      "2볼 1스트라이크",
      "1볼 1스트라이크",
    ];

    for (let i = 0; i < 5; i++) {
      expect(getHint(correctNumber[i], inputNumber[i])).toEqual(answer[i]);
    }
  });

위 코드는 실제로 작성했던 테스트 코드의 일부이다. 테스트 하고자 했던 기능은 힌트를 산출하는 getHint 함수의 정상 동작 여부였다.

getHint 함수는 정답과 사용자 입력값을 인자로 받아 힌트를 출력하는 함수이다. 이를 테스트 하고자 가상의 정답, 입력값을 배열로 만들고, 이 값들에 해당하는 힌트 또한 배열로 만들었다. 반복문을 작성하여 getHint에 가상의 정답, 입력값을 전달해 주었고 Jest의 toEqual matcher를 사용하여 출력값이 미리 작성한 힌트와 일치하는지 확인했다.

다 적고 보니 보잘것 없어 보이긴 하지만 저 코드를 작성하기 위해 들인 시간이 생각보다 길었다. 저런 간단한 테스트는 이제 수월하게 작성할 수 있지만, 가상 함수 mock function을 만들어 테스트 하는 기능은 이번주 미션완료까지 확실히 공부하지 못했다. 오늘(11/09) 사랑니를 빼러 가는 날이라 통증이 좀 줄어들 11/12까지 mock function을 분석해 포스팅 하겠다. (데드라인을 안잡으면 절대 안하는 성격이라 블로그에 적어두었다)

mock function 분석
이젠 안아플 줄 알았는데 아직도 뽑은 자리가 따갑다... 매복이라 그런가 ㅠㅠ 그래도 약속한 내용이니 지켜 적어보았다.(11/12)

참고로 공식문서를 검색할 때는 "검색하고자 하는 대상 docs"로 검색하면 된다. ex) "javascript docs", "node.js docs"
최근에 알게돼서 적어본다

❗모듈 내보내기

미션을 수행하다보니 하나의 기능을 완성하기 위해 여러 작은 함수들을 구현하게 되었고, 그렇게 함수들이 많아지다 보니 너무 지저분해 보이게 되었다. 깔끔하게 고쳐보고자 기능 단위로 묶어 다음과 같이 함수들을 정리하고자 했다.

export default function 아래 세 함수를 사용해서 힌트를 반환하는 함수(){~~~};
                                                    
function 스트라이크 개수 계산 함수(){~~~};
function 볼 개수 계산 함수(){~~~};
function 스트라이크, 볼 개수로 힌트 문자열 만드는 함수(){~~~};
                                      
// 사용할 때                                      
import 아래 세 함수를 사용해서 힌트를 반환하는 함수 from "경로"

위 코드는 그동안 프로젝트를 진행하며 자주 사용했던 방식으로 작성한 코드이다. 전혀 문제가 없어 보이지만 저 함수를 사용할 때 문제가 발생했다.

문제의 원인을 찾아보기 위해 node.js의 공식 문서를 찾아보았다. 찾아본 결과 node.js에서는 기본적으로 import, export를 지원하지 않고, 이를 사용하기 위해선 js파일을 저장할 때 확장자명을 mjs로 저장해야 한다는 것을 알았다. 혹은 package.json을 일부 수정하는 방식이 있다고 하지만 이는 미션에서 제한 사항에 있는 내용이기 때문에 포기했다.

평소에는 js의 ES6문법을 사용했기 때문에 import, export를 지원해주는 것이었고, node.js 환경에서는 module.exports, require를 사용해야 함을 알게 되었다.

혹시나 mjs 파일 확장자를 사용하면 미션 진행에 문제가 발생할까 두려워 module.exports, require를 사용하기로 결심했다. 그렇게 변경된 방식은 다음과 같다.

function 아래 세 함수를 사용해서 힌트를 반환하는 함수(){~~~};
                                                    
function 스트라이크 개수 계산 함수(){~~~};
function 볼 개수 계산 함수(){~~~};
function 스트라이크, 볼 개수로 힌트 문자열 만드는 함수(){~~~};
                                      
module.export = {아래 세 함수를 사용해서 힌트를 반환하는 함수};
                                      
// 사용할 때
const {아래 세 함수를 사용해서 힌트를 반환하는 함수} = require("경로");

import를 사용할려고 고집부린 덕에 새로운 내용을 알게됐다. (사실 node.js 공식문서를 검색하기까지 다른 내용으로 엄청 삽질했다)

❗MissionUtils의 사용

이런 요구사항이 있었다.

ApplicationTest를 살펴보니 저 라이브러리를 사용하지 않으면 테스트를 진행할 수 없어 0점 처리가 됨을 확인할 수 있었다. 그래서 저 녀석을 사용해서 문제를 해결하기 위한 계획을 짜봤다.

MissionUtils.Console.readLine("질문 내용",(입력값)=>{
  // 여기서 입력값 사용 가능
});

요런 함수가 있는데 원래 계획은 다음과 같이 while문에서 저 MissionUtils를 사용해 프로퍼티를 변경하는 함수를 호출하고자 했다.

class BaseballGame{
  constructor(){
    this.inputNumber = 0;
  }
  
  handleUserInput(){
    MissionUtils.Console.readLine("질문 내용",(입력값)=>{
      this.inputNumber = 입력값
  	});  
  }
  
  startGame(){
    while(힌트가 3스트라이크 아닐 동안 반복){
      handleUserInput();
      //다음 로직...
    }
  }
}

그냥 보기엔 문제가 없어보이지만, 이 코드엔 치명적인 문제가 있었다. readLine을 통해 입력값을 받아올 때 위와 같이 호출하면 사용자의 입력을 기다려주지 않고 while문이 계속 반복한다는 문제점이었다.

실제로 저 로직을 돌려보면 내 입력은 기다리지도 않고 숫자를 입력하라는 문구가 무한대로 출력되는 아름다운 경험을 할 수 있을 것이다... ㅠㅠ

그래서 방식을 고민하다 readLine내부에서 로직을 실행시키면 어떨까 라는 생각을 하게 되었다. 방식은 다음과 같다.

MissionUtils.Console.readLine("질문 내용",(입력값)=>{
  입력값 처리 함수(입력값);
});

이런 식으로 처리하니 사용자의 입력값을 기다렸다가 입력이 되면 그 값을 통해 로직이 실행되는 것을 볼 수 있었다.

MissionUtils는 readLine 말고도 다양한 방식으로 날 괴롭혔다. 미션의 로직이 완성되고 npm test를 실행시켰을 때 모두 정상적으로 테스트가 통과해 기분 좋게 우테코 지원 사이트에서 테스트를 돌려보았다.

결과는

제출날 이런 문구와 마주하게 되었다. 무엇이 문제인지 알 수 없어 애꿎은 PR만 닫았다가 다시 제출했다. 그래도 결과는 위와 같았다. 오랜 시간 고민해본 결과 문제점은 게임이 종료된 이후 "2"를 입력했을 때 게임이 종료되는 부분에 있었다. 내가 처음 생각한 로직은 다음과 같았다.

1. 사용자가 숫자를 맞춰 재시작 여부 판별함수 실행
2. "1"이 입력되면 재시작
3. "1", "2"가 아닌 다른 숫자가 입력되면 throw로 Error 발생
4. "2"는 따로 처리하지 않음

아마도 테스트를 할 때 종료되는 부분이 없어 문제가 발생한 것 같았다. MissionUtils의 사용 방법을 다시한번 읽어보니

이런 부분이 있었다. 혹시나 이 녀석이 해결책일까 싶어 게임 종료 후 "2"가 입력되면 Console.close()를 호출해보았다.

😭😭😭😭😭😭😭😭😭😭😭😭😭😭😭

앞으로 기능을 구현할 때 조금만 더 꼼꼼히 계획하자는 다짐을 했다.

💪가장 공들인 부분

📃기능 목록 작성하기

위 사진은 1주차 미션 중 가장 어려웠던 7번 문제를 해결할 때 작성했던 기능목록 및 구현 방향성이다.

그리고 위 사진은 2주차 미션을 수행하며 작성한 기능목록 및 구현 방향성이다. 전체 내용은 여기서 확인할 수 있다.

그냥 보기만 해서는 꾸몄다는 것 외에 둘의 차이가 잘 안느껴지겠지만

이 부분에서 둘의 차이가 있다.

1주차엔 기능 목록을 작성하는 나만의 루틴을 잡아가는 단계였다면 2주차는 그걸 좀 더 발전시키는 단계였다. 지난 1주차 회고에서 나만의 기능목록 작성 규칙을 이야기 했었는데

이때 나는 총 5단계를 거쳐 기능을 구현했다고 이야기 했다. 이때는 나름 간단한 내용이라 한꺼번에 모든 방향성을 정할 수 있었다. 하지만 이번주 미션에서는 하나의 큰 프로그램을 작성하기 위한 기능목록을 작성해야 했다. 직접 해보니 내 루틴 중 구현 방향성을 설정하는 부분에서 어려움이 있었다. 그래서 기능목록을 작성한 후 기능에 필요한 구현 방향성을 구현할 때마다 적어보았다. 전체 방향성을 정해둔 후 작은 방향성들을 잡아가니 큰 무리 없이 미션을 해결할 수 있었다. 어디서 주워들은 divide and conquer가 떠올랐다. 이래서 이전 기수 분들의 후기를 보면 기능 목록 작성이 많은 도움이 되었다고 얘기했던건가 싶었다.

1주차 회고는 여기서 확인할 수 있다.

🛠️리팩토링

처음에 말했다시피 나는 이미 이 미션을 한번 구현해본 적이 있었다. 물론 지금 한 것처럼 열심히 하진 않았지만 구현을 이미 해본 프로그램을 다시 해보는 것은 처음 했던 것보다 크게 어렵지 않았다. 그래서 이번엔 리팩토링을 많이 해보자는 생각으로 미션에 임했다.

한번 다 짠 코드를 보면서 하나의 코드에 부담이 너무 커지면 작은 조각들에 책임을 분할하는 느낌으로 코드를 작성해보았다.

ex)

• App에서 모든 내용을 다 처리하는 방식 => App은 BaseballGame을 실행만 하고, 실질적인 게임의 로직은 BaseballGame에서 처리하는 방식으로 변경.
• BaseballGame에서 필요한 자잘한 연산은 따로 module로 묶어 파일 분리

이렇게 해보니 요구사항에 주어졌던 indent depth 2이하로 제한, 함수가 하나의 역할만 수행하도록 작성 등의 내용이 자연스럽게 지켜지게 되었다. 개인 프로젝트를 하면서도 나름의 리팩토링을 자주 진행했었지만, 이렇게까지 세부적으로 해본적은 없었다. 고민하면 고민할수록 단순한 표현으로 많은 기능을 하는 코드를 작성할 수 있게 되니 고민하는 재미가 있었다.