[JS][우테코] 프리코스 1주차 공통 피드백을 통한 KPT회고

글의 목표

1주차 공통 피드백을 통해 내가 한 프리코스 1주차의 코드를 되돌아보고 2주차를 어떻게 시작해야 할지 고민해볼 생각이다.

※ 해당 글은 우아한테크코스에서 올려준 1차 공통 피드백을 참고하여 작성되었습니다. 공통 피드백은 프리코스 참여자들에게 개별적으로 공유된 링크가 존재하며, 저는 해당 링크는 공유할 수 없고 공통 피드백을 확인하는 과정에서의 생각들을 해당 글에 정리해보았습니다.

※ 프리코스 1주차 문제를 알고 계신다는 가정하에 작성된 글입니다. 1주차 문제 요구사항 글이 재확인이 어려워서 따로 설명을 첨부하지 않았습니다.🥲

 

1주차 프리코스 과정에 대한 후기

우선, 1주차의 학습 목표가 개발 환경과 프로그래밍 언어에 익숙해지는 것이라고 되어있다. 나뿐만 아니라 많은 사람들이 아직 개발 환경이 낯설어했는지, 우테코에서 테코톡에 올라와있는 영상들을 첨부해주었다. 처음 1주차때는 테코콕의 영상들을 참고하고 싶은데 무엇을 봐야 하는지, 다 보기에는 버거워서 어떤 것을 봐야 하는 지 몰랐는데 어떤 영상을 봐야 Git을 숙지할 수 있는지, 피드백의 방법을 제안할 때도 테코톡 영상 링크를 첨부해주셔서 좋았다.

프로그래밍을 누군가가 피드백해주고 그 지침대로 진행해볼 수 있는 게 꽤나 많이 좋은 것 같다! 혼자 하면 방향을 잃고 막연함에 미루기 마련인데 방향을 잡아주는 자세한 피드백에 프리코스 신청을 하길 잘했다는 생각을 했다.

 

공통 피드백 확인

[요구 사항을 정확하게 준수한다.]

프로그래밍 요구 사항을 지킨다고 왔다갔다 하면서 확인은 했는데 아무래도 확신은 없다. 다른 분들이 하신 것을 보니 과제 진행 요구사항, 기능 요구 사항, 프로그래밍 요구사항을 리드미 투두에 모두 적으신 걸 보았다. 그렇게 하면 훨씬 잊어먹지 않고 꼼꼼하게 과제를 진행할 수 있을 것 같다. 이번에는 3가지 요구사항을 모두 반영한 리드미를 작성해야겠다.

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

이번 미션에서 사용한 Git의 명령어는 clone, git, commit, push이다. 현재는 이러한 명령어만 알아도 되지만, 미리 알아두어도 나쁠 것이 없으니 시간날 때 틈틈히 올려주신 영상을 참고해야겠다. 만약, 코드 구현의 시간이 부족하다면 "유용한 Git 명령어" 영상 먼저 확인해볼 생각이다.

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

package.json 파일만 있으면 node_modules 폴더를 생성할 수 있다. => 프로젝트 디렉터리에 package.json 파이링 존재한다면 Node.js의 패키지 관리 도구인 npm을 사용하여 패키지를 저장하는 node_modules 폴더를 생성할 수 있다.

• 명령어 : npm install

Git을 통해 node_modules 폴더를 관리할 필요가 없다. => Git 저장소에 node_modules 폴더를 포함해서 커밋할 필요가 없다.

이 말은 피드백에 적힌 ".gitignore에 대해서도 알아본다." 와도 연관이 있다. .gitignore에 입력된 파일들은 깃에 커밋하고 push할 때 포함되어 push되지 않는다. node_modules파일을 잘 보면 다른 파일들과 다르게 회색 처리 되어있다. 이는 gitignore에 포함되어있는 파일이라는 뜻이며 git에 올릴 때 포함되지 않는다. 

ignore되어있는 node_modules 폴더

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

