우테코 프리코스 3 주차 후기 (+ 코드 리뷰 받은 느낀 점)

 

우테코 프리코스에 참여하고자하는 이유는 단 하나 

 

"주니어로써 좀 더 온전한 개발자가 되는 것" 을 위함이다

 

---

 

3주차의 시작

 

 

 

 

# 본격적인 시작 전  

 

  이제 벌써 3주차다 즉 이번주 차가 끝나면 내 우테코 프리코스 과정도 한 주 밖에 안남은 셈이다.

 

이전에는 수련회 나 어떤 행사에서 "이제 우리 볼시간이 xx 밖에없네요 참 아쉽죠? " 같은 멘트를 진행자가 날리면

 

대체로 나의 반응은 "ㅋ 집에 가고 싶다"  하는 반응이였는데

 

이번엔 누가 뭐라고 하지 않았음에도 벌써 아쉬움이 느껴진다. 

 

물론 아쉬움 느끼기전에 일단 남은 과정이나 똑바로 해야된다. 

 

 

#  공통 피드백 

 

()안의 내용은 내가 한 번 더 내용을 읽고 추린 내용이다 

 

README.md를 상세히 작성한다   

 

기능 목록을 재검토한다 (예외적인 상황도 정리한다)

 

기능 목록을 업데이트한다 

 

값을 하드 코딩하지 않는다 (상수를 만들고 이름을 부여해 변수의 역할을 드러내라 )

 

구현 순서도 코딩 컨벤션이다 (클래스의 경우 필드 , 생성자, 메서드 )

 

한 함수가 한 가지 기능만 담당하게 한다

 

함수가 한 가지 기능을 하는지 확인하는 기준을 세운다 (15 줄이상 넘기지 않기 같은 제약을 통한 의식적 연습)

 

JavaScript에서 객체를 만드는 다양한 방법을 이해하고 사용한다.

 

테스트를 작성하는 이유에 대해 본인의 경험을 토대로 정리해본다

 

처음부터 큰 단위의 테스트를 만들지 않는다  ex) 숫자입력하면 결과를 알려준다 (x) 일치하는 게없으면 낫싱을 출력한다(o)

 

 

 

몇몇가지는 피드백이 오기전에 알아서 이전 부터 해나간 것들도 꽤 있었음으로 혼자서 뿌듯함을 느끼기도 했다.

 

지난주차엔 테코톡과 git에 대한 강의 가있었는데  요번주엔  숫자야구 피드백 강의가 있었다(우왕)

 

저번주에도 그렇고 나는 이렇게 까지  피드백 자료나 자원을 풍성하게 주실거라곤 생각못했다

 

위에 볼드 처리 해놓은 굵은 글씨의 글 정도만 올거라고 생각했는데 

 

이게 왠걸 코치와의 수다 타임 이라는 소통 시간과 , 강의 및 다른 관련 영상자료 , 웹 문서 , 깃헙 디스커션 까지 

 

요번 기수부터 프리코스는 제출만해도 다 참여 가능하다고 하여 오히려 나는 자원 부분에 있어서 솔직히 기대치가 낮았다.

 

물론 이전 기수 에도 이렇게 계속했는지는 모르겠지만

 

어찌되었건 내가 알 수 있는건 내가 참여한 기수 뿐이고 확실한건 커뮤니티는 이전에는 없었던 자원이다. 

 

 

 

# 코드 리뷰를 받으며 느낀 점 (2 주차 미션)

 

이전 주차 글에 적었듯이

 

중간에  주요 목표가 아닌 코드 컨벤션 에러로 인해  객체지향과 static 키워드 쪽으로 공부방향이 빠져 버렸는데 

 

올리고 나서 보니 나 말고 static 이 붙어있는 코드를 많이 보지를 못했다.

 

java에서의 static 은 메모리 같은 것들을 다 상정해서 설계 해야되는 요소 인 듯 한데 그런 식 이면 일단 지난 주에 내가 전부 static 처리한 건 잘한 행동이 아니라 생각했다.

 

근데 그것은 java 이고 나는 javascript 이며 airbnb 에러를 기준으로 밖에서 쓰이냐 안쓰이냐에 초점을 맞춰서 static 키워드를 붙인거지만 다른 분들의 코드에 잘 보이질 않다보니

 

