[우아한테크코스] 우테코 프리코스 6기 2주차 자동차 경주 미션 회고

개인적으로는 미션 수행을 통해 성장한 과정을 기록하고,
누군가에게는 이 글이 도움이 되었으면 하는 마음입니다 :)

 

🛠️ 2주 차 결과물

2주 차 미션 : 자동차 경주 PR

게임 실행 화면과 테스트 통과 화면

 

 

📮 2주 차 메일 내용

1️⃣ 지난 1주 차 미션에 이어..

1주 차 미션의 목표는 git, 분야별 언어, 그리고 미션 사이클에 익숙해지는 것이었다. 그리고 2주 차부터는 우테코 미션 과정을 제대로 맛볼 수 있는 과제인 '자동차 경주' 게임이었다.

 

요구사항을 이해하는 게 어려울 수 있지만 주어진 요구사항을 잘 파악하는 것도 좋은 개발자의 역량 중 하나다. 고민 없이 무작정 질문하거나 다른 사람의 도움을 받기 전에 스스로 고민하고 문제를 해결해 보는 것을 추천한다고 한다.

 

2️⃣ 2주 차 미션의 목표

2주 차 미션에서는 1주 차에서 학습한 것에 더해 함수를 분리하고, 각 함수별로 테스트를 작성하는 것에 익숙해지는 것을 목표로 명시했다. 더불어, 테스트 코드 작성이 처음이라면 테스트 도구를 학습하고, 작은 단위의 기능부터 테스트를 작성해 보길 권했다.

 

 

🌳 지난 1주 차 공통 피드백

아래는 1주 차 미션 마감 후, 모든 프리코스 참여 인원에게 발송된 공통 피드백이다. 엄청나게 지키기 어려운 것들이라기보다 '기본을 지키자'라는 내용이다. 거의 요구사항과 Git에 대해 다시 한번 강조했다.

1. 요구사항을 정확히 준수한다
2. 커밋 메시지를 의미 있게 작성한다
3. git을 통해 관리할 자원에 대해서도 고려한다
4. Pull Request를 보내기 전 브랜치를 확인한다
5. PR을 한 번 작성했다면 닫지 말고 추가 커밋을 한다
6. 이름을 통해 의도를 드러낸다
7. 축약하지 않는다
8. 공백도 코딩 컨벤션이다
9. 공백 라인을 의미 있게 사용한다
10. space와 tab을 혼용하지 않는다
11. 의미 없는 주석을 달지 않는다
12. linter와 Code Formatter의 기능을 활용한다
13. EOL(End Of Line)
14. 불필요한 console.log를 남기지 않는다
15. JavaScript에서 제공하는 API를 적극 활용한다

 

 

 

🤚 미션에 앞서,

1️⃣ 기능 목록 만들기

미션은 기능 요구 사항, 프로그래밍 요구 사항, 과제 진행 요구 사항 세 가지로 구성되어 있다. 특히 주목해야 할 점은 기능을 구현하기 전에 기능 목록을 만든다는 것. 기능 구현 시 목록을 만들어져 있는 것이 아니라, 직접 만들어야 하는 게 포인트다.

 

2️⃣ 제출 전 테스트 필수

기능 구현을 모두 정상적으로 했더라도 요구 사항에 명시된 출력값 형식을 지키지 않을 경우 0점으로 처리된다. 기능 구현을 완료한 뒤 테스트를 실행했을 때 테스트가 실패할 경우 0점으로 처리되므로, 반드시 확인 후 제출한다. 필자는 Node 환경에서 프로그램이 잘 돌아가는지 확인하고, 로컬 테스트 코드 통과까지 확인했다.

 

뿐만 아니라, 제출 가능 기간에는 미리 PR을 올리고 지원하기 플랫폼의 예제 테스트까지 미리 돌려보았다. 그렇지 않으면 마감이 몇 시간 남지 않은 상태에서 추측이 어려운 에러와 기약 없이 싸워야 하니 미리미리 확인하자.

 

3️⃣ Node 버전 확인 필수

테스트 패키지 설치를 위해 Node.js 버전 18.17.1 이상이 필요하다. 본인 로컬의 Node 버전이 몇인지 꼭 확인 후 미션을 진행하자. 참고로 Node 버전 확인은 'node --version'으로 확인 가능하며, 업데이트는 Node.js 공식 사이트를 참고하거나, 아래와 같이 'nvm install'로 특정 Node 버전을 설치할 수 있다.

 

Node 버전 설정 화면

 

 

🏎️ 기능 요구 사항

1️⃣ 자동차 경주 게임 설명

미션에 대한 자세한 내용은 우테코 프리코스 레포에 있으니 참고하길 바라며, 간단히 게임 설명을 하자면 자동차들이 사용자가 입력한 시도 횟수만큼 경주를 하면서 가장 멀리 이동한 자동차가 이기는 게임이다.

 

2️⃣ 자동차 경주 게임 예시

경주할 자동차 이름을 입력하세요.(이름은 쉼표(,) 기준으로 구분)
pobi,woni,jun
시도할 횟수는 몇 회인가요?
5

실행 결과
pobi : -
woni :
jun : -

pobi : --
woni : -
jun : --

... 생략

