20241023 우테코 프리코스 1주차 피드백, 2주차 체크리스트, 좋은 에러 메시지 작성법, 자바스크립트 변수와 상수, 네이밍 컨벤션

October 23, 2024

우테코 프리코스 1주차 과제를 제출했다.
프리코스 과정은 공통으로 피드백이 진행되므로 공통 피드백을 정리해보려고 한다.

우테코 프리코스 1주차 과제 공통 피드백

학습 목표 : 개발 환경과 프로그래밍 언어에 익숙해지기
▶ ✅ 간단한 과제였어서 git에 익숙해지기(clone, branch 생성, pull request 등)인것 같다고 생각했었는데 맞았나보다.

프로그래밍을 처음 접하고 개발 환경이 낯설게 느껴진다면 우아한테크코스의 테코톡 동영상 참고하기. 테코톡은 우아한테크코스 크루들이 관심 있는 기술 주제를 스스로 공부하고 공유하는 문화. 앞으로도 미션을 수행하면서 어려운 점이 있으면 테코톡을 통해서 학습하고 구현해 보는 것을 추천.
유튜브 테코톡 재생목록

요구 사항을 정확하게 준수한다 ⭐️

과제 제출 전 과제 진행 요구 사항, 기능 요구 사항, 프로그래밍 요구 사항 모두 충족하였는지 다시 한번 확인. 이런 요구 사항들은 미션마다 다르므로 항상 주의 깊게 읽어본다.
▶ ✅ 이번에 실수를 하나 했다. 기능 요구 사항의 예 부분에 "" => 0,라는 부분을 처음에는 읽고 기억하고 있었는데, 나중에는 이 부분을 까먹고 그냥 에러 처리를 해버렸다. 꼭 꼼꼼하게 읽고 마지막에 한번 더 확인하자

기본적인 Git 명령어를 숙지한다

Git은 개발자 간의 협업을 위한 가장 기본적인 프로그램. 컴퓨터 파일의 변경 사항을 추적하고 여러 사용자 간의 해당 파일에 대한 작업을 조정한다.
[10분 깃코톡] 와일더의 Git Commands
[10분 테코톡] 주노의 git commands
[10분 테코톡] 망쵸의 유용한 Git 명령어
[10분 테코톡] 망쵸의 유용한 Git 명령어
▶ ❌ 강의 보기

Git으로 관리할 자원을 고려한다

package.json 파일만 있으면 node_modules 폴더를 생성할 수 있다. 따라서 Git을 통해 node_modules 폴더를 관리할 필요가 없다. IntelliJ IDEA의 .idea 폴더와 Visual Studio Code의 .vscode 폴더도 IDE에서 자동으로 생성하는 폴더이므로 Git으로 관리할 필요가 없다. Git에 코드를 추가할 때는 Git을 통해 형상 관리해야 하는 코드인지 고려하는 것이 좋다. 또한 .gitignore에 대해서도 알아본다.
▶ ❌ package.json 파일?

package-lock.json의 역할을 이해한다

package.json 파일은 일반적으로 유의적 버전(semantic versioning)을 사용하며, package-lock.json에는 파일이 생성될 당시의 의존성 트리에 대한 정보가 있다. 이를 통해 node_modules를 커밋하지 않더라도 팀원들이 동일한 의존성을 설치할 수 있게 한다.
▶ ❌ package-lock.json 파일? 유의적 버전?

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

해당 커밋에서 수행된 작업을 이해할 수 있도록 커밋 메시지를 작성. 팀의 좋은 코드 리뷰 문화는 작은 커밋을 작성하는 것에서 비롯된다.
좋은 git 커밋 메시지를 작성하기 위한 7가지 약속
▶ ✅ 이건 내가 신경 쓴 부분이다. 나도 좋은 git 커밋 메시지에 대한 글을 작성했는데 우테코에서 글을 공유해줬다. 내가 작성한 글과 내용은 비슷한데 이 글에서는 제목은 영문 기준 50자 이내, 본문은 영문 기준 72자마다 줄 바꾸기를 얘기하고 있다.