분명 스스로 판단해서 적용했음에도 불구하고 

 

... 설마....  잘못 판단했나??  싶은 생각이들어서 

 

1,2주 차에 용기를 내서 먼저 봐달라곤 못하겠다는 말을 전면 수정하고 용기내서 피어 리뷰를 요청했다.

 

지금 가고 있는 방향성에 대해서 피드백이 간절 하니까 부끄러움이고 뭐고 없고 스스로 잘못 피드백해서 공부하고 적용한 거면 지금이라도 얼른 고쳐야 된다는 생각에 용기가 절로났다

 

몰랐는데 depth 를 어긴 부분도 있었고 계속 내가 나 스스로 나의 코드를 보니 고치지 못한 부분들도 알려주셔서 깨달을 수 있었다.

 

게다가 다른 분들 코드중 좋은 코드를 발견했다며 아낌없이 공유해주시는 분 까지 있어 이게 선한 영향력이구나...

 

하면서 황송함까지 느꼈다. 

 

지난 주에도 그랬듯이  테스트코드가 중요하다고 생각했지만 정확히 그걸 쳐가면서 느낀것이 있듯이 

 

이 코드리뷰를 받는 것 또한  받으면서 확실히 느낀 게 있다. 

 

나는 이걸 처음 airbnb 컨벤션을 적용했을때 와 비슷한 기분을 느꼈는데 거기에 더해 

 

친절히 사유 까지 설명해주시며 사람이 직접 해주는 피드백이란...! 

 

그래서 다른 분들의 코드도 더욱 열심히 보게 된 것 같다. 

 

만약 아직 안해봤다면 꼭 신청해서 리뷰 받아보는 경험을 해봤으면 좋겠다고 생각한다. 

 

나는 다 지켰다고 생각했는데 아닌 부분도 있어서 참 스스로의 눈은 믿을게 못된다는걸 새삼 다시 한 번 느꼈다. 

 

한가지 아쉬운 건 원초 목적 이였던 static에 대한 피드백은 받지 못했다. 

 

 

 

 

 

# 3 주차 미션 목표 

  

 

 

3주차 미션에 대한 세부 내용: https://github.com/woowacourse-precourse/javascript-lotto

 

 

요번주의 메일 에 따른 목표는 저 번주 까지의 목표들에 더해

 

1. 클래스(객체)를 분리하는 연습
2. 도메인 로직에 대한 단위 테스트를 작성하는 연습

 

이였는데

 

처음으로 목표가 정확히 이해가안됬다.

 

도메인 로직과 객체를 분리한다는게 어떤 의미인지 감이 잡히지않았다.

 

내가 느끼기론 객체 를 분리한다 => 모듈화 한다 라는 의미라고 이해했는데 어찌해야될지 감이안잡혔고 

 

단위 테스트는 그렇다치고 도메인 로직이 뭔지 이해가 안갔다...

 

 

 

 

#  나의 시도&우여곡절 

 

여기서 부터는 미션을 진행하면서 겪은 우여곡절 과 나의 시도들에 대한 글이다. 

 

  1)  미쳐 깨닫지 못했던 실수라고 느꼈던 부분들에 대한 FIX   

 

     1-1)  eslint 

 

       이건 내가 느끼기에 꽤나 치명적인 깨닫지 못했던 실수였는데 eslint 가 지난 주차에 분명 적용했는데 어느순간 부터 안되고있었다는 사실이다 

 

나는 영락 없이 내가 문제없이 잘 치고있어서 그런줄로만알고있었다.

 

깨닫게 된 경위는 요번 주차 또한 컨벤션을 위해 eslint 를 적용하고 진행하고있다가 max-len 이라는 컨벤션 오류를 맞닥 뜨렸는데  

 

"어라...? 저번주에 이런거 나올법한 상황에서도 못봤는데" 하고 가보니 아니나 다를까 지난주 차에  해당 오류가 나야 될 부분에도 나지 않고 그냥 다 진행되고있었다. 

 

??? 

 

이유를 못찾을 거라고 생각했는데 진행하다가 찾았다..

 