pobi : -----
woni : ----
jun : -----

최종 우승자 : pobi, jun

 

이번 미션은 지난 1주 차에 비해 예외 처리를 생각보다 꼼꼼하게 했어야 했다. 요구 사항들을 읽어보면 생각보다 애매한 조건들이 있어서 사용자의 다양한 인풋까지 예상하고 제한을 걸어두어야 했다.

 

일단 아래 요구사항들을 아주 꼼꼼하게 씹어먹듯 읽어보자. (중요)

 

3️⃣ 자동차 경주 기능 요구 사항

✅ 주어진 횟수 동안 n대의 자동차는 전진 또는 멈출 수 있다.

👉 여기서 n대를 어떻게 처리할 것인가? 무한으로 늘릴 것인가, 아니면 자체적으로 수를 제한할 것인가? 스스로 판단해 볼 문제다. 무한대로 늘리면 애플리케이션에 무리가 가지 않을까? 아니면 굳이 그런 조건은 없으니 걸어두지 않아도 될까?

✅ 각 자동차에 이름을 부여할 수 있다. 전진하는 자동차를 출력할 때 자동차 이름을 같이 출력한다.

👉  각 자동차에 이름을 어떻게 부여할 것인가? 영문 숫자 특수문자 모두 허용할 것인가? 그런데 '전진하는 자동차를 출력할 때' 자동차 이름을 같이 출력한다고 기재되어 있는데, 실행 결과 예시에서는 전진하지 않는 자동차도 이름이 출력되어서 헷갈렸다. 하지만 텍스트보다 예시가 정확하니 예시처럼 하이픈이 찍히지 않아도 자동차 이름을 출력되도록 했다.

✅ 자동차 이름은 쉼표(,)를 기준으로 구분하며 이름은 5자 이하만 가능하다.

👉  자동차 이름은 쉼표를 기준으로 구분해야 한다. 그런데 여기서 중요한건 '쉼표'만 요구한다는 것이다. 공백이나 온점, 하이픈 등 다른 것들로 자동차가 구분되도록 하면 안 된다. (하지만 난 이 예외처리를 하지 못했지.. 매우 아쉽다.) 더불어, 이름은 5자 미만이 아닌 5자 이하만 가능하다.

✅ 사용자는 몇 번의 이동을 할 것인지를 입력할 수 있어야 한다.

👉 자동차가 몇 번의 이동을 할 지는 랜덤 생성기로 하는 것이 아니라, 사용자가 값을 입력하는 것이다. 여기서 '몇 번의 이동'이란, 각 자동차가 몇 개의 하이픈을 찍느냐가 아닌, 실행 이터레이션을 얼마나 돌지를 말하는 것이다. 쉽게 말해, 사용자가 5를 입력하면 각 자동차는 5번을 이동할 수 있는 '기회'를 얻고, 그 기회동안 가장 많은 이동을 한 자동차들이 우승하는 것이다. 더불어, 사용자가 횟수를 입력할 때의 별다른 제한 조건이 없지만 시도 횟수에 따라 자동차들이 이동해야 하니, 소수/음수/문자 등에도 제한 조건을 걸어두어도 좋겠다.

✅ 전진하는 조건은 0에서 9 사이에서 무작위 값을 구한 후, 무작위 값이 4 이상일 경우이다.

👉 자동차들이 전진하는 조건은 (자동차도 사용자도 아닌, 컴퓨터 == 랜덤 API가) 0과 9 사이의 무작위 숫자를 구해주면, 그 값에 따라 전진할지 말지 정해지는 것이다. 예를 들어 랜덤 생성기가 pobi에게 3을, woni에게 4를, jun에게 9를 준다면? woni와 jun만 전진할 수 있다 ( == 하이픈 하나를 찍을 수 있다) 

✅ 자동차 경주 게임을 완료한 후 누가 우승했는지를 알려준다. 우승자는 한 명 이상일 수 있다.

👉 프로그램이 끝나는 게 아니라 게임이 끝나면, 최종 우승자를 알려주는데, 이때 우승자는 한 명일 수도 있고, 여러 명일 수도 있다. 위에서 언급한 것처럼 횟수동안 '가장 많이 이동한 자동차'가 우승하는 것이다. 즉, 5회의 시도동안 5회를 이동한 차가 우승하는 게 아닐 수도 있다.

✅ 우승자가 여러 명일 경우 쉼표(,)를 이용하여 구분한다.

👉 위에서 언급하듯 우승자가 여러 명이라면 각 이름이 꼭 쉼표로 구분되어야 한다. 하이픈이나 온점도 안된다. 하지만 이 요구사항 또한 애매했던 게 텍스트로는 쉼표를 이용하라면서 실행 결과 예시에서는 쉼표와 공백이 있었다. 내가 본 게 맞나 싶어 드래그를 그어 공백까지 확인했다구.. 뭐지 함정인가.. 싶었다. 

✅ 사용자가 잘못된 값을 입력한 경우 throw문을 사용해 "[ERROR]"로 시작하는 메시지를 가지는 예외를 발생시킨 후, 애플리케이션은 종료되어야 한다.