프리코스는 혼자하지만 협업을 진행할 때는 package.json 파일에 변동이 있을수도 있다. 우선 node_modules에 내가 파일을 추가해서 업로드 하는 것이 아니라, package.json에 변경 사항을 적용하면 팀원들은 프로그래밍을 시작하기 전에 git pull명령어를 쳐서 변동된 코드를 가져오고 여기서 다시 npm install을 하여 node_modules에 없는 파일을 업데이트 할 수 있다.

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

커밋 메시지를 1주차에 작성할 때도 처음 작성해보든 커밋들이다보니 계속해서 고민이 생겼다. 어떻게 작성해야 될까, 어떻게 작성하는 게 다른 사람이 읽을때도 한눈에 들어오는 커밋이 될까 고민이 있었다. 이에 대한 좋은 링크를 공유해주셔서 확인할 수 있었다.

좋은 git 커밋 메시지를 작성하기 위한 7가지 약속 : https://meetup.nhncloud.com/posts/106

해당 게시글의 내용을 블로깅하고 커밋을 잘 작성해보도록 노력해야겠다.

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

다행히 1주차의 메시지에는 이슈와 풀 리퀘스트 번호를 포함하지 않았다. 몇 달전에 프로젝트 진행할 때, 개발 팀원들이 이슈 번호를 포함하여 커밋한 것을 본 적이 있다. 프로젝트에서는 필요한 작업이라고 생각했지만 요구사항에 없어서 따로 진행하지 않았다. 아무래도 프로젝트 작업에 익숙하신 분들은 습관적으로 포함할 수 있을 것이라고 생각한다.

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

해당 피드백을 보고 풀 리퀘스트를 닫은 분들이 있는 지 확인하고 왔다는 점..ㅎ

PR을 잘못했고 커밋을 수정하고 싶을 때 PR을 다시 만들고 싶어서 닫는 방법을 선택한 분들이 있을 것이라고 생각되고 충분히 이해된다. 내가 2주차에 닫는 선택을 하기 전에 공통 피드백으로 미리 알아서 다행이다. 

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

내가 가장 주의깊게 봐야하는 피드백 사항 중 하나이다. 디버깅 방법을 몰라서 오류가 나는 부분을 찾기 위해 계속해서 console.log() 를 사용하여 코드를 실행해보았다. 여기서 공감되는 점은 "비효율적이며 불필요한 코드가 남을 수 있다."이다. 실제로 코드를 다 작성한 후에 오류를 확인하기 위한 코드들을 삭제하는 작업을 한번 더 거쳤다. 이를 통해 확실히 비효율적인 작업임을 알았고, 디버거를 사용할 수 있다는 점을 알게 되었다. VSCode에서 디버깅하는 방법에 대한 영상을 참고하여 이번 주차 과제는 오류를 더 효율적인 방법으로 찾아봐야겠다!

오류를 찾는데 시간이 많이걸려서 요구사항에 적어둔 하나의 리스트를 삭제하게 되었었다 ㅠ 제출하는 것이 목표였기 때문에 그랬는데 아무래도 디버거를 활용하여 시간을 줄이면 하나의 구현이라도 더 해낼 수 있지 않을까 기대가 된다.

[이름을 통해 의도를 드러낸다.] + [축약하지 않는다.] + [의미 없는 주석을 달지 않는다.]

변수, 함수, 클래스 이름을 지을 때 연속된 숫자를 덧붙이거나 불용어(Info, Data, a, an ..etc)를 추가하는 방식은 적절하지 않고, 의도를 드러낼 수 있다면 이름이 길어져도 괜찮다고 언급해주셨다.

나는 사실 처음에 이름을 userInputCustomSeparator이라고 지었다가 마지막에 inputCustomSeparator와 같이 한 단어씩 축약했다.

코드가 길어졌다면, 코드의 양을 줄일 생각을 했어야 하는데 함수명과 변수명을 줄였던 것 같아서 많이 아쉽다.