eslintrc.js 에 답이있었다.

 

나의 prettier 는 기본적으로 문자열을 사용할때 double quote 를 사용하고 있는데

 

eslint 규칙은 single 만 쓰라는 에러 메세지가 자꾸 뜨는게 짜증나서

 

rule에 single quote를 추가했는데  그때 부터 eslint 가 적용이 안되는것을 깨달았다.

 

(참고로 double quote 와 single quote 가  의미하는건 "" 과 '' 를 말한다.)

 

아... 룰을 내가 새로 하나 쓰면 기존것에 추가가 되는 게 아니고 

 

HTTP 메서드 PUT 마냥 아예  덮어쓰는가 보구나...해서 

 

프리티어를 single quote로 바꿨다.

 

 

+ 번외 npm install

 

package.json을 건드릴 수 없다는 제약이있어서 지난 주차의 방법과 여러가지 방법으로 eslint를 사용하고있었는데 jest 테스트를 하다가 뭐가 안되서 npm install을 안했던가? 하고 install 을 하니 

 

내 사고의 흐름대로라면 package.json 에 안등록되어있는 eslint는 당연히 남아있고 나머지가 깔릴거라고 생각했는데

 

의외로 싹 다 package.json 대로 초기화가 되는걸 보고 놀랐다. (린트도 지워짐)

 

  1-2) static method 에 대한 재고 

    말 그대로 다시 한번 생각해보게 되었다. 컨벤션 에러 메세지 대로라면 단순히 인스턴트에 상속해서 쓰냐 안쓰냐에 따라서 static 선언의 분기가 나뉜다고 생각했는데 

 

지난주차에 나는 전부  정적필드에다가 넣어놓고 진행 했는데

 

물론 예시에 play()를 제외하고 아무것도 없었음으로 굳이 필요없다 판단해서 static으로 다 선언한것이지만 

 

게임마다 다른 인스턴스를 가질것이고 그렇게 생각하면 게임 진행들은 static 메서드로 선언하는게 맞다고 쳐도 

 

멤버변수를 사용하는것은 각각의 게임마다 들어갈테니까 static으로 선언하는게아니라 필드에 들어가야되는게 맞다고 생각했다.

 

또 사실 그게 air-bnb 컨벤션 오류의 원초의 내용이기도했다.  

 

그래서 static을 쓰긴 쓰되 그런 부분은 유의해서 써야겠다고 생각했다. 

 

 

  1-3) jest 

     지난주차에 급하게 jest를 사용 하면서 문서참조 보다 코드만 우선적으로 치면서 파악해나가는 과정 중 

 

matcher 중에 toEqual 이 깊은 비교를 하지 않는다고 생각했는데, 

 

그 이유는 하드코딩으로 [1,2,3] 과 [1,2,3] 이 같다고 했을때 기억상으론 deep equality 어쩌고 하는 메세지가 뜨면서 계속 실패를했기때문이였다. 

 

결국 json.stringify 메서드 를  사용하여 검증했는데 

 

왠걸 이번에 문서를 다시 읽어보니 toBe 는 === 와 같은 비교를 해서 안되는게 맞는데 문서에가서 보니 toEqual의 예제코드가 객체를 비교하고있었다.

 

그리하여 코드 쳐보니 아무문제없이 잘 작동... 

 

예상컨데 막바지에 급하게 테스트 코드 적다보니까 toBe 쳐놓고 toEqaul 쳤다고 착각했거나 아니면 뭔가... 내가인지못하는 뭔가가있었거나 하여간 실수를 한건 명백하다. 

 

 

 

 

 

 

2) 목표와 피드백 중심 진행 

 

지난 주차에 끝내면서 좀 아쉬움이 느껴졌다.

 

목표를 우선순위로 달리고 난 다음에 남는 시간에 static 이든 private 이든 캡슐화든 보고 적용 했으면 좋았을것을 

 

에러가 뜬 대로 순차적으로 궁금한대로 공부하면서 하다가 보니 구현이 늦어지고 주요 목표 였던 test를 제일 마지막에 급하게 했다.

 

근데 제일 많이 느낀 점이 많았던게 아이러니 하게 test 였다 

 

