우테코: 프리코스 1주차 미션 복기 (feat. git 대소문자 구분 설정)

2주차가 곧 끝나가는 시점이지만.. 지금이라도 1주차 미션을 복기해보려고 한다.

나는 그간 React를 조금 한 것 말고는 바닐라 JS로 기능을 구현해본 적이 없다. 있다면 그나마, 학교 강의시간에 간단한 기능 구현정도만? (정말 간단한 기능들…)

그렇기에 처음 1주차를 시작할때는 정말.. 쉽지 않았다. 솔직히 좀 어려웠다. 그나마 프로젝트를 진행한다고 node나 git 등을 다뤄봐서 다행이지, 한번도 사용해보지 않았더라면 프로젝트 설정에서 막혔을 것이다.

그리고 처음 보는 것들이 많았어서 그거에 대한 궁금증 때문에 정작 기능구현은 그리 빨리 시작하지 못했다. 1주차를 하면서 정말 크게 느낀 것은 선택과 집중을 잘 해야 한다는 것이었다.
다른 것을 신경쓰다가 가장 중요한 기능 구현은 실패헀을 수도 있다..

다행이도.. 그간 코딩좀 타탁거렸던 실력으로.. 정말 많은 난관들이 있었지만.. 잘 해결해서 테스트 실행을 통과시킬 수 있었다.

1주차: 숫자 야구 Repository 스크린샷 2023-10-31 23 56 56

서론은 여기서 마치고 1주차 미션을 진행하면서 발생했었던 일들에 대해 작성해보고자 한다.

테스트 실패


아무리 이상하다 싶은 코드를 수정하고, chatGPT랑 Bard에게 물어봐도.. 테스트에 실패하는 원인을 찾을 수가 없었다. 이거 찾는게 진짜 굉장히 오래 걸렸다.. 근데, 이 원인은 나의 바보같은^^.. 행동으로 인해 발생한 것이었다.

  • pickUniqueNumbersInRange()의 달콤한 유혹

    나는 처음에 랜덤 숫자를 추출할때 pickUniqueNumbersInRange()를 사용하였다. pickUniqueNumbersInRange 사용 코드

    모든 기능 구현을 완료한 후, 로컬에서 테스트를 실행하니 모든 테스트가 실패했다. 무엇이 문제일지 한참 고민하다가, ApplicatioinTest.js에 작성된 코드를 하나 하나 잘 읽어보니 랜덤 숫자를 추출할때 pickNumberInRange()를 사용하고 있었다.
    설마..? 사용한 함수가 달라서 테스트가 실패하는 것은 아닐까..? 라는 생각에 pickNumberInRange()를 사용하도록 코드를 변경하니..
    테스트가 잘 실행되어 테스트에 성공했다..

    그렇다. 이 사항은 README 프로그래밍 요구사항에 적혀있었다. 리드미파일 프로그래밍 요구사항 … 꼭.. 요구사항은.. 진짜.. 꼼꼼히 살펴야 겠다고 몸소 느꼈다..
    이것때문에 몇시간을 버린거야 진짜…

  • error 출력문 문제

    이상하게 예외 테스트만 실행하면 아래 사진과 같은 에러가 계속 발생했다.

    예외 테스트 실패

    이 에러만 이틀?정도 계속 찾았던 것 같은데, 에러의 원인은 정말^^.. 허무했다.

    에러 원인 코드

    위 사진에서 어떤 코드가 에러를 발생시킨 것일까?
    두번째 else if문을 보면.. throw를 new Exception으로 던지고 있다. 여기서 Exception은 위에 내가 만들었던 것이다.
    그렇다. new Error가 아닌 new Exception으로 에러를 던지고 있기에 “[ERROR]”형식이 맞지 않다는 이유로 해당 테스트가 실패했던 것이다..
    new Exception은 처음 throw를 적용하면서 봤던 글에서 사용하던 방식인데, 이게 나의 발목을 잡을 줄이야.. 앞으로는 조심하도록 하자..

예기치 못한 오류로 인하여 실행에 실패하였습니다.