그리고 좋은 방법은 클래스 명을 지었다면 클래스 명이 앞에 온 상태에서 메서드를 호출하기 때문에 메서드 이름을 짓기 쉽다는 것이다. 예를 들면 클래스 명을 userInputCustom으로 지어서 메서드 명을 separator로 사용한다면, 자연스럽게 userInputCustom.separator가 된다는 것이다. 이러한 표현법을 활용하여 2주차에는 클래스를 선언하고 메서드 명을 지어야겠다.

주석을 달지 않아도 될 정도로 변수, 함수의 이름에 의도가 잘 드러난다면 주석이 필요가 없다. 이름을 잘 지어보는 것을 중점적으로 프로그래밍 해야겠다.

[코드 포매팅을 사용한다.]

코드 포메팅과 구조화가 클린 코드를 위한 최소한의 요구 사항이라고 한다. VSCode의 자동 정렬 단축키는 Shift+Alt+F 인데 나는 이미 JS 코드 강의 초반에 Prettier라는 확장자를 알게 되어서 코드 포매팅을 잘 사용하고 있었던 것으로 생각된다.

Prettier 알아보기 : https://velog.io/@gangk_99/VS-Code-Prettier-%EC%84%A4%EC%A0%95%ED%95%98%EA%B8%B0

[VS Code] Prettier 설정하기

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

나의 아쉬운 부분이 여기서 드러난다.. 앞으로 더 많은 API를 알아가고 사용할 수 있도록 노력해야겠다는 걸 공통 피드백으로 확인사살했다. 함수를 구현하기 전에, JS에서 제공하고 있는 함수는 아닌지 확인해보고 구현해야겠다.

이는 지식을 쌓아가는 과정이니, 필요한 함수가 생각나면 GPT한테 설명해서 JS에서 사용할 수 있을법한 함수를 추천해줘 와 같은 방식으로 빠르게 함수를 배워가며 2주차를 마무리하는 게 목표이다.

[기타]

if, for, while문 사이의 공백, 공백 라인을 의미있게 사용하여 문맥을 분리하되, 과도한 공백은 의문이 발생할 수 있다는 점을 인지하여야 한다. 생각해보니 내 코드에도 과도하게 각 라인마다 공백이 들어갔다는 점이 생각나서 수정해야겠다.

마지막으로 스페이스와 탭 둘 중 하나만 사용하는 습관을 들이는 것이다.

 

중간 KPT 회고 

공통 피드백을 확인하고 나니 내가 어떠한 점을 모르고 비효율적이게 함수를 구현했는지, 어떤 점이 부족하고 어떻게 공부해나가야하는지에 대한 매뉴얼을 보고나니 막연했던 2주차의 시작이 어느정도 길이 보이는 것 같다. 

1주차때는 정말 알고있는 기본 지식이 적어서 요구사항을 최대한 적고 그 요구사항에 맞는 코딩을 하기 위해 필요한 함수나 코드 작성 방법을 어느정도 상상하고 구글에 검색하거나 GPT한테 "A기호와 B기호 사이에 C기호가 들어가야한다는 정규표현식을 알려줘"와 같이 질문하거나 "JS 문법에서 A와 같은 방식을 나타내려고 할 때 사용하는 메서드를 알려줘"와 같이 있을법한 메서드를 상상하여 답변받고 기억하고자 노력했다.

그렇게 주차별로 지식이 쌓여가면 4주차에는 기억나는 지식을 최대한 쌓아서 코드를 구현해낼 수 있지 않을까 하는 기대를 해본다.

현재 1주차에 내어준 과제에 대한 내용물을 다시볼수가 없어서 짧게나마 기억을 복기하여 말해보자면, 정말 간단한 방법으로 구현했다.

나에게는 내 손으로 짠 코드로 테스트를 통과하는 작은 목표였기 때문에 다양한 패턴을 사용하거나 효율적인 코딩을 생각해볼 겨를이 없었다.