물론 그렇게 하는 것도 하나의 공부 방법이고 결과적으로는 조삼모사라고 생각하지만

 

지금처럼 기한과 목표가 정해진 학습에서 잘 하는 행위는 아니였다고 반성했다

 

그리하여 요번 주에는 지난 주와 이번 주의 주요 목표를 중심으로 공통 피드백과 내가 느낀것들을 종합해서 구현 우선으로 진행하고자 했다. 

 

 

  2-1)  클래스 분리 

   클래스의 분리는 함수의 분리보다 확실히 더 어렵게 느껴졌다.   

 

패턴을 적용해볼까? 하고 생각하다가 아는 패턴은 MVC 밖에없었고 그조차도 사실 제대로 해본건 이전에 node로 서버쪽을 구현하는걸 배울때 잠깐 해본것이 전부였는데 

 

이번에 적용하기엔 일단 VIEW 라고 불릴만한게 딱히 없었으며 그럼 MC패턴인가(?) 하고 혼자 생각하다가 중요한건 내가 생각해서 클래스를 분리를 해보는것이지 어떤 패턴에 맞게 완벽하게 구현하는것은 아니라는 생각이 들었다.

 

(*11.16 내용 추가

 

다른 분들의 코드와 피드백 자료등을 보니 나는 view라고함은 .... 자고로 html 파일 정돈 되야 view 라고 생각하고 콘솔은 그저 text 라고 생각했는데  인풋값을 받고 게임 이 진행되는 메세지 또한 view로 분리하는것이였다... )

 

그리하여 나는  Lotto 와 외부라이브러리를 쓰는 Utils 로 나누어 진행했고 

 

클래스는 각각의 로또 내의 기능에 알맞게 분리하는 시도를 했다.

 

예를들어  계산하는건  Calculaotr , 유효성 검사는 Validator 로 기능 별로 묶을려고했다. 

 

이렇게 분리 한 이유는 우테코 측에서 제공해준 지난주차 피드백 강의에서 

 

객체지향 프로그래밍이란 

 

기능을 가지고 있는 클래스를 인스턴스화 하고 

필요한 기능을 역할에 맞는 인스턴스가 수행하게 한다.

+각 결과를 종합한다. 

 

라는 말을 보고 로또라는 폴더에 기능을 가진 클래스들을 각각 만들어서 (로또) 계산자 , (로또) 검증자  와 같이 기능별로 나눌려고 시도해봤다. 

 

그리하여 4가지 클래스 가 생겼는데 각각 로또 클래스 , 계산기 클래스 , 유효성 검사 클래스 , 프린터 클래스 로 나누었으며, 

 

로또 클래스에서는 로또 번호의 생성을 맡아서 이것또한 generator 라는 생성자 클래스를 만들어서 분리할까 하다가 그랬다간 로또 라는 클래스의 필요가없어져서 그렇게는 하지않았다. 

 

 

한 가지 더 분리하면서 신경쓰려고 한 것은 

 

나의 경우에는 static 으로 만 생성하여 기능을 가진 객체로써만 분리하고 

 

리액트의 state, props 처럼 가장 최상위에 모든걸 이어붙이는 App.js 에서  state 관리하듯이 필드를 한번에 관리해야 결과를 종합하기도 유지보수하기도 편하지않을까? 하는 생각에 가능한 그런 식 으로 만들었는데 맞는지는 모르겠다. 

 

 

  2-2) 도메인 로직에 대한 이해 

 

     미션 목표에 대해서 위에서도 적었지만 도메인 로직에 따른 분리가 뭔지 이해가 안갔다. 

 

이해하기 쉽게 번역하여 재정리해서 적어놓으신 블로그를 발견하여 같이 첨부한다.

https://velog.io/@eddy_song/domain-logic

 

요약하자면 도메인 로직이란 의사결정을 하는 로직이며

서비스 로직은 외부 서비스를 변경시키는 로직이다.

 

단순 프론트 , 백 으로 나누어서 볼 수 있지 않을까 기대했는데 alert를 띄우는것도 서비스 로직이라고 하니 그런 시선으로 보면 명확한 관심사의 분리가 어려워서 

 

확실히 의사결정  이라는 기준으로 분리를 해야 그나마 생각하기 쉬운것같았다. 

 

