[우테코 프리코스] 2주 차 회고

📌 2주 차 미션 : 레이싱 카 게임

레이싱 카 게임은

자동차 이름 목록과 경주할 횟수를 사용자에게서 입력받고

가장 많이 전진한 자동차 이름을 출력하는 게임입니다.

 

요구사항들을 읽어보면서 1주 차와 달리

오 이번 과제 조금 복잡하겠는데?라는 생각이 들었습니다.

(3주 차 과제를 받은 지금 레이싱카 게임이 그립네요..)

 

입력을 받은 값을 하나씩 검사해야 하고

개별로 점수를 매기며

우승자가 2명 이상 일 수 있다는 점에

난이도가 상승한 느낌이 들었거든요 🥹

---

👩🏻‍💻 커밋주기는 얼마가 적당할까?

과제 요구 사항에 기능 단위 커밋을 한다고 적혀있는데

작성한 기능 목록 단위로 작성을 해야 할지

각 기능 안의 세분화된 기능들 단위로 작성을 해야 할지

스스로도 기준이 명확하지 않았습니다.

 

때마침 디스코드에서 커밋 단위에 대한 질문이 올라왔는데

그 내용은 아래와 같았습니다.

1. 여러 부속 메서드들 포함 전체 기능이 잘 동작하는지 확인 후 커밋

장점 : 전체적으로 완성된 기능을 확인할 수 있다.

단점 : 숙달된 개발자가 아니라면 에러 추적이 어렵다.

 

2. 정상적 동작하는지 확인이 어렵지만 개별 메소드를 완성한 그 즉시 커밋

장점 : 세부적으로 작업 목록을 알 수 있기에 에러 추적이 쉽다.

단점 : 제대로 동작하지 않는 코드를 커밋하는 것은 위험하다.

 

저는 정상적으로 기능이 동작하는 선에서 자주 커밋을 하는 게 좋겠다는 결론을 내었습니다.

개별 기능들이 어느 시점에서 구현이 완료되었는지 알 수 있어

로직을 연결하는 과정에서 문제가 발생했을 때 추적이 쉽다는 장점이 있기 때문입니다.

 

또한 숙달된 개발자라면 1번 방식에서 오류 발생 시 빠르게 원인을 찾을 수 있겠지만

그렇지 않은 경우 에러 추적에 쓰는 비용이 클 것이라는 한 크루의 의견에도 동의합니다.

---

✔️ 코드컨벤션 설정

- 출력 문구는 모두 상수 화해서 사용한다.

- 에어비앤비 스타일 가이드를 따른다.

 

코드 컨벤션 또한 미리 설정해 높으면 개발 생산성이 높아집니다.

프리코스에서는 에어비앤비 자바스크립트 스타일 가이드를 따르도록 되어있는데 

그 내용이 많기도 하고 일일이 적용하긴 어렵다고 판단해서

 

package.json을 변경하지 않되

1주 차 과제 피드백에서 제안한 바와 같이 Linter를 적용하기 위해

과제 폴더 위에 package.json을 두고

prettier와 ESLint를 설치해 사용했습니다.

---

🗂️ 폴더 구조에 관한 고민

1주차 과제에서는 프로그램이 시작되는 파일에서 게임 시작 함수만 남기고

나머지 함수들은 모두 한 파일에 작성을 했었습니다.

그렇게 작성을 하고 나니 성격이 다른 함수들이 한 폴더에 섞여있어

추후 확장성을 고려했을 때 유지 보수 하기 힘들 것 같았습니다.

 

이번 과제에서는

프로그래밍 시작 파일인 App.js에는 전체적인 로직만 남기고

실질적으로 게임을 위해 실행되는 함수들 중

검증 역할을 하는 validator함수들은 utils에

게임의 각 기능들을 수행하는 함수들은 functions 폴더에 나누었습니다.

 

코드리뷰 올려주신 PR들을 살펴보면 MVC 패턴을 적용하신 분들이 많던데

저는 아직 왜, 어떻게 사용하는지에 대한 공부가 충분히 되어있지 않아서 적용하지 않았습니다.

📦src
 ┣ 📂constants
 ┃ ┣ 📜messages.js
 ┃ ┗ 📜numbers.js
 ┣ 📂functions
 ┃ ┣ 📜canMoveFoward.js
 ┃ ┣ 📜startRacing.js
 ┃ ┗ 📜whoIsWinner.js
 ┣ 📂utils
 ┃ ┗ 📜validator.js
 ┣ 📜App.js
 ┗ 📜index.js

 