그래서 예외 처리용 에러 메시지 출력 조건문은 모두 함수로 나누어 하나의 js 파일에 모두 담고 export하여 App.js에서 예외처리 상황마다 호출하였다. 

그리고 App.js에서는 함수를 세 개를 만들어서 각각 사용자가 커스텀 구분자를 만들어서 계산했을 때(userInputCustom), 사용자가 입력한 값에서 (기본 구분자 계산 포함) 숫자 배열만 추출하여 변수에 선언할 수 있는 함수 기능을 구현했다. (userInputNumber) 이름의 의미는 사용자가 입력한 값에서 숫자만 가져오는 기능이라는 의미이다.

그리고 덧셈 계산기이기 때문에 배열의 숫자들을 덧셈해주는 함수, (sumCaculator) 이렇게 3개로 만들어서 각각 함수 기능 내에 if 조건문을 만들어 예외문을 출력하도록 구성하였다. 

예외문을 출력하는 함수는 Error.js 파일을 따로 만들어서 한번에 모아두었다. 

이렇게 한 구현 방법이 정답인지는 모르지만, 우선 테스트가 잘 통과되었다는 것에 의의를 두었다!

Keep (유지하면 좋은 점)

 지속적으로 가져가면 좋은 것은 클린 코드를 위한 Prettier 사용과 요구사항 설계 방식이다. 구현을 위해 기능단위로 요구사항을 설계하는 과정과 고민하던 시간은 의미있게 사용을 했던 것 같고, 그 사고방식을 계속해서 가져가면 기능 구현의 요구사항에 다가가는 방법에 익숙해질 것 같다. 처음에 요구사항을 작성할 때 이렇게 작성하는 게 맞는 지 걱정이 많았는데 다른 사람들의 작성한 내용을 보니 유사하다고 느껴서 나의 생각대로 유지해보아도 좋을 것 같다.

 

Problem (고쳐야할 문제점)

 함수, 변수명을 지을때 축약하는 과정을 생략해야겠다. 코드를 줄이고 클린하게 보이기 위해서 라인을 줄이는 것이 아니라 급한대로 함수명을 고쳤는데 공통 피드백에서 축약하는 것은 좋지 않다는 것을 보았다. 아마 누군가 알려주지 않았다면 몰랐을 사실인데 빠르게 알게 된 것에 대해 다행으로 생각한다. 내가 알아보기 쉽게 함수명을 지어놓고 다른 사람들한테 보일때는 깔끔하기 위해 축약을 했다.. 모순이 있는 결정이었다. 

오류를 찾을 때 Console.print()를 하나하나 추가하여 에러를 해결하는 데 시간을 많이 쓴 점이다. 디버거에 대해 잘 몰랐고, 테스트 코드도 작성할 생각을 못했으니 아무래도 에러 잡는 데 시간을 많이 써서 내가 추가하고싶었던 요구사항 중 커스텀 구분자를 두 개 이상 만들 수 있는 요구사항이 있었는데 마지막에 구현 시간이 부족하여 해내지 못했다. 기본 요구사항은 아니었지만, 추가하고 싶은 사항이었는데 추가하지 못한 점이 아쉽다. 시간을 더 줄일 수 있게 효율적인 피드백을 적극 수용해야겠다.  

 

Try (Problem을 기반으로 보완하여 새로 시도해볼 점)

 VSCode 디버거 영상을 보고 디버거 과정을 적극적으로 활용할 예정이다.

또한 내가 알아볼 수 있는 의미의 함수명을 지었다면, 굳이 축약하려고 하지 않고 그대로 사용하고자 노력해야겠다. 

 

최종 Todo 정리

□ [영상 시청] "유용한 Git 명령어" 테코톡 영상보기 - 나머지 영상들은 2주차 우선순위를 달성한 이후 확인하기

□ [Blog] 좋은 git 커밋 메시지를 작성하기 위한 7가지 약속 게시글 블로깅하기

□ [영상 시청] "Debugging in Visual Studio" 영상보기

□ 2주차 기능 구현 시작하기