👉 사용자가 잘못된 값 (자동차 이름, 시도 횟수)를 입력하여 예외 상황에 대해 1) throw문을 사용하고 (2) 꼭 [ERROR]로 시작하는 메시지를 출력하며 (3) 애플리케이션이 즉시 종료되도록 해야 한다. 이 한 문장에 무려 세 가지 요구사항이 담겨 있으니 유의하자.

 

 

🚨 프로그래밍 요구 사항 - 실행 환경

✅ Node.js 18.17.1 버전에서 실행 가능해야 한다.

👉 Node 버전 체크 필수다. 작업할 때 확인했더라도 제출하기 직전에 다시 한번 해당 버전에서 잘 돌아가는지 확인하자.

 

✅ 프로그램 실행의 시작점은 App.js의 play 메서드다.

👉 App.js로 게임을 실행할 수 있던 지난 1주 차와는 달리, 이번 2주 차는 App 클래스가 index.js에 import 되어 node 환경에서 index.js를 실행할 수 있었다. 매 미션마다 실행 환경이나 요구 사항이 완전히 똑같지 않을 테니 이미 알고 있는 것이라도 다시 읽어보는 것이 좋겠다.

 

✅ package.json을 변경할 수 없고 외부 라이브러리(jQuery, Lodash 등)를 사용하지 않는다. 순수 Vanilla JS로만 구현한다.

👉 하지만 필자는 지난 1주 차와 똑같이 ESLint와 Prettier를 사용하고, 변경된 package.json 내역은 굳이 push 하지 않았다.

 

✅ JavaScript 코드 컨벤션을 지키면서 프로그래밍한다.

👉 Airbnb 코드 컨벤션을 하나하나 보고 따르기에는 너무 번거로웠기에 ESLint와 Prettier를 설정해서 컨벤션을 맞추었다.

 

✅ 프로그램 종료 시 process.exit()를 호출하지 않는다.

👉 보통 프로그램을 종료할 때 Console.Close()나 process.exit()를 사용하고는 했지만, 여기서는 메서드를 호출하지 않는다. 지난 1주 차 미션에서는 게임 종료 시 '게임 종료' 문구를 출력했지만, 2주 차는 위에서 언급한 듯이 throw문을 사용해 에러를 발생시키고 그대로 애플리케이션이 종료되도록 했다.

 

✅ 프로그램 구현이 완료되면 ApplicationTest의 모든 테스트가 성공해야 한다. 테스트가 실패할 경우 0점 처리한다.

👉 이번 미션의 ApplicationTest는 총 3개의 테스트였고, 이 세 가지 테스트를 모두 통과해야 한다.

 

✅ 프로그래밍 요구 사항에서 달리 명시하지 않는 한 파일, 패키지 이름을 수정하거나 이동하지 않는다.

👉 디폴트로 있던 파일(package.json, package-lock.json 등)과 코드, 폴더는 굳이 건들지 않았다. 혹시나 지원 플랫폼 예제 테스트에 통과하지 못할까 봐 굉장히 조심스러웠던 것도 있다. 요구사항을 잘 듣는 개발자가 되자!

 

 

🚨 프로그래밍 요구 사항 - 라이브러리

✅ @woowacourse/mission-utils의 Random 및 Console API를 사용하여 구현해야 한다.

✅ Random 값 추출은 Random.pickNumberInRange()를 활용한다.

✅ 사용자의 값을 입력받고 출력하기 위해서는 Console.readLineAsync, Console.print를 활용한다.

👉 1주 차와 마찬가지다. 굳이 따로 만들지 않고 우테코에서 제공하는 utils들을 사용해 입력 및 출력을 하면 된다.

 

 

➕ 2주 차부터 추가된 요구사항

✅ indent(인덴트, 들여 쓰기) depth를 3이 넘지 않도록 구현한다. 2까지만 허용한다. 

👉 이번부터 새롭게 추가된 요구사항이지만, 사실 함수 하나에 15줄 이상 넘어가고 depth가 많아지면 한 가지 일을 하지 않을 가능성이 높다. 따라서 indent depth를 줄이고자 한다면 함수 또는 메서드를 분리하면 된다. 더불어, 많은 이들이 depth에 대해 커뮤니티에 질문을 남겼는데, 예를 들어 while문 안에 if문이 있으면 들여 쓰기는 2이다.

✅ Jest를 이용하여 본인이 정리한 기능 목록이 정상 동작함을 테스트 코드로 확인한다. 

👉 친절하게도 테스트 도구 사용법이 익숙하지 않은 사람들에게 예제로 주어진 StringTest.js라는 파일이 주어졌다. 나도 테스트 코드 작성이 처음이라 이를 참고하여 학습한 후 단위 테스트들을 구현했다.

 

 

📚 미션을 통해 배운 점

1️⃣ 기능 명세서 작성 방법

지난 1주 차에 이어 이번 주에도 기능 명세에 공을 많이 들였다. 단순히 보기 좋게 꾸민다기보다, (특히 학습하는 단계에서는) 요구사항을 꼼꼼히 분석하고 로직을 구상하는 연습을 해야 한다고 생각했다.

 