커밋 메시지에 이슈 또는 풀 리퀘스트 번호를 포함하지 않는다

프리코스 과정에서는 커밋 메시지에 이슈 또는 풀 리퀘스트 번호를 포함하면 원본 저장소의 관련 없는 이슈 또는 풀 리퀘스트에 영향을 미칠 수 있기 때문에 포함하지 않도록 한다.
▶ ✅ 커밋 메시지에 이슈 번호를 넣는 건 처음 알게 된거였어서 해보고 싶었는데 안하는걸로!

풀 리퀘스트를 만든 후에는 닫지 말고 추가 커밋을 한다

이미 풀 리퀘스트를 생성하면 변경을 위해 새 풀 리퀘스트를 만들 필요가 없다. 변경이 필요한 경우 추가 커밋을 하면 자동으로 반영된다. 그러므로 미션 제출 기간 이후에는 추가 커밋을 금지한다.
▶ ✅ 이것도 고민했던 부분! 풀 리퀘스트를 닫아야 하는지, 열어둬야 하는지 고민했는데 다른 사람들 다 열어뒀길래 닫지 않았다. 안 닫는게 맞는가 보다.

오류를 찾을 때 출력 함수 대신 디버거를 사용한다

디버깅은 프로그램 오류를 감지하고 수정하는 과정이다. 문법 오류와 같이 컴파일러가 처리하기 때문에 쉽게 발견할 수 있는 오류도 있지만, 어느 지점에서 오류가 발생했는지 파악하기 어려운 경우도 있다. 이때 코드 중간에 console.log()를 사용하여 매번 코드를 실행하여 문제를 파악할 수 있으나, 이는 비효율적이며 불필요한 코드가 남을 수 있다. 하지만 디버거를 이용하면 코드 내부의 상태 값이 어떻게 변하는지, 어떤 흐름으로 프로그램이 실행되는지 이해할 수 있다. 현재 사용 중인 IDE에서 애플리케이션을 디버깅하는 방법을 학습한다.
[10분 테코톡] 🍟 웨지의 인텔리제이 디버깅
[10분 테코톡] 오리의 Intellij Debugging
[10분 테코톡] 몰리의 디버깅
Debugging in Visual Studio Code
▶ 🔺 나도 출력 함수를 계속 써서 확인을 했는데 이제부터는 디버거를 사용해보자. 내 개발환경은 VS Code니까 마지막 영상을 보면 될 것 같다.

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

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

축약하지 않는다

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

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

▶ ✅ 이름을 의도가 잘 드러나도록, 그리고 의도를 드러내기 위해 축약하지 말자. 축약은 하지 않되, 한 두단어로 유지하려고 노력하고 문맥을 중복하는 이름을 자제하자.

공백도 코딩 컨벤션이다

if, for, while문 사이의 공백도 코딩 컨벤션이다.
▶ ✅ 다행히 신경쓴 부분이다. 마지막에 공백을 통일시켜줬다.

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

공백 라인을 의미 있게 사용하는 것이 좋아 보이고 문맥을 분리하는 부분에 사용하는 것이 좋다. 하지만 과도한 공백은 다른 개발자에게 의문을 줄 수 있다.
▶ ✅ 의미 있게 사용했다고 생각한다. 그런데 공백 라인조차도 피드백 사항인게 신기하다.

스페이스와 탭을 혼용하지 않는다

들여쓰기에 스페이스(space)와 탭(tab)을 혼용하지 않는다. 둘 중의 하나만 사용한다. 확신이 서지 않으면 풀 리퀘스트를 작성한 후 들여쓰기가 잘 되어 있는지 확인하는 습관을 들인다.
▶ ✅ 난 탭만 사용하는 것 같아서 혼용한 것 같지는 않다. 이런 부분도 신경 써야 하는 줄 몰랐다.

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