이번 미션에서 도메인 로직에 해당하는것은 무엇일까 ? 생각해서 

 

크게는 두부분 validate와 calculate.

 

세부적으로는 

 

validate = > 유저의 인풋에 대한 검증을 통해 진행 가능한지 의사 결정 

calculate => 정해진 로또 매칭 규칙에 따라 등수 계산 결정 , 정해진 기준에 따른 수익률 계산 

 

이렇게 세가지 부분으로 생각하여 작성했는데 validate의 경우에는 전체가 해당한다고 생각해서 따로 도메인 로직 테스트 파일에는 중복되어 넣지않았고 계산 부분에서 도메인 로직에 해당한다고 생각하는것만 분리하여 작성했다. 

 

 

 

 

2-3) 함수 분리 

 

   지난 주 까지 내가 했던 함수의 분리라 함은 좀 뭉뜽그린 느낌이였다. 제대로 분리를 하지 않았다 

static 이랑 객체지향이 주요 목표가 아니였음에도 불구하고 그것을 고민 하다가 분리에는 많은 시간을 할애하지 못했다.

 

그런 부분에서 아쉬움을 느껴 이번엔 아주 작은 기능조차도 나눠보겠다는 마음 가짐으로. 

 

다시 잘게 잘게 쪼개는 시도를 했으며

 

확실히 함수 분리와 테스트코드 작성이 같은 목표에 나온 이유를 좀 알것같다는 생각을한것이 

 

이렇게 해놓으니까 테스트 작성이 훨씬 수월하기도 하고 그 전 보다 테스트 코드에서도 뭘 테스트 하는지 명확하게 보이는 느낌이였다. 

 

  2-4) 테스트 코드

   지난 주 차에 이어 테스트 코드를 작성하며 느낀 점이 있는데 지난 주에는 사실 급하게 작성하느라 (급하게 작성하면서도 많은 걸 느꼈지만)  못 느꼈던? 새로운 것들을 지난주 보단 더 생각하면서 작성하면서 느낄 수 있었다. 

 

일단 예외를 작성하다보니 내가 작성한 함수에 대한 이해가 깊어졌다. 

 

지난 주에는 분리 로써 온전히 자기혼자 작동하는 함수에 대한 이해였다면 이번 주에는 기능적으로 온전히 작동하는 함수에 대한 이해가 늘어났다고나 할까? 

 

전체 테스트는 통과하는데 일일이 유닛테스트를 해보니 내 생각대로 안돌아가는게 꽤 있어서 좀 놀랐다.

 

'이게 이렇게 작성했는데 통과하고있었네 ㅋㅋ;'  하는 것들도 꽤있었고 

 

 

 

  2-5) README 수정

 

     공통 피드백의 README.md를 상세히 작성한다    를 보고  이 번 주차부터

 

문서 수정 방향을 기존에 기능구현목록에 몇가지를 더해보려고 했다. 

 

이미 전주차에 한번 체크리스트를 넣어 기능 구현 목록을 좀 더 잘 정리해보고자 했으나 이번에는 그것 뿐만 아니라 아예 이 미션 전체의 구현 에 대한 사항들을 적어놔야겠다고 생각했다. 

 

마치 잘 정리되어있는 프로젝트 README 마냥 정리해보고 이 참에 습관을 들여야겠다고 생각했다.

 

그리하여 추가 된 것이 노드 버젼 정보 , 라이브러리,  부연설명  같은 것들이였다. 

 

개인적으로 블로그글 같은 경우에도 쓰면서 지금 폰트가 단순 안예쁜걸 떠나서 읽기 어딘가 지져분하다는 느낌을 받아 이번주부터 본고딕R로 바꿔서 쓰고있다.

 

벨로그는 안그런거같은데 티스토리 기본 서체 뭔가 별로... 뭐 하여간  이건 잠깐 딴이야기. 

 

 

 

3) ETC

 

  3-1) 비동기적 커밋 

      나는 여지껏 커밋을 동기적으로 작성하고있었다.  싱글 스레드 인 자바스크립트 마냥  하나 작업 끝내면 꼭 커밋을 날려야 다음 작업을 진행할 수 있었다.

 