특히 앞으로 3주 차 4주 차부터 요구사항도 많아지고 로직도 복잡해질 텐데 다양한 방식으로 작성해 보면서 나만의 방법, 더 나아가 템플릿까지 갖춰두고 싶었다. 더더나아가 최종 코딩테스트는 이러한 과정을 아주 짧게 가져가면서 기능 구현에 시간을 쏟고 싶었다. 

 

README.md와 convention.md

 

위와 같이 이번 미션에서 우테코가 제시한 목표(함수 분리, 테스트 코드 작성), 그리고 개인적인 목표(MVC 패턴 적용, 객체 지향 프로그래밍)를 기재했다. 목표를 적어두니 이번 미션에서 무엇을 얻어가고자 하는지, 무엇을 더 신경 써야 하는지 주목하게 되었다. 이후 이 목표를 기준으로 회고할 수도 있겠다.

 

추가로, 컨벤션도 추가했다. 물론 공통으로 지켜야 하는 컨벤션은 무조건 지켜야 하고, 이 외에 커밋 메시지나 파일명 컨벤션 등은 따로 정답이 정해져 있지 않아 내가 서칭 한 내용을 바탕으로 자체 규칙을 정했다. 코드를 생각 없이 쓴 게 아니라, 나름의 규칙을 가지고 작성한다는 점을 부각하고 싶기도 했다.

 

2️⃣ 절차 지향 vs. 객체 지향

지난 1주 차에는 전체적인 플로우와 함께, 각 단계에 따라 필요한 클래스와 메서드 및 변수까지 아주 상세하게 정의했으나, 몇몇 이유로 형식을 조금 바꾸었다.

이번 미션은 어느 정도 미션 사이클에 익숙해지기도 했다. 그리고 무엇보다 로직은 리팩토링 등으로 언제든지 바뀔 수 있기에, 로직을 바꾸면 추후 기능 명세까지 변경해야 하는 번거로움이 있었다. 절차에 따라 상세하게 기재해 두면 How에 대해서는 더 좋은 방법으로 바꿀 수도 있어야 하는데, 사고가 갇히는 느낌이 들기도 했다.

 

정리하자면, 이번에는 How보다는 예외사항을 포함해 해당 기능에서 구현되어야 하는 What을 중심으로 적었다.

 

requirement.md

 

위와 같이 두 가지 방법으로 적어보았다. 하나는 절차 지향으로 How를 간단하게 적고, 하나는 객체 지향으로 각 객체가 어떤 역할을 해야 하는지를 적어서 전체적인 구조를 생각했다.

 

사실 요즘 프론트 쪽에서는 함수형 프로그래밍이 대세라지만, 우테코에서는 객체 지향 프로그래밍을 지향하는듯해서 객체 지향 프로그래밍을 지향하기로 했다. 물론 프로그래밍 방법이 무슨 대수냐 싶긴 하겠다만, 이번 기회에 다양한 프로그래밍 방법을 학습하며 적용하려는 노력 그 자체가 충분히 의미 있을 것 같았다. 정답은 없다. 본질적으로는 요구사항 파악이니까.

 

그러니 절차 지향이든, 객체 지향이든 하나의 문제를 다양한 시각에서 보기로 했다. 절차 지향으로 단계를 하나하나 짚으면서 게임 단계별로 구현해야 하는 기능이 무엇인지 파악했다. 그리고 각 MVC 패턴을 공부하면서 각 객체의 역할을 어떻게 배치할지 고민했다.

 

3️⃣ MVC 패턴의 본질

이 부분에 대해서는 나도 고민이 많았고, 커뮤니티에서도 토론이 활발했다. 다들 MVC, MVC 이야기하는데 이걸 쓰면 좋은 건가? 에 대한 납득이 되지 않았나 보다. 그래서 나 또한 무지성으로 패턴을 사용하기보다 스스로 납득 가능한 이유를 찾기로 했다.

 

우선 MVC의 본질부터 알아보고자 했다. 이 MVC라는 개념이 어떻게 등장했는지를 알면 그에 맞게 쓸 수 있을 것 같아서다. (참고: MVC 창시자가 말하는, MVC의 본질) 앨런 케이가 창시한 객체 지향 프로그래밍(Object oriented Programming)은 다음과 같은 고민에서 시작되었다고 한다.

좋은 코드를 만들기 위해서
어떤 방식으로 코드를 나누고 묶어줘야 할까?
어떤 방식으로 코드를 추상화해야 할까?

 

여기에 더해, 트라이브라는 사람은 (1) 비즈니스 로직과 (2) 시각적인 UI, 그리고 (3) 둘 사이를 연결해 주는 부분을 코드 안에서 분리하고 역할 부여를 해줘야 한다는 생각을 했다는데, 이 두 사람의 말을 듣고 보니 MVC 패턴이 해결하고자 하는 문제를 조금은 알 수 있었다.

 

곧, MVC의 본질은 관심사의 분리인 것이다. 좋은 코드를 만들기 위해 코드 혹은 모듈의 역할을 나누고, 각자 역할에 따라서 움직이며, 서로가 서로에게 영향을 받지 않고 코드의 중복을 줄일 수 있다. 이렇게 되면 유지보수도 편하고, 좋은 코드라고 할 수 있는 것에 가까워진다.

 