변수 이름, 함수(메서드) 이름을 통해 어떤 의도인지가 드러난다면 굳이 주석을 달지 않는다. 모든 변수와 함수에 주석을 달기보다 가능하면 이름을 통해 의도를 드러내고, 의도를 드러내기 힘든 경우 주석을 다는 연습을 한다.
▶ ✅ 주석을 아예 달아야 한다는 생각을 안하고 있었는데, 다른 사람들 코드를 보니까 주석을 단 경우도 있어서 주석의 필요성에 대해서 생각해 보게 되었었다. 그런데 의도가 이름에서 드러나면 주석 O, 의도가 이름에 드러나지 않으면 주석 X 인걸로!

코드 포매팅을 사용한다

코드 포매팅과 구조화는 클린 코드를 위한 최소한의 요구 사항. IDE의 코드 자동 정렬 기능을 사용하면 더 깔끔한 코드를 볼 수 있다.

IntelliJ IDEA: ⌥⌘L, Ctrl+Alt+L
Eclipse: ⇧⌘F, Ctrl+Shift+F
Visual Studio Code: ⇧⌥F, Shift+Alt+F

▶ ✅ 개발환경에 코드 자동 정렬 기능이 있는지 몰랐는데 사용해보자.

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

함수(메서드)를 직접 구현하기 전에 API에서 해당 함수를 제공하는지 확인한다. 예를 들어 사용자를 출력할 때 사용자가 둘 이상인 경우 쉼표(,) 기반 문자열을 출력하도록 다음과 같이 구현할 수 있다.

const members = ['pobi', 'jason'];
members.map((member) => member).join(','); // pobi,jason

▶ ✅ 확인완료!

추가 학습 자료

우테코에서 실제로 수업이 어떻게 진행되는지, 이번 과제 요구 사항을 어떻게 구현했는지를 볼 수 있는 피드백 강의 동영상.

코드가 중복되면 메서드 분리. 근데 메서드 분리 없이 가능한지도 생각해 볼 것.
적절한 이름인지 고민. 이름을 봤을 때 어떤 코드인지 알 수 있는가.
테스트 케이스 추가. 예외 테스트와 아닌 테스트 구분.
어떤 예외 테스트인지 보여주기 위해 @DisplayName 사용.
차근차근 요구사항 복붙해서 기능 구현. 요구 사항도 쪼개서 제일 작은 단위로 생각해보기.
목적을 달성하려는 중간에 나오는 가지들(ie. 이 부분은 이렇게 처리하는게 더 좋지 않을까?, 이런 예외를 처리해야 하지 않나? 등)은 우선 주석 달고 넘어가기.

상수로 분리가 필요한지 for 가독성과 의미전달.
ex )

public static in sum(final String text){
  text.split(",");
}

public static final String INPUT_DELIMITER = ",";

public static in sum(final String text){
  text.split(INPUT_DELIMITER);
}

두 코드 중에 어떤 코드가 text를 ,를 기준으로 구분한다라는 의미 전달에 적절한지를 고민해서 코드 작성.

▶ ✅ 영상 확인 완료.

우테코 프리코스 2주차 과제 체크리스트

# 학습목표
- [x] 여러 역할을 수행하는 큰 함수를 단일 역할을 수행하는 작은 함수로 분리한다.
- [x] 테스트 도구를 사용하는 방법을 배우고 프로그램이 제대로 작동하는지 테스트한다.
- [x] 1주 차 공통 피드백을 최대한 반영한다.
<br>

# 과제 제출 전 체크 리스트
- [x] 요구 사항에 명시된 출력 형식을 따랐는가
- [x] 모든 테스트가 성공적으로 실행되는가
<br>