피드백 반영하기

2주 차 과제와 함께 1주 차 과제 피드백이 함께 첨부되어 있었습니다.

그중에 코드를 작성하면서 스스로 의문이 들었던 부분을

명확히 할 수 있어서 좋았던 두 가지 사항이 있었습니다.

 

1. 축약하지 않는다.

의도를 드러낼 수 있다면 이름이 길어져도 괜찮다.

누구나 실은 클래스, 메서드, 또는 변수의 이름을 줄이려는 유혹에 곧잘 빠지곤 한다. 그런 유혹을 뿌리쳐라. 축약은 혼란을 야기하며, 더 큰 문제를 숨기는 경향이 있다. 클래스와 메서드 이름을 한 두 단어로 유지하려고 노력하고 문맥을 중복하는 이름을 자제하자. 클래스 이름이 Order라면 shipOrder라고 메서드 이름을 지을 필요가 없다. 짧게 ship()이라고 하면 클라이언트에서는 order.ship()라고 호출하며, 간결한 호출의 표현이 된다.- 객체 지향 생활 체조 원칙 5: 줄여 쓰지 않는다 (축약 금지)

코드를 작성할 때 변수명을 잘 짓는 것은 어렵고도 가장 중요한 작업인데요

단어가 3-4개를 넘어가는 순간 괜히 좋아 보이지 않았었습니다.

줄였을 때 뭔가 더 있어빌리티가 있었거든요.. 예를 들어 button을 btn이라 한다던가...

 

이 피드백을 보고서는 맘 놓고(?)

마음대로 축약하지 않으면서 명시적으로 작성하기 위해 노력했습니다.

 

예를 들어 checkValid라는 유효성 검증 함수를 isValidCarsName으로

1. boolean을 리턴하고

2. 유효성을 확인하며

3. 어떤 값을 필요로 하는지

알 수 있게끔 작성하였습니다.

 

영어로 변수명을 짓기에 더 어려운 부분도 있지만

한글로 작성했어도 쉽지 않은 일임이 분명합니다.

 

저는 그래서 chatGPT를 활용했습니다.

함수의 기능을 설명하고 변수명을 추천해 줘! 하면

아주 적절한 단어를 가지고(물론 터무니없는 단어가 나올 때도 있습니다.)

여러 개를 추천해 주는데 그중에 쓸만한 동사를 가지고

제 나름대로 재구성하여 사용하곤 했습니다.

 

얼마 전 매주 목요일 2시에 열리는 '코수타'에 출연한 코치분이

우리가 코드 작업을 하며

intelliJ나 vsCode의 도움을 받는 것처럼

chatGPT도 결국 하나의 도구에 불과하다고 했습니다.

 

이처럼 전적으로 chatGPT를 너무 의존하지 않는 선에서

적절히 활용하면 생산성을 높일 수 있는 것 같습니다 :)

2. 공백도 코딩 컨벤션이다.

if, for, while문 사이의 공백도 코딩 컨벤션이다.

 

코드의 가독성을 위해서는 적절한 공백이 필요하다고 생각하는데

코드를 모두 작성하고 이 피드백을 보니

if문과 while문 사이에 공백을 주지 않은 저의 만행을 보았습니다.

 

예를 들어 변수를 선언하고

해당 변수를 if 또는 while문 안에서 사용한다면

둘이 아주 착붙해서 코드를 작성해 두었습니다. ^^

 

이처럼 코드를 작성하면서

생각해 보면 별 일 아닌 것에 고민을 하는 부분을

피드백으로 명확히 정의할 수 있어서

2주 차 피드백도 기대가 됩니다!

함수의 return문

이건 다른 분 코드리뷰를 보다가 알게 된 점인데

return으로 함수를 호출하면 코드의 흐름을 이해하기 어렵고 디버깅에 어려움이 생긴다는 점입니다.

 

예를 들어서

      if (isRacingAttemptsValid(this.attemptTimes)) {
       	return startRacing(this.attemptTimes, this.carList);
      }

 

 

게임을 시작하는 함수를 return 문에 작성해 줌으로써

해당 함수 실행이 끝나면 해당 코드가 종료되게 작성하였습니다.

이렇게 된다면 코드의 흐름의 끝은 startRacing 내에서 끝나게 되고