참고한 글에서도 말하는 듯, 사실 객체지향이든 절차지향이든 MVC 패턴이든, 어쨌든 목적은 하나다. 유지보수하기 편하고 읽기 쉬운 코드를 작성하기 위한 수단이다.

 

4️⃣ MVC 패턴 적용하기

이렇듯 본질과 목적에 대해 이해하고 나니 MVC 패턴을 적용하기가 수월해졌다. 그리고 지난 1주 차 미션에서 아쉬웠던 관심사 분리를 MVC 패턴을 통해 적용하면서 각 폴더와 코드들의 목적을 더 잘 파악하기 쉬웠다. 나는 아래와 같이 MVC 패턴을 적용해 보았다.

 

MVC @InterviewBit

 

우선 전체적인 로직은 사용자 요청이 들어오면 → Controller가 중재자 역할을 하고 → View로 사용자 요청을 받아서  → Model을 생성하여 로직을 처리한다.  → 그리고 다시 Controller라는 중재자가 View로 사용자에게 응답을 주도록 설계했다. 이 중 Model(Car.js)에서는 각 자동차들의 데이터 (name, position)을 저장했다. 여기서 자동차라는 객체를 만드는 필드는 이름이라는 속성이 있고, Car만이 가지는 '달린다'라는 고유한 동작을 정의했다.

 

View는 사용자가 자동차 이름과 시도 횟수를 입력하고 검사하는 inputView와, 사용자에게 결과 값을 출력하는 outputView로 구성했다. 마지막으로 Controller는 위의 Model과 View 사이에서 비즈니스(도메인) 로직을 처리하도록 컨트롤 타워의 역할을 하게 했다.

 

5️⃣ TDD에 대한 결론

이번에 테스트 코드를 짜면서 TDD(Test Driven Development)에 대해 공부해 보기도 했다. 사실 TDD는 말은 거창해 보이지만 간단하게 말하자면 '테스트 주도 개발'로서 작은 단위의 테스트를 먼저 작성하고, 이를 통과하는 코드를 추가하는 단계를 반복하는 구현 방법이다. (참고:  TDD 방법론 (테스트 주도 개발) - 알기 쉽게 정리) 

 

프리코스 참여 전까지만 해도 테스트 코드라는 것을 짜본 적이 없었기에 TDD는 무슨, Jest 조차도 익숙해질 시간이 필요했다. 그래서 개발 속도가 느려지기도 하고, 기능 구현보다 테스트 코드를 먼저 짜기에는 이제까지 내가 개발하던 방식을 많이 바꿔야 했기에 어려웠다. 그래서 TDD를 지향하기보다, 일단 테스트 코드 작성이라는 것을 해보자를 목표로 삼아 공부하고 적용했다. (참고: 테스트하기 좋은 코드 - 테스트하기 어려운 코드)

 

그러다 현직 개발자가 피드백해 주길, 사실 현업에서도 TDD 적용은 이상적인 세계 같다고 할까. 실제로는 어려운 점이 있다고 한다. 물론 좋은 점도 있다. 그렇기에 TDD가 내 성향과 맞고, 좋은 방법론이라고 체감하는 그때 적용해도 좋을 것 같다고 결론을 내렸다.

 

6️⃣ 라이브러리 테스트

테스트 코드에 우테코에서 제공하는 라이브러리 (Console, Random)들은 utils 파일에 모아두고 단위 테스트를 돌렸다. 어차피 보장된(?) 라이브러리인데 왜 테스트를 돌려야 할까 생각도 들었다. 이 부분에 대해서는 사람마다 시각 차이가 있는 것 같았다.

 

하지만 외부 라이브러리는 언제든지 변경될 수 있고, 그들을 util이라는 하나의 js파일, 하나의 테스트 파일에 모아두고 관리할 수 있게끔 하고자 했다. 지금은 작은 일회성 프로젝트지만 추후 사용자에게 배포된 서비스라고 가정했을 때를 위함이다. 라이브러리는 내가 통제하기 어려운 외부 변수 중 하나인데, 만약 라이브러리에 이슈가 생기면 utils로 모아두었던 라이브러리만 수정하면 되기 때문이다.

 

외부적인 요인이 바뀌어도 우리 코드에는 영향을 덜 받게끔 하나의 레이어를 중간에 둔달까? 특히 규모가 크고 사용자와 직접적인 interaction이 있다면 최대한 변동성을 없애고자 하는 차원에서도 고민해 볼 내용인 것 같다.

비슷한 이유로 printMessage를 utils로 빼두고 테스트코드까지 작성했던 것도 마찬가지다. 실제로 현업에서는 라이브러리가 바뀌었을 때 내부에서 먼저 감지할 수 있기에 테스트를 만든다고 한다. 특히, 외부 라이브러리를 일정 주기로 확인하는 batch 같은 것을 돌려서 원하는 응답이 오는지, 정상적으로 작동하는지 체크한다고 한다.

 

7️⃣ 테스트 코드 커밋에 대한 고민

테스트 코드와 소스코드는 분리해서 커밋할지 고민이 있었고, 이 부분에 대해서도 커뮤니티에서 토론이 있었다.

 