# 과제 진행 요구 사항
- [x] 미션은 자동차 경주 저장소를 포크하고 클론하는 것으로 시작한다.
- [x] 기능을 구현하기 전 README.md에 구현할 기능 목록을 정리해 추가한다.
- [x] Git의 커밋 단위는 앞 단계에서 README.md에 정리한 기능 목록 단위로 추가한다.
- [x] AngularJS Git Commit Message Conventions을 참고해 커밋 메시지를 작성한다.
<br>

# 기능 요구 사항
- [x] 주어진 횟수 동안 n대의 자동차는 전진 또는 멈출 수 있다.
- [x] 각 자동차에 이름을 부여할 수 있다.
- [x] 전진하는 자동차를 출력할 때 자동차 이름을 같이 출력한다.
- [x] 자동차 이름은 쉼표(,)를 기준으로 구분한다.
  - [x] ex) pobi,woni,jun
- [x] 자동차 이름은 5자 이하만 가능하다.
- [x] 사용자는 몇 번의 이동을 할 것인지를 입력할 수 있어야 한다.
  - [x] ex) 5
- [x] 전진하는 조건은 0에서 9 사이에서 무작위 값을 구한 후 무작위 값이 4 이상일 경우이다.
- [x] 차수별 실행 결과를 출력한다.
  - [x] ex) pobi : --\n woni : ----\n jun : ---
- [x] 자동차 경주 게임을 완료한 후 누가 우승했는지를 알려준다. 우승자는 한 명 이상일 수 있다.
  - [x] 단독 우승자일 경우 ex) 최종 우승자 : pobi
- [x] 우승자가 여러 명일 경우 쉼표(,)를 이용하여 구분한다.
  - [x] 공동 우승자일 경우 ex) 최종 우승자 : pobi, jun
- [x] 사용자가 잘못된 값을 입력할 경우 "[ERROR]"로 시작하는 메시지와 함께 Error를 발생시킨 후 애플리케이션은 종료되어야 한다.
- [x] 실행 결과 예시
/*
경주할 자동차 이름을 입력하세요.(이름은 쉼표(,) 기준으로 구분)
pobi,woni,jun
시도할 횟수는 몇 회인가요?
5

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

pobi : --
woni : -
jun : --

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

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

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

최종 우승자 : pobi, jun
*/
<br>

# 프로그래밍 요구 사항
- [x] Node.js 20.17.0 버전에서 실행 가능해야 한다.
- [x] 프로그램 실행의 시작점은 App.js의 run()이다.
- [x] package.json 파일은 변경할 수 없으며, 제공된 라이브러리와 스타일 라이브러리 이외의 외부 라이브러리는 사용하지 않는다.
- [x] 프로그램 종료 시 process.exit()를 호출하지 않는다.
- [x] 프로그래밍 요구 사항에서 달리 명시하지 않는 한 파일, 패키지 등의 이름을 바꾸거나 이동하지 않는다.
- [x] 자바스크립트 코드 컨벤션을 지키면서 프로그래밍한다.
- [x] 기본적으로 JavaScript Style Guide를 원칙으로 한다.
  - [x] Airbnb 자바스크립트 스타일 가이드
  - [x] 네이밍 컨벤션
    - [x] 소스의 변수명, 클래스명 등에는 영문 이외의 언어를 사용하지 않습니다.
    - [x] 클래스, 메서드 등의 이름에는 특수 문자를 사용하지 않습니다.(ex) function $some(){} (x))
    - [x] 상수명은 SNAKE_CASE(전부 대문자. ex) firefox(x), FIREFOX(o), is_left(x), IS_LEFT(o))로 작성합니다.
- [x] indent(인덴트, 들여쓰기) depth를 3이 넘지 않도록 구현한다. 2까지만 허용한다.
  - [x] ex) while문 안에 if문이 있으면 들여쓰기는 2이다.
  - [x] 힌트: indent(인덴트, 들여쓰기) depth를 줄이는 좋은 방법은 함수(또는 메서드)를 분리하면 된다.