그렇다. 나는 일명 ‘예기치씨’라고 부른다. 위 문구는 이번 미션에서 날 환장하게 만든 문구이다.
왜 날 환장하게 만들었냐. local에서 test를 실행했을 때는 잘.. 예제 테스트 실행이 되었지만, 제출을 한 후에 페이지에서 에제 테스트를 실행하면 위 문구가 뜨면서 예제 테스트에 실패했다..
정말 해당 문제를 해결하느라 힘들었다..

  • new App() 코드문 삭제

    빌드가 실패된 첫번째 이유는 new App() 코드를 주석처리했기 때문이다.
    로컬에서 test를 할 때에는 해당 코드가 필요 없다. 그래서 주석처리를 해뒀었는데, 이로 인하여 우테코 페이지에서 예제 테스트를 실행했을 때 빌드가 실패한 것이다.
    절대.. 빼먹지 말고.. 작성하자..

  • 파일명 변경으로 이전 파일명이 적용

    빌드 실패의 두번째 이유는 파일명이 엉켜 import에 실패한 것이다.
    처음에 파일명이 InputNumber.js였다고 한다면, 리팩토링을 진행하면서 파일명을 inputNumber.js로 변경했다. 지금에서야 알게된 사실은 변경할 필요가 없었다..

    파일명이 변경되면서 App.js에 import 했던 경로의 파일명도 변경해줬다. 그리고 로컬에서 test를 실행했을 때 테스트에 성공했다. 그러나 빌드에서는 실패했다.

    로컬에서는 변경한 이름(inputNumber.js)을 이전 이름(InputNumber.js)과 동일하게 여겨 import를 진행하여 테스트가 통과됐던 것이었다. 이 사실을 알고 git status를 확인했을 때, 변경한 이름이 아닌 이전 이름(InputNumber.js)으로 변경사항 일어났다고 되어있었다.
    즉, 나는 파일명을 파스칼케이스에서 카멜케이스로 변경했지만 로컬에서는 파일명 변경이 이뤄지지 않았다고 판단한 것이다!!

    나: 파스칼 -> 카멜로 파일명 변경 (철자는 동일, 대소문자만 변경)
    나: App.js에도 import할때 파일 경로 카멜케이스로 작성한 이름으로 변경
    로컬: App.js에 inputNumber.js로 작성했네? inputNumber.js 파일 존재하네! ㅇㅋ inputNumber.js 파일 불러오겠음
    git: inputNumber.jsInputNumber.js랑 철자 동일한데? 난 대소문자 구분할 줄 몰랑. 그러니 파일명 변경된거 없음ㅇㅇ! ( InputNumber.js로 저장)
    => 결론, pull request에는 파일명 바뀐거 없음

    그러나 우테코 페이지에서는 pull request에 반영된 마지막 커밋을 가지고 빌드를 진행하는데, App.js에 import한 경로가 inputNumber.js로 작성되어져 있고 저장된 파일명은 InputNumber.js로 되어있으니, 해당 파일을 찾을 수 없다면서 빌드 실패(예기치씨 등장)가 된 것이다.

    진짜 최종 결론, git 글로벌 설정으로 대소문자를 구분하자

    • git 글로벌 대소문자 구분 설정

      git config core.ignorecase false
      단, 이미 push된 파일에는 해당 설정으로 꼬일 수 있다. 따라서 아래 방법을 사용하자.

    • 원하는 파일만 이름 변경

      git mv user.js User.js
      user.js에서 User.js로 변경됨