이런 방식은 테스트나 코드 수정을 굉장히 번거롭거나 힘들게 만들고있었다.

 

동시에 이곳저곳 손대는 일은 있을수 없었으며 다른 파일을 수정하고싶으면 먼저 지금파일을 커밋해야된다는 강박같은것이 있었다.

 

굳이 예를 들자면  기능하나를 구현하면 꼭 docs에 들어가서 기능구현 목록에 하나만들었다는 의미로 [x] 를 일일이 치고 docs에서 나갈때는 꼭 커밋을 날려야 다음 작업으로 넘어가는 식이였는데 

 

이번 우테코에 참여하면서 add로 스테이징을 활용하기 시작하면서

 

그 전까진 무조건 애지간하면 git add . 로 전부다 스테이지에 올리고 시작했으나 이젠 내가 자원을 골라서 올리니까 뭔가 기계적으로 그렇게 했었지만

 

이제는 이런 방식이 유의미한가? 라는 생각이 점차 강해졌다.

 

리드미 는 리드미 대로 수정하되 나중에 좀 쌓였을때 한번에 수정하는편이 좀 더 변경사항을 확인하기도 편하게 변하고 좀 더 그 전 방식보다 더 의미있는 커밋이 되지않을까? 하는 생각이들어서 그다음부터 비동기적으로 커밋하기 시작했다.

 

특히 지난 주차의 경우에는 처음부터 이어지는 구현의 스토리 라인 대로 기능 목록을 작성하고 붙이면서 구현을 했다면 이번 주차 미션에서는 내가 작성한 기능 목록대로 기능부터 구현하되 클래스를 나눠서 생각해서 구현한 다음 나중에 한 번에 이어붙이는 형식으로 진행했기때문에

 

더욱 더 비동기적인 커밋이 필요했다.

 

지난 주 차 처럼 진행 하였다면 'fx' 카테고리의 커밋이 어마어마하게 쌓였을거라 예상한다. 

 

 

 

 

 

 

 

 

 

 

 

 

# 느낀점

나는 나대로

너무 흔한 이야기 이다 '나는 나대로' 

 

하지만 흔한것과 별개로 너무나도 어려운 이야기이기도하다.

 

중간에 주말에 비를 맞아 건강 관리가 수월치 못했는데 그래서 더 마음을 내려놓고 진행해서인지 

 

나는 나대로 라는 말대로 임할 수 있었다. 

 

원래 힘 빡주고 잘해야지하다가 불의든 어떤 실수로든 망하고나서야 그때부터 

 

외려 망했다고 생각하니 평정이 찾아와지는것과 같이 그렇게 약간의 평정이 돌아왔다

 

3주차를 진행하면서 본문에도 적었듯이 치명적인 실수도 많았다고 느꼈지만 모든 것이 다 성장의 발판이라고 진심으로 생각한다. 

 

요번주에는 지난주차까지와 다르게 크게 진행하면서  "와! 이거야! 내가 하고 싶었던 거라구" 하는 건 없었다.

 

하지만 그렇다고 해서 느낀 게 없다거나 재미가 없다거나 하지는 않았다

 

또한,

 

정말로 한 주 한 주 지나갈수록 

 

내가 많이 변해가는 걸 느끼며 뿌듯함과 , 보람참을 느꼈다. 

 

그래서 처음 시작할때 말했듯이 아쉽다는 말이 거짓이아니다 

 

이제 마지막주차를 남겨두고있다.  

 

마지막 코테를 넘어 본 과정까지 합류하고는 싶지만 내가 컨트롤 할 수 있는건  지금 현실 의 자신 뿐임을 늘 잊지않으려한다. 

 

시작이 내가 왜 우테코에 임하게 되었는지 의미 복기로 시작한다면 

 

마지막은 늘 우테코에 감사인사를 하며 마무리하고싶다.

 

요번주도 참 감사했습니다 

 

 

 

 

 

---

 

이전글 목록 

 

 

2주차 후기 : https://hello-coding-world.tistory.com/48

우테코 프리 코스 2주차 후기

 

1주차 후기 : https://hello-coding-world.tistory.com/45

우테코 프리 코스 1주차 후기