# 소스 코드 커밋
feat: 사용자가 입력한 자동차 이름의 유효성 검사 기능 추가
feat: 사용자가 입력한 시도 횟수의 유효성 검사 기능 추가

# 테스트 코드 커밋
test: 자동차 이름과 시도 횟수 유효성 검사 테스트 코드 추가

 

나는 코드 리뷰를 하는 사람의 입장을 고려해 분리해서 커밋하기로 결정했다. 보는 사람의 관심사에 다를 수 있기 때문이다.

 

예를 들어 CI/CD  (Continuous Integration/Continuous Delivery) 배포 단계 중, CI 단계에서는 테스트 올렸을 때 통과되면 리뷰하는 사람한테는 관심이 없고 소스코드가 관심 있을 것이다. 반대로 만약 CI가 제대로 되지 않는다면, 그때 되어서 테스트 코드를 작성한 커밋으로 가서 테스트 코드를 보면 될 것이다.

 

즉, 보는 사람의 관심사를 고려해 시간을 아껴주는 차원으로 생각했다.

 

 

👩🏻‍🔧 트러블 슈팅

일반적인 에러는 따로 다른 글로 발행하고,
본 미션에서 마주할 수 있는 몇 개만 기술합니다.

 

1️⃣ 왜 "pobi : -" 출력이 안되는가

어느 정도 기능 구현을 했다고 생각했고, Node 환경에서 테스트해보니 잘 작동되는 듯했다.

Node 환경에서는 테스트가 잘 되는 모습

 

분명 Node 환경에서는 "pobi : -" 출력이 잘 되는데..  왜 아래와 같이 테스트 코드에서는 string이 contain 되어 있지 않다고 하는 것인지 이해가 안 됐다.

 

하지만 테스트 통과가 안되는 화면

 

뜯고 뜯어보다가, GPT에게도 물어보다가 아래와 같은 해답을 찾았다.

문제는 역시 코드에 있었다.

 

moveCarForwardOrStop() {
    this.cars.forEach((car) => {
      const randomNumber = generateRandomNumber();
      if (randomNumber >= NUMBER.MOVE_FORWARD_REQUIREMENT) {
        car.moveForward();
      }
    });
  }

  printForwardCarName() {
    this.cars.forEach((car) => {
      printCar(car.getName(), car.getPosition());
    });
    printMessage(STRING.BLANK_SPACE);
  }

  raceCar(tryNumber) {
    printResult();
    for (let i = 0; i < tryNumber; i += 1) {
      this.moveCarForwardOrStop(generateRandomNumber()); // 랜덤 생성기 한번 더 호출
      this.printForwardCarName();
    }
  }

 

일단 우테코 측에서 제공한 테스트코드인 ApplicationTest.js 코드를 살펴보았다. 여기선 generateRandomNumber 함수 (내가 짠 랜덤 생성기)를 모킹히면서 반환 값을 제어하려고 했다. 그런데 내가 짠 GameController.js 내부에서 generateRandomNumber 함수를 호출하는 방식이 잘못되었으니 테스트할 때 generateRandomNumber의 반환 값이 랜덤이 아닌 항상 동일하게 설정되었던 것이다.

즉, 아래와 같이 테스트 코드의 이 부분이 테스트 실패의 원인이었던 것이다.

 

