활동내역.zip/개인

<우아한테크코스 2024 프리코스> 2주차 후기: 자동차게임

728x90

이 포스팅은 회고 겸 TroubleShooting 겸 한 주 간의 고민과정을 모두 정리해둔 글임을 알립니다

코수타, 코치들과의 수다 타임

물론 이 시점에서도 나는 수업을 듣고있었기에 집에 가는 길에 모두 들으며 유익한 시간을 보냈다.

https://www.youtube.com/watch?v=xwqIBM-vOdU

내 개인적인 입장에서는 참 아쉬운 시간대라고 생각한다. 하필 수업이 시작하는 그 시점에 이런 재미있는 행사들이 벌어지니 말이다. 이 이후에도 진행했던 5기 분들과의 이야기 시간 또한 수업시간과 겹쳐서 굉장히 아쉽다고 생각하고는 있다. 그래도 다시보기가 있어 참 다행이라고 생각하는데, 여기서 재밌는 말 하나를 들었다.

요구사항 분석을 제대로 하지 않고 작성한 코드는 결국 양념소스만 잘 되어있는 덜익은 치킨과 같아요.

어느 순간부터 음식과 관련된 이야기가 나오다가 질문을 받더니 음식으로 멋진 비유를 해주신 코치님들, 개인적으로 이해하기 쉽게 비유하기를 좋아하는 나에게는 정말 인상깊은 말이라 메모해두었다. 그 말이 맞다고 생각하는 것이, 요구사항을 모두 지키지 않고 작성한 코드는 겉보기에는 정상적으로 완성된 것 같은 양념치킨 같아보여도 안을 들여다보면 덜익어서 먹었을 때 탈이 날 수도 있다는 것과 같기 때문이다.
이 외에도 여러 질문들과 답변들이 오갔고, 이를 들으면서 유익한 시간을 보내며 집으로 돌아갔다.

1주차보다 월등히 향상된 실력, 적응해서일까?

적응해서인지 내가 잘해져서인지는 알 수 없다. 다만 요구분석부터 잘 돌아가는 코드로직을 짜는 그 순간까지는 전주차보다 훨씬 빨라져있었다.

말 그대로이다. 시간을 재 둔 것이 있어서 이를 통해 비교를 해보았었다.

요구사항 분석 및 구현할 기능 정리
- 3시간 -> 45분
코드로직 + 예외처리 작성
- 5시간 -> 2시간
  확실히 둘 다 절반 그 이하로 시간이 단축된 것을 알 수 있었는데, 이는 그 당시 몸상태가 좋지 않은 상태였음에도 몰입이 제대로 되었다는 것을 의미한다.
  물론 여러 이유들이 있을 것일라고 추측하고 있다. 1주차에 처음 써보는 객체지향형 프로그래밍에 적응하는 시간이 필요했을 수도 있고, 이미 한 번 해 본 상태에서 전주차보다 조금 더 로직이 쉬워서(혹은 쉽게 느껴져서) 그러는 것일수도 있다.

이번 과제는 지난 주 보다는 반복되는 로직이 적어 더 쉽게 느껴졌다.

가장 큰 이유가 있다면 이번에 2주차 안내할 때 말해주었던 한 가지의 안내사항과 관련이 있다.

여기서 함수를 분리하고 각 함수별로 테스트를 작성하는 것에 익숙해지는 것, 이 중 테스트를 작성하는 것에 대해서는 지난 주 특정 에러를 잡기위해 테스트를 뜯어보았던 것이 굉장히 도움이 되었다고 생각한다. 물론 이번에 조금 더 복잡하고 상세한 테스트를 구성하였다면 좋았겠지만, 그래도 예외처리가 제대로 돌아가는지 만큼은 확실히 확인해볼 수 있었다.

이번에 코드 어떻게 분리했어요?

1주차 때 함수를 분리하지 않고 그냥 한 파일에 모두 다 넣어놓았다면 이번에는 큰 기능을 하는 단위로 클래스를 분리하고, 그 안에 비슷한 기능을 하는 메서드들을 모아두는 형태로 코드를 분리했다.
또한 공통적으로 사용하는 조건이 붙어있는 숫자, 에러코드들을 모아두었으며, 에러코드에서 공통적으로 사용 되는 컨벤션인 [ERROR] 문자열 또한 분리해서 관리했다.
이렇게 정리하니 확실히 전보다 유지보수가 더 좋아진 느낌이었고, 오류가 발생했을 때 손쉽게 해결할 수 있어서 좋았다.