메인 로직에서는 명시적으로 그 결과를 알 수 없습니다.

 

따라서 return 문을 사용하여 함수를 호출하는 대신

함수를 명시적으로 호출하고 결과를 변수에 저장하는 것이 좋습니다.

      if (isRacingAttemptsValid(this.attemptTimes)) {
        const winner = startRacing(this.attemptTimes, this.carList);
        Console.print(`${MESSAGES.WINNER} ${winner}`);
        return;
      }

startRacing 함수의 결과로 받은 값을 winner 변수에 할당해 주고

winner를 console에 print 합니다.

(여기서 startRacing의 결과보다는 우승자 결과를 반환하는 함수면 더 좋겠네요 ㅜ^ㅜ)

그리고 if 문이 끝나기 전에 return을 하여 함수를 종료합니다.

---

💡 배운 점

테스트 코드를 작성해 보다!

함수를 분리하고 각 함수별 테스트 코드를 작성하는 것이 2주 차 미션 학습 목표였습니다.

npm t로 실행 해본 적은 많지만 (빨간 fail이 뜰 때의 서러움..)

직접 테스트 코드를 작성해 본적은 없는데 이번 기회에 테스트 코드에 대해서 학습할 수 있어서 좋았습니다.

 

테스트 코드를 작성하는 방법은 기본적으로 간단합니다.

어떠한 함수를 실행했을 때 결괏값이 이럴 것이다~라는 단순한 구조인데요

 

'describe'로 테스트 그룹을 묶어주고

콜백함수 내에 테스트에 쓰일 가짜 변수, 객체들을 선언해서 사용할 수 있습니다.

expect함수의 매개변수로 들어오는 함수의 결괏값이

toXXX라는 Test Matcher 함수에 맞는지 test 하게 작성하면 됩니다.

 

Test Matcher는 정확한 값은 물론

배열의 경우 특정 요소가 존재하는지

오류를 던지고 있는지 등

다양한 상황들을 제공합니다.

 

저는 boolean 값을 return 하는 검증함수들을 가지고

간단한 toBeFalsy, toBeTruthy Test Matcher를 사용하여

test코드를 작성해 보았습니다.

describe('유효성 검증 함수 테스트', () => {
  test('자동차 리스트 길이', () => {
    const inputs = ['a', 'b', 'c', 'd', 'e', 'f', 'g', 'h', 'i', 'j', 'k'];
    expect(isCarListValid(inputs)).toBeFalsy();
  });
  test('시도 횟수 범위', () => {
    const input = 7;
    expect(isRacingAttemptsValid(input)).toBeTruthy();
  });
});

---

⚒️ 3주 차에서는

- 클래스를 적극적으로 활용하기

- mock 함수를 활용한 테스트 코드 작성하기

---

🎙️소감

다른 크루분들의 1주 차 회고글을 보면서 저도 저렇게 꼼꼼히 기록해 두어야겠다..!라고 생각했는데 실천하기 쉽지 않네요..ㅠ^ㅠ

2주 차 학습 주제였던 함수의 분리와 함수 테스트 구현 중 테스트 구현을 제대로 학습하지 못해서 아쉬운 점이 남았던 이번 과제였습니다.

3주 차 과제에서는 제대로 학습할 수 있도록 열심히 해보겠습니다!

의도치 않게 1주일에 한 번 우테코 프리코스 디스코드 모각코방에서 새벽 코드리뷰 타임이 있는데

칭찬도 많이 해주시고 날카로운 지적도 해주셔서 유익하고 즐거운 시간을 보냈습니다 :) 

 

처음에는 프리코스만 경험해 보자..!라는 마음으로 신청했는데 (합격할 것이라는 전제는 아예 존재하지 않았던...)

디스코드에서의 소셜과 코드리뷰 타임이나 코수타, 오 수타에 참석해 보니

열정 넘치는 분들과 같이 성장하는 기쁨을 맛볼 수 있어서 합격에 조금 욕심이 나기 시작했습니다 😂

물론 탈락하더라도 이만큼의 성장과 경험, 네트워킹은 프리코스가 아니었다면 느낄 수 없었을 것 같아요 

 

3주 차 과제는 5기 프리스코스 후기에서도 악명 높았던 로또입니다.

아직 기능 구현 목록만 작성한 상태인데 어떻게 코드로 구현해야 할지 조금 무섭지만..... 파이팅!