- [x] 3항 연산자(조건문 ? 선택문1:선택문2)를 쓰지 않는다.
- [x] 함수(또는 메서드)가 한 가지 일만 하도록 최대한 작게 만들어라.
- [x] Jest를 이용하여 정리한 기능 목록이 정상적으로 작동하는지 테스트 코드로 확인한다.
  - [x] 테스트 도구 사용법이 익숙하지 않다면 아래 문서를 참고하여 학습한 후 테스트를 구현한다.
    - [x] Using Matchers
    - [x] Testing Asynchronous Code
    - [x] Jest로 파라미터화 테스트하기: test.each(), describe.each()
- [x] @woowacourse/mission-utils에서 제공하는 Random 및 Console API를 사용하여 구현해야 한다.
  - [x] Random 값 추출은 Random.pickNumberInRange()를 활용한다.
    - [x] ex) MissionUtils.Random.pickNumberInRange(0, 9); // 0에서 9까지의 정수 중 한 개의 정수 반환
  - [x] 사용자의 값을 입력 및 출력하려면 Console.readLineAsync()와 Console.print()를 활용한다.

Airbnb 자바스크립트 스타일 가이드
우아한테크코스 네이밍 컨벤션

좋은 에러 메시지 작성법

에러 메시지를 어떻게 쓰면 좋을지에 대해서 토스에서 발행한 글.
좋은 에러 메시지를 만드는 6가지 원칙

자바스크립트 변수 vs 상수

자바스크립트에서 변수는 let, var 키워드를, 상수는 const 키워드를 사용한다.
변수는 데이터를 담는 그릇을 의미하고, 상수는 변수 중에서도 변화하지 않는 값을 가지고 있는 변수를 의미한다.

변수 선언

메모리 위치를 참조

var 선언자

var 선언자로 변수 선언시 같은 자바스크립트 코드 안에서 동일한 변수명을 재사용하는 것이 가능하다.
따라서 매번 새로운 변수명을 만들어서 사용하지 않아도 된다는 장점이 있다.
하지만, 동일한 변수명으로 변수가 새로 선언되면 기존 코드에서 동일한 이름으로 사용되던 변수에 할당된 값이 사라지기 때문에 해당 변수를 참조하고 있던 프로그램에서 에러가 발생할 수 있다. 이러한 단점 때문에 변수 선언 시 var 보다는 let 사용을 추천한다.

let 선언자

let 선언자로 변수 선언시에는 동일한 변수명을 다시 사용하지 못한다.
var 보다 let 사용을 추천한다.

상수 선언

constant(상수). 변화하지 않는 변수다.

const 선언자

const 선언자를 사용하면 같은 변수명으로 재선언하지 못하고, 이미 선언된 변수의 값을 변경할 수 없다.
즉, 선언 시점에 할당한 값을 절대로 변경하지 않는 용도로 사용한다.

네이밍 컨벤션

네이밍 컨벤션이랑 변수명을 짓는 규칙이다. 크게 4가지 규칙이 있다.

let userName="";	//카멜 표기법
let user_name="";	//스네이크 표기법
let UserName="";	//파스칼 표기법
let strUserName="";	//헝가리언 표기법

카멜 표기법: 변수명이 두 단어 이상이면 두 번째 이후부터는 단어의 첫 번째 문자를 대문자로, 나머지는 모두 소문자로 작성하며 모든 단어를 붙여서 사용한다.
스네이크 표기법: 변수명을 모두 소문자로 작성하며 단어와 단어 사이에 언더스코어(_)를 사용해서 연결한다.
파스칼 표기법: 카멜 표기법과 유사하지만, 첫 번째 단어의 첫 문자도 대문자를 사용한다.
헝가리언 표기법: 소문자 변수 타입+단어(첫 문자는 대문자) 표기법을 사용한다.