이번에 테스트 어떻게 구성했어요?

테스트는 이번에는 주로 예외처리에 관한 코드들로 구성하였다. 적어도 내가 직접 만들고 작성했던 부분에 대한 대부분의 예외에서는 테스트를 다 해보자 라는 생각으로 코드를 구성하였다.

주로 사전에 주어진 mocking된 데이터에서 오류가 나는 지 확인하는 방법으로 구성을 하였고, 예외처리와 관련된 테스트코드가 주를 이루었다.

직접 추가하고 돌렸던 테스트가 성공적으로 돌아가는 모습을 보니 기분이 좋았다.

위에 있는 Test Suites는 테스트 파일의 개수인 것 같았고,
아래에 있는 Tests는 모든 테스트 개수를 의미하는 것 같았다.
이렇게 추가해서 코드가 돌아가는 모습을 보니 이제 프로젝트를 할 때 테스트코드도 작성하며 할 수 있을 것 같은 느낌이 들었다.

마지막에 예기치 못한 오류가..! 그래도 해결해냈다!

물론 지금은 모두 해결을 한 상태로, 문제없이 예제 테스트에 통과하였지만, 처음 오류가 발생하였을 때에는 굉장히 당황했었다.

아마 누구라도 제출했을 때 저런 오류가 발생한다면 굉장히 당황했을 것이다. 그 당시 나는 실제로 두려웠다.

"분명 실행도 잘 되었고, 테스트도 모두 통과했는데.. 왜..?"

다행히 1주차때 많은 사람들이 올려준 해결방법들이 있었기에 하나하나 적용해보며 해결할 수 있었다.

이 문제는 빌드 오류로, 코드를 빌드하는 과정에서 어떤 문제가 생겼음을 나타내는 오류라고 한다.
그리고 아래에 올라와있는 해결방법과 시도방법들을 적어두었다.

프리코스의 경우에 사전에 작성되어있는 ApplicationTest.js 파일이 먼저 실행되기에 여기에 App.js가 올바른 경로로 import 되어있는 지 확인해야 한다.
- 이미 제대로 적용되어있기에 나에게는 적용되지 않는 문제였다.
불필요한 console.log가 남아있는 경우 이럴 수 있다.
- 실제로 console.log가 남아있었기에 이를 지우고 commit 해보았지만 똑같은 오류가 발생했었다.
node_modules와 package-lock.json 의 종속성 문제일 수 있기에 이를 지우고 npm i 를 이용해서 다시 설치해보면 될 것이다.
- 가장 유력한 답이라고 생각했지만 해결되지는 않았다.

저는 이렇게 해결했어요!

프리코스 커뮤니티의 힘은 굉장하다!

나는 커뮤니티에 "예기치 못한 오류" 라는 키워드로 검색을 하며 관련해서 사람들이 겪은 문제에 대해 알아보기 시작했고, src 내에 추가적인 폴더가 있는 경우에 이런 오류가 발생할 수 있다는 대화내용을 보았다.

그 당시 나는 아래와 같이 파일을 분리해서 코드를 작성했었고, 이는 그 대화내용의 오류 상황과 일치했다.
폴더를 통해 한번 더 묶어서 관리를 했고, IDE에서 잘 돌아갔고, 보기에도 예뻤지만, 제출 환경에서는 이를 원하지 않았던 모양이다.

그래서 폴더 내부에 있던 모든 파일들을 src 바로 아래에 들어오도록 변경하였다.

이렇게 변경하고 제출하니 빌드 오류는 사라졌고, 정상적으로 테스트가 실행되면서 이슈를 해결할 수 있었다.

와우! 정말 조마조마했는데 다행이네요!
모두 src 안으로 이동했지만 파일명을 잘 지어두어서 알아보기 편해 다행이었다.

과연 나는 1주차 공통 피드백을 2주차에 잘 적용했을까?