describe('자동차 경주 게임', () => {
  test('전진-정지', async () => {
    // given
    const MOVING_FORWARD = 4;
    const STOP = 3;
    const inputs = ['pobi,woni', '1'];
    const outputs = ['pobi : -'];
    const randoms = [MOVING_FORWARD, STOP];
    const logSpy = getLogSpy();

    mockQuestions(inputs);
    mockRandoms([...randoms]); // 이 부분

 

generateRandomNumber 함수의 반환 값을 배열 randoms의 값으로 “순차적으로” 설정하도록 모킹 하려고 했다. 이때, 랜덤 생성 함수는 여러 번 호출되더라도 항상 동일한 값을 반환하는 것이 아니라, 호출될 때마다 무작위의 값이 반환되어야 한다.

따라서 generateRandomNumber 함수의 반환을 순차적으로 설정하면, 예상과 다르게 항상 동일한 값이 반환되어서 pobi와 woni의 이동을 무조건 멈추게 되고, "pobi : -"와 같이 position이 0으로 출력되는 문제가 발생한 것이었다.

 

그래서 GameController 코드 내에서 generateRandomNumber 함수를 호출하되, 해당 함수가 테스트 코드에 '적합한' 위치에서 실제로 난수를 반환하도록 수정하는 방식으로 해결했다.

 

통과!!!

 

아무튼 1주 차에 이어, 이번 에러도 새벽까지 붙잡고 있다가 너무 안 되겠어서 다음날 맑은 정신으로 살펴보니 잘 해결할 수 있었다. 에러 해결은 언제나 힘들지만, 언제나 통쾌해!

 

2️⃣ 그놈의 '예기치 못한 오류'....

지난 1주 차에는 지원 플랫폼 예제 테스트도 한 번에 통과가 되었는데, 왜인지 이번 주는 한번에 통과를 못했다. 다행히 마감 전 날에 이런 일이 생겼으니 망정이지, 마감 시간 다 돼서 이랬으면 정말 멘붕이었을 것 같다.

 

뭔데 뭔데 원인이 뭔데

 

여러 시도를 해보다가, 문득 짚이는 원인이 생각났다. 바로 '대문자로 시작하는 파일명을 소문자로 바꾼 것'이다. 처음엔 InputView 클래스를 굳이 클래스화 할 필요가 없다고 생각해 파일명 또한 InputView.js에서 inputView.js로 변경했다. 이게 화근이었다.

 

원인은 git이 대소문자를 구분하지 못하기 때문이었다. (참고: 파일명 대소문자 인식에 대한 고민) 그렇기에 InputView를 inputView로 변경해도 바뀌어 커밋 & 푸시되지 않는다. 더불어, import 문에서는 InputView라 쓰여있어도 파일명은 inputView라 기재되었기에 예제 테스트에서 오류가 일어날 여지가 있던 것이다. 

 

해결을 위한 커밋 내역

 

해결을 위해 위와 같이 inputView 파일을 다시 생성해서 커밋했더니 정말 다행히도 통과가 되었다. 이 에러 해결을 위해 필요 없는 커밋을 꽤 해서 아쉽다.. (물론 squash merge를 하면 되지만 혹시 몰라 하지 않았다)

결국 통과!

 

 

🧹 리팩토링

1️⃣ 에러를 상황에 따라 나누기

지난 1주 차에는 에러를 상황에 따라 나누지 않았다. 무조건 유효한 입력값이 아니면 동일한 에러 메시지가 출력되도록 했으나, 이번 2주 차에는 다양한 예외 처리를 해야 하는 만큼, 에러 메시지도 세분화했다. (하지만 공백 등 더 다양한 예외처리를 했어야 했는데 그러지 못해 아쉽다. 3주 차에는 예외처리에 더 신경을 많이 쓰겠다!)

 

export const getUserInputCarName = async () => {
  const input = await Console.readLineAsync(LOG_MESSAGE.INPUT_CAR_NAME); 
  if (!input) {
    throwError(ERROR_MESSAGE.EMPTY_INPUT); // 입력 값이 없는 경우
  }
  if (!isValidCarName(input)) {
    throwError(ERROR_MESSAGE.INVALID_CAR_NAME); // 중복 또는 5자 초과한 경우
  }
  return input;
}

export const getUserInputTryCount = async () => {
  const input = await Console.readLineAsync(LOG_MESSAGE.INPUT_TRY_COUNT);
  if (!input) {
    throwError(ERROR_MESSAGE.EMPTY_INPUT); // 입력 값이 없는 경우
  }
  if (!isValidTryCount(input)) {
    throwError(ERROR_MESSAGE.INVALID_TRY_COUNT); // 1이상의 정수가 아닌 경우
  }
  return input;
}

 

2️⃣ distance → position

Car라는 자동차 객체를 만들 때 이름과 이동거리라는 멤버 변수를 만들었어야 했다. 처음에는 이동 거리를 나타내는 변수 이름을 'distance'라고 지었다. 그러다 생각해 보니 이 변수의 역할은 "자동차가 어디까지 갔어?"라는 것을 물어보고 알려주는 것이 아닌가. 그러니 Car를 바라보는 누군가의 입장을 고려해야 했다. 

 

distance는 Car이 본인 자신이 "음 이동 거리가 이만큼이군" 하고 혼자 생각하는 느낌이고, position은 "나의 위치는 여기야"라고 사용자에게 알려주는 느낌이 들어 더 알맞다고 생각했다.

 

다시 말하면, Car 라는 객체의 속성과 행위를 정의함에 있어 속성은 position과 같은 field가 되고 행위는 class의 멤버함수가 될텐데, Car의 속성을 표현하는 말로 위치를 나타내는 'position'이 더 낫다고 생각했다.

 

// Car.js
class Car {

  #name;
  
  #position = 0;

  // ... 생략

  getPosition() {
    return this.#position;
  }

  // ... 생략

 

 

3️⃣ 합칠지 말지 고민되던 함수

아래와 같이 자동차가 랜덤 생성기가 주는 숫자에 따라 움직이거나 멈추는 함수, 그리고 전진하는 자동차의 이름을 출력하는 함수가 있다.

 

// 리팩토링 전
moveCarForwardOrStop() {
  this.cars.forEach((car) => {
    const randomNumber = generateRandomNumber();
    if (randomNumber >= GAME_SETTING.MOVE_FORWARD_REQUIREMENT) {
      car.moveForward();
    }
  });
}

printForwardCarName() {
  this.cars.forEach((car) => {
    printCar(car.getName(), car.getPosition());
  });
  printMessage(GAME_SETTING.BLANK_SPACE);
}

 

위 두 개의 함수를 놓고 봤을 때 for each로 순회를 하는 대상이 동일한데, 내부에서 조건 분기로 충분히 명확하게 표현할 수 있는 부분이기에 굳이 두 함수로 나눌 필요가 없다는 생각을 했다. 그래서 아래와 같이 합쳤다.

 

// 1차 리팩토링
moveCarsAndPrintResults() {
  this.cars.forEach((car) => {
    if (generateRandomNumber(GAME_SETTING.MIN_RANDOM_NUMBER, GAME_SETTING.MAX_RANDOM_NUMBER) >= GAME_SETTING.MOVE_FORWARD_REQUIREMENT) {
      car.moveForward();
    }
    printCar(car.getName(), car.getPosition());
  });
  printMessage(GAME_SETTING.BLANK_SPACE);
}

 

하지만 대문자로 표현된 상수가 너무 많고 긴 데다가, 조건식이 길어져 가독성이 떨어졌다. 그래서 아래와 같이 2차 리팩토링했다.

 

// 2차 리팩토링
moveCarsAndPrintResults() {
  this.cars.forEach((car) => {
    const randomValue = generateRandomNumber(GAME_SETTING.MIN_RANDOM_NUMBER, GAME_SETTING.MAX_RANDOM_NUMBER);

    if (randomValue >= GAME_SETTING.MOVE_FORWARD_REQUIREMENT) {
      car.moveForward();
      printCar(car.getName(), car.getPosition());
    }

  });
  printMessage(GAME_SETTING.BLANK_SPACE);
}

 

위와 같이 랜덤 생성기로부터 나오는 랜덤 값을 변수로 선언하고, 이 변수가 조건에 충족하면 이동하고 출력되도록 했다.

 

4️⃣ 공백을 의미 있게 사용하기

이번 미션을 하면서 지난 1주 차 피드백을 최대한 반영하려고 했는데, 그중 하나가 공백이다. 공백 라인을 의미 있게 사용하고자 했다. 의미 없는 공백을 최대한 줄여 읽는 사람으로 하여금 머릿속에 물음표가 생기지 않도록 했다.

 

 대표적으로 아래의 코드를 보면 (1) 기다린 것 (2) 세팅하는 것 (3) 출력하는 것. 세 가지 목적에 따라 줄바꿈으로 분기했다.

 

// 리팩토링 전
async play() {
    await this.setCars();
    const tryCount = await this.handleTryCount();
    this.raceCar(tryCount);
    const winner = this.getWinner();
    printWinner(winner);
  }
  
// 리팩토링 후
  async play() {
    await this.setCars(); // 기다리는 것

    const tryCount = await this.handleTryCount(); // 세팅하는 것
    this.raceCar(tryCount);

    const winner = this.getWinner(); // 출력하는 것
    printWinner(winner);
  }

 

확실히 수정 전보다 각 역할이 분리되어 보기 좋다.

 

위의 케이스뿐만 아니라, 그 외 다른 코드에서도 const 라인과 바로 리턴하는 함수 사이에 의미 없는 공백이 있지는 않은지도 체크했다. 더불어, if와 여는 괄호 '(' 사이의 공백이 있는지, single quote로 잘 되어 있는지, 불필요한 주석이 있지 않은지 등등 컨벤션을 꼼꼼하게 체크했다.

 

컨벤션은 모두의 약속이자 규칙이니 지켜야 하는 것이 맞으니까!

 

 

☕️ 2주 차 소감

1️⃣ 같은 문제, 다른 해결

커뮤니티에서 같은 문제에 대해 다르게 바라보거나, 코드 리뷰를 주고받으며 많은 학습이 되었다. 프리코스 참여 이전에는 같은 애플리케이션을 구현한 다양한 코드를 볼 기회가 적었지만, 프리코스 과정을 통해 더 좋은 코드와 구조를 익히며 좁았던 세계를 넓혀가고 있는 느낌이다. 이번 2주 차에는 감사하게도 무려 9명의 지원자 분들로부터 코드리뷰를 받으며 '이렇게 생각할 수도 있구나'라고 느꼈다. 성장할 수 있는 기회를 주는 모든 사람들에게 정말 감사했다.

 

2️⃣ 리뷰에는 WHY를

코드 리뷰에 대한 새로운 관점도 배웠다. 단순히 “이건 이게 더 나아요” 와 같이 틀린 것을 고치는 관점보다, “이건 이러이러해서 더 좋고, 이 자료도 참고해 보시면 좋을 것 같아요”라는 구체적인 피드백을 주고받았다. 이를 통해 스스로는 타인에게 설명하며 더 깊게 공부할 수 있었고, 리뷰를 받을 때는 왜 더 좋은지에 대한 맥락을 이해할 수 있어 효과적으로 학습할 수 있었다. 9명의 코드 리뷰를 받는 동시에 나도 9명의 코드를 리뷰했는데, 설명하는 과정에서 내 의견을 뒷받침할 (혹은 그 사람에게 도움이 될만한) 자료도 찾고, 더 깊게 공부할 수 있어 일석이조였다.

 

3️⃣ 콧노래

2주 차 미션을 하면서 스스로에게 놀란 적이 있다. 콧노래를 부르며 코딩하는 내 자신을 발견한 것이다. 프리코스 과정을 잘 해낼 수 있을까 걱정했지만, 우려와는 달리 매주 명확한 목표와 요구사항이 주어지는 환경이 나에게는 굉장히 잘 맞았다. 물론 잠도 잘 못 자고 체력적으로 힘들긴 하지만, 감사하게도 하루하루 성장하고 있다는 느낌에 학습에 재미와 속도가 붙고 있다. 앞으로 남은 2주 동안 성장할 내 모습이 매우 기대된다.