미션을 진행하면서 배운점


  • typeof Number('string')의 결과값

    플레이어에게 값을 입력 받을 때, 여러 예외처리를 해야 했다. 이때, 입력 받은 값은 무조건 문자열로 들어오게 되는데 이 입력받은 문자열을 숫자로 변환되는지 안되는지를 가지고 예외처리를 하려고 했다.
    그래서 '안녕하세요'를 입력받았을 때 해당 값을 숫자로 변경하면 NaN을 반환하기를 기대했다.
    그래서 확인하기 위해서 typeof Number('string')을 실행했더니 값이 NaN이 아니라 number로.. 나오는 것이다..?!
    이 결과가 도저히 이해가 안돼서 우리의 영원한 두번째 친구, Bard에게 물어봤다.

    bard의 답변

    음 그렇다! typeof Number(아무거나) 실행하면 Number()로 인해 무조건 number로 결과가 나오는 것이다.

    이런 결과를 이번 미션을 진행하면서 처음 알게 되었다.
    이 외에도 새로 알게된 사항은 글로 적어뒀다.

  • 좋은 깃 커밋 메세지
  • npm permission denined 에러
  • git reset -hard 경로 : 원하는 시점으로 되돌리기
  • throw를 통한 예외처리
  • 기명 함수표현식?

코드리뷰


1주차 미션이 종료되고 내가 작성한 코드를 다른 분들에게 리뷰를 받을 수 있는 기회가 생겼다! 그래서 용기를 내서 코드리뷰를 부탁드렸다.

코드리뷰를 처음 받아보는데, 이번에 느낀 것은 코드리뷰는 기회가 생긴다면 꼭 받아야한다! 였다. 내가 보지 못했던 부분들을 짚어주시고 더 좋게 보완할 수 있는 사항들을 알려주셨다.

코드리뷰 정리

  • 변수 네이밍컨벤션
    const를 사용한다고 무조건 상수 네이밍컨벤션이 아닌, lowerCamelCase를 사용하는 변수 네이밍켄벤션을 사용할 것

  • 메서드 안의 지역변수라면 대문자 스네이크케이스보다 카멜케이스를 사용하기

  • boolean형 변수들 이름은 is__형식을 주로 많이 사용

  • for문은 break나 return 사용이 아니라면 고차함수 (forEach / map / filter / reduce)를 사용하는 것을 추천

  • 매직넘버 사용하기
    의미 전달이 확실하기에 사용을 매우 추천

  • print를 할때 변수가 없다면 ``가 아닌 ‘’ 사용

  • 변경되지 않는 값이라면 변수로 만들어서 명시적으로 알릴 것

  • Set 자료구조를 이용하여 중복 제거하기

코드리뷰를 해주신 친절하신 분들 덕분에 정말 많이 배울 수 있었다..💜
처음 알게된 개념들도 많았고 내가 놓치고 있던 개념들도 다시 공부하게 되는 계기가 됐다.
실제로 2주차 미션을 진행하면서 리뷰 받았던 사항들을 거의 다 적용해봤다! 덕분에 코드가 한결 이해하기 쉬워진 것 같다.

마무리


1주차 프리코스 미션을 진행하면서 정말 많이 성장할 수 있었다. 비록 일주일이라는 길고도 짧은 시간이었지만 새로 알게된 내용들이 엄청나게 많았다. 그동안 내가 모르고 해왔던 나쁜 습관들도 잡을 수 있게 되었고, 새롭게 알게된 내용을 통해 코딩을 하는 것에 있어 많이 자신감을 얻을 수 있었다.

이번 1주차 미션을 진행하면서 느낀 것은 우테코에 최종 선발이 되면 너무너무 좋겠지만, 선발되지 않더라도 프리코스를 통해 배운점이 너무나도 많기 때문에 후회되지 않은 정말 뜻 깊은 시간이었다라고 생각할 내 미래의 나의 모습이 벌써부터 보였다.

그리고 우테코에서 왜 코딩테스트를 하기 전에 프리코스라는 기간을 두는지의 이유와, 이 프리코스가 단순히 선발을 위해서가 아닌 많은 사람들에게 성장의 기회를 주기 위한 것이라는 걸 몸소 느꼈다.
프리코스라는 성장의 기회를 준 우테코에게 정말 고맙다는 말을 전해드리고 싶다! (선발돼서 직접 말씀드릴 수 있게 되면 좋겠다ㅎ)

그럼 앞으로 남은 3주 (글 작성 현재 2주) 화이팅하자!

학습 참고자료
Git: 대소문자 구분 이슈
git 파일명 대소문자 변경했을 때 제대로 인식하지 못하는 문제

Comments