프리코스에서 1주차에 대한 공통적인 피드백을 보내왔다. 이번 주차 후기에서는 이 피드백이 잘 적용되어있는 지 확인해보는 걸 중점적으로 해보겠다.

피드백 내용은 아래와 같았다.

1. 요구사항을 정확히 준수한다

과제 제출 전에 기능 요구 사항, 프로그래밍 요구 사항, 과제 진행 요구 사항의 항목을 모두 잘 지켰는지 다시 한 번 점검한다.

기능 요구사항 및 프로그래밍 요구 사항 정확히 지키려고 함
- 실행환경 예시와 정확히 똑같은 결과가 나오도록 하기 위한 코드를 작성

2. 커밋 메시지를 의미 있게 작성한다

커밋 메시지에 해당 커밋에서 작업한 내용에 대한 이해가 가능하도록 작성한다.

아마 이정도면 내용에 대해 괜찮게 작성된 것이라고 본다. 물론 피드백을 받는다면 더 나아질 수 있을 것이다.

3. git을 통해 관리할 자원에 대해서도 고려한다

node_modules 는 package.json 파일이 있으면 설치할 수 있고 버전 관리를 직접 하지 않으므로 git으로 관리하지 않아도 된다.
Intellij의 .idea 폴더, VS Code의 .vscode 폴더 또한 개발 도구가 자동으로 생성하는 폴더이기 때문에 굳이 git으로 관리하지 않아도 된다.
앞으로 git에 코드를 추가할 때는 git을 통해 관리할 필요가 있는지를 고려해볼 것을 추천한다.

이부분은 간혹 깃허브에 DS Store이나 .vscode 등의 코드가 올라온 경우가 있어서 나온 피드백인 것 같다. 이미 잘 작성되어있는 .gitignore을 통해 올라가지 않는 상황이라 여기는 패스

4. Pull Request를 보내기 전 브랜치를 확인한다

기능 구현 작업을 fork된 Repository의 main branch가 아닌, 기능 구현을 위해 새로 만든 브랜치에서 작업한 후 PR을 보낸다.

여기는 내가 초반에 실수했던 부분이다. 브랜치를 만들어두고 체크아웃을 깜빡한 상태로 코드를 일부 작성했었다. 이를 깨닫고 나서 바로 브랜치를 옮긴 후 코드를 작성했다.

5. PR을 한 번 작성했다면 닫지 말고 추가 커밋을 한다

PR을 이미 한 번 보냈다면, 새로운 PR을 생성할 필요가 없다. 수정이 필요하다면 추가 커밋을 하면 자동으로 반영된다. 단, 미션 제출 기간 이후에는 추가 커밋을 하지 않는다.

이부분은 기존 프로젝트들을 통해 익혔던 내용으로 잘 지키고 있었다. 이번에는 예기치 못한 오류 를 해결하기 위해 추가 커밋을 하였다.

6. 이름을 통해 의도를 드러낸다

나 자신, 다른 개발자와의 소통을 위해 가장 중요한 활동 중의 하나가 좋은 이름 짓기이다. 변수 이름, 함수(메서드) 이름, 클래스 이름을 짓는데 시간을 투자하라. 이름을 통해 변수의 역할, 함수의 역할, 클래스의 역할에 대한 의도를 드러내기 위해 노력하라. 연속된 숫자를 덧붙이거나(a1, a2, ..., aN), 불용어(Info, Data, a, an, the)를 추가하는 방식은 적절하지 못하다.

이 부분은 리팩터링 하면서 많은 고심을 했던 부분이다. 10분 테코톡과 같은 여러 기업들에서 제공하는 영상들을 보며 클린코드에 대한 것들을 익히고 있는데, 이름만 보고도 확실히 구분할 수 있는 변수명, 메서드명을 짓기 위한 시도들을 했다.

그래도 읽었을 때 무슨 의미를 하는 지 1주차보다는 더 명확해진 것 같아서 기분이 좋았다.

7. 축약하지 않는다

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

위에서 잘 지키고 있는 것 같다고 판단하여 넘어가겠다.

8. 축약 예외

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

객체 지향 생활 체조 원칙 5: 줄여쓰지 않는다 (축약 금지)

여기는 피드백을 받아들여야 하는 부분이다. 지금 작성하면서 확인해보니, 중복되어있으며, 간결한 호출 표현이 되지 않은 네이밍을 발견할 수 있었다.

클래스이름과 메서드 이름에 Exception이 중복되어있지 않은가.

하지만 여기서 궁금한 점이 있다. 실제로 이 부분은 호출되지 않고 결국 이 모든 것을 묶어서 한번에 호출한 check()라는 메서드만 다른 파일에서 호출되는데, 이를 줄일 필요가 있을까?

실제로 이 클래스가 호출되는 App.js 에서는 InputCarsException.check() 처럼 간결하게 호출되고 있기 때문이다.
대신, check() 메서드 내에서는 빠르게 확인하기 위해 축약하지 않고 작성하였다. 잘 작성된 코드인 것인지 궁금하다.

이런 느낌으로 호출 시점에서는 간결하게 표현되어있는 것 같다.
아, 물론 RacingGame.racing()은 한 번 변경하는 것도 괜찮아 보인다고 생각이 들기도 한다.

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

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

이 부분은 이미 prettier과 eslint 를 통해 자동으로 관리되고 있기에 넘어갔다.

10. 공백 라인을 의미 있게 사용한다

공백 라인을 의미 있게 사용하는 것이 좋아 보이며, 문맥을 분리하는 부분에 사용하는 것이 좋다. 과도한 공백은 다른 개발자에게 의문을 줄 수 있다.

공백 라인은 메서드마다 1줄로 설정하였고, 그 사이 공백에 주석을 통해 구분되도록 설정하였다.
주석이 필요없는 메서드/코드의 경우 그 사이를 공백 1줄로만 남겨두었다.

11. space와 tab을 혼용하지 않는다

들여쓰기에 space와 tab을 혼용하지 않는다. 둘 중에 하나만 사용한다. 확신이 서지 않으면 pull request를 보낸 후 들여쓰기가 잘 되어 있는지 확인하는 습관을 들인다.

기본적으로 IDE에 잘 마련되어있는 기능이기도 하고, 이 또한 prettier에서 설정이 가능한 부분이기도 하다.
코드를 배울 때 space 를 통해 들여쓰기를 하지 않는 기본기를 익혀두었기에 이 부분도 잘 적용되어있다고 보고 넘어가겠다.

12. 의미 없는 주석을 달지 않는다

변수 이름, 함수(메서드) 이름을 통해 어떤 의도인지가 드러난다면 굳이 주석을 달지 않는다. 모든 변수와 함수에 주석을 달기보다 가능하면 이름을 통해 의도를 드러내고, 의도를 드러내기 힘든 경우 주석을 다는 연습을 한다.

이 부분은 추가적으로 작업이 필요한 부분이다. 리팩터링을 통해 이름을 변경하였기에 그 전에 달아두었던 주석이 필요없어졌을 수도 있다. 확인해보고 추가적으로 변경하고, 필요하면 주석을 달고 필요없으면 주석을 제거해야겠다.

13. linter와 Code Formatter의 기능을 활용한다

가능하면 eslint와 prettier를 이용해 더욱 생산적으로 코드를 작성하자.

린트(lint)는 소스 코드에 문제가 있는지 탐색하는 작업을 의미하며, 린터(linter)는 이 작업을 도와주는 소프트웨어를 말한다. 자바스크립트와 같은 인터프리터 언어의 경우, 런타임 에러가 발생할 확률이 높기 때문에, 이 린트 작업을 통해 사전에 에러를 최대한 잡아준다면 훨씬 생산성 높은 개발을 할 수 있다. lint 중 eslint는 자바스크립트 진영의 오픈소스로 확장되고 있는 정적 분석 도구이다.

prettier는 일종의 Code Formatter이다. Code Formatter란 개발자가 작성한 코드가 정해진 코딩 스타일을 따르도록 변환해주는 도구이다. 이 두 가지 도구를 이용하면 코드를 짜는데 발생할 수 있는 오류를 미리 예방하고 쉽게 정돈할 수 있다.

https://time-map-installer.tistory.com/211
이미 이전에 작성해둔 글이 있기에 공유하겠다. 이 중요성은 몇 번의 프로젝트와 개발 경험으로 잘 알고 있다.

13. EOL(End Of Line)

최종 제출하는 코드에서 EOL을 확인한다. 환경에 따라 의도한 바와 다르게 개행 문자 처리가 되지 않도록 EOL 설정을 확인한다.

이 부분은 처음 듣는 부분이었다. 그래서 알아보았는데, UNIX 환경으로 개발된 Mac과 다르게 Windows 환경에서는 줄바꿈 처리가 다른 문자열로 처리된다고 한다. VSCode에서 설정할 수 있다고 하기에 후에 팀 협업 시 이를 고려해야겠다.

14. 불필요한 console.log를 남기지 않는다

디버깅을 위해 사용한 console.log가 최종 제출하는 코드에 의미 없이 남아있지 않도록 주의한다.

이 부분은 확인과정에서 남아있는 코드를 발견하였고, 제거하였다.

15. JavaScript에서 제공하는 API를 적극 활용한다

함수(메서드)를 직접 구현하기 전에 JavaScript API에서 제공하는 기능인지 검색을 먼저 해본다.
JavaScript API에서 제공하지 않을 경우에 직접 구현한다.
예를 들어 우승자를 출력할 때 우승자가 2명 이상이면 쉼표(,) 기준으로 출력을 위한 문자열은 다음과 같이 구현할 수 있다.

const members = ['east', 'west', 'south'];
members.map((member) => member).join(','); // "east,west,south"

이 부분에 대해서는 잘 활용한 것 같다. 코드리뷰를 거치면서 이 부분도 피드백 받으면 좋을 것 같다.

프리코스의 힘, 연관 검색어에 뜰 정도라고?

분명 변수명을 위해 구글에 전진을 영어로 어떻게 하는 지 검색을 했을 뿐인데..
자동차 전진 영어로가 뜨는 것을 보면 정말 많은 사람들이 열정적으로 프리코스에 참여하고 있다는 것을 알 수 있었다. 재미있는 에피소드였기에 한 번 적어보았다 😄

마치며: 감기와 함께했던 2주차, 몰입이 이런거구나!

진정한 몰입은 지금 현재 내 몸상태가 어떻든 그 상태를 잊고 일정시간 집중할 수 있는 상태에 도달하는 것이다.

이 말은 내가 지어낸 말이며, 계속되는 감기와 함께 진행했던 프리코스 2주차에서 얻어낸 깨달음이다.
최근 반년 이상 건강했다가 갑작스럽게 환절기가 왔다고 이런 고생을 하다니.. 몸이 아프니 수면제 성분의 약을 지속적으로 먹어야 했고 생각보다 오래 깨어있을 수가 없어 아쉬웠다.
그럼에도 프리코스에 몰입을 하는 그 순간만큼은 아프고 몸이 나른한 느낌이 들지는 않았다. 아니면 몸이 아프니깐 더 집중해서 빠르게 끝내야한다라는 생각이 들어서였을수도 있다.

그동안에 무언가 몰입하는 느낌을 알고있었고, 몰입이 끝나면 그 날 하루가 쾌적하게 느껴져서 참 좋았는데 이번에는 몸이 아프다보니 몰입이 끝나면 에너지가 소진되어 잠에 들기를 반복했던 것 같다.
무언가 이상했다. 분명 몰입이 끝나면 에너지가 순환이 되면서 하루가 더 쾌적해야 할 텐데? 라고 생각했지만
목 부음 + 비염 + 식은땀 + 어지러움증 + 근육통이 같이 찾아온 상태라는 것을 생각해보면 몰입하면서 에너지를 몰아서 쓴 것이 아닐까 싶다.

목~금: 목감기로 인해 아파서 병원가서 주사맞고 약 처방
주말 외부행사 진행
월: 월! 월! 월! 월!
화: 몸상태 악화되어 휴식
수: 근육통 발생해서 휴식

이런 상태에서도 몰입이 되는 것을 보고 현재 상태와 상관없이 가능하다 라는 것을 알 수 있었다.

물론 시간 투자가 평소보다는 적어졌지만, 그래도 할 수 있다는 것이 어디일까?
다음 과제에서는 몸이 회복되고 더 많은 에너지를 투자할 수 있게되면서 재밌는 일들이 많이 일어날 것 같다.
이번 주 후기를 마치도록 하겠다.

End