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

 

 

모든 우테코 프리코스 후기의 시작은 항상

 

내가 우테코 프리코스를 임하는 마음가짐에 대해 복기 하며 시작 하려고 한다.

 

 나에게 있어서는 당연한 사실 이지만 

 

나는 당연한 말을 생략하는 것을 별로 안 좋아한다.

 

우테코 프리코스에 임하는 큰 마음가짐은 단 한가지

 

"주니어로써 온전한 개발자가 되는 것" 을 위한 성장을 위함임 을 잊지 않는 것 이다. 

 

 

 

 

---

 

 

 

 

 

 

 

2주차 시작!

 

 

# 본격적인 시작 전 

 

이제 막 두번째이지만  본격적인 시작 전의 나의 패턴은 앞으로도 대체로 똑같을 것 이다. 

 

메일과 주어진 자료 및 요구사항 들을 여러번 읽어보고 기능구현 목록을 자체적으로 한번 작성 해 본다. 

 

특히나 2주차에는 첫주차와 달리 공통 피드백 자료가 메일을 통해 구글 docs링크로 전달 되었고

 

공통 피드백과 함께 1주차의 내용이 어렵다고 느끼는 사람들을 위한 추가 학습 자료 들이 주어졌는데 

 

이 자료들 또 한 가능한 첫날 여러 번 보고 혹시 몰랐던 부분이 있다면 따로 정리해보려고 했다.

 

추가학습 자료에는 우테코 본 과정 레벨 1 코스에 있는 강의와 테코톡 영상 링크가

 

포함되어있어서 우테코 본과정은 어떤지 에 대한  약간의 궁금증 해소와 교육 문화 같은 것들도  확인할 수 있었다. 

 

 

* 참고로 테코톡 이라함은 우테코 크루 들이 관심있는 내용을 스스로 공부하고 공유하는 문화라고 한다 

 

 

 

테코톡의 경우 기술 블로그랑 맥은 일맥 상통한 것 같다고 생각했다. 

 

하지만 말로 표현하는것 과 글로 표현하는 방식의 차이나

 

혼자 보는 일기 쓰는거랑 보이는 글을 쓰는것의 차이 같은 

 

일상의 대화 와 사람들 앞에서의 발표에서 오는 차이가 분명히 있을 것이고

 

능동적인 공부의 연장이자 우테코에서 강조하는 소프트 스킬 역량 강화의 연장 선상이겠구나 싶어 좋은 문화라고 생각했다. 

 

 

 

 

 

 

# 공통 피드백 사항 

 

공통 피드백 사항은 이러하다 () 안의 내용은 부차적으로 스스로 알아보기 쉽게 간략히  적은 것 이며

 

연관된다 싶은 내용은 & 으로 연결 시켜놓았다.  

 

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

 

커밋 메시지를 의미 있게 작성한다 (작업을 이해할 수 있도록)

 

git을 통해 관리할 자원에 대해서도 고려한다 (노드 모듈)

 

JavaScript에서 제공하는 API를 적극 활용한다 (메서드)

 

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

 

이름을 통해 의도를 드러낸다 & 축약하지 않는다 (명시적)

 

공백도 (if,for,while문) 코딩 컨벤션이다 & 공백 라인을 의미 있게 사용한다 & space와 tab을 혼용하지 않는다

 

linter와 Code Formatter의 기능을 활용한다 & EOL(End Of Line)     (프리티어에 EOL : auto 옵션이 있다)

 

불필요한 console.log를 남기지 않는다 & 의미 없는 주석을 달지 않는다

 

 

 

 

공통 피드백을 적용하기 전에

 

한 가지 걸리 는게 있었는데

 

오롳이 내 힘으로만 한다면

 

공통 피드백을 보고 자체적으로 피드백을 해야함으로 내 이해력 부족이나 오해로 인해 

 

잘못 이해한게 있다면 그대로 넘어가게 되기 때문에 

 

위의 피드백 대로 eslint 와 prettier 의 사용은 필수적이라 느꼈다.(자신을 너무 맹신하지말 것)

 

 

 

 

 

 

# 2주차 미션

 

2주차의 총체적인 목표는 보내주신 메일에 따르면

 

" 1주 차에서 학습한 것에 더해 함수를 분리하고, 각 함수별로 테스트를 작성하는 것에 익숙해지는 것" 이였으며 

 

'함수별 테스트 작성' 부분에서 지난주차 처럼 또 잠깐 설렘을 느낄 수 있었다.

 

매 글 마다 해보고 싶었다고 떠들어서 이상하게 보일 지 모르겠는데

 

내 깃헙이나 어떤 발자취를 보면 기업과제 같은것들을 해보면서 정말 해보고 싶었고 필요하다고 느꼈던 부분이다. 

 

단지 설렘 속에는 역시나 해보지 않은것에 대한 막연한 두려움 또한 있었다. 

 

다행히 분리 연습이나 코드 컨벤션 같은건 1주차에 미리 찾아보고 조금 적용해보며 연습한것이 있어 좀 더 수월한 연습이 될 것 으로 생각되었다.  

 

 

* 미션 설명까지 전부 적을려고 하다가 완전히 우테코 프리코스 미션 전체 복붙 소개글이 되어버릴꺼 같아서 

 

기타 자세한 미션 내용은 저장소 링크로 대체한다 (https://github.com/woowacourse-precourse/javascript-baseball)

 

 

 

 

 

 

# 미션 돌입

 

여기서 부턴 미션의 진행 동안 겪은 우여곡절과 과정별 학습 방법에 대한 글이다. 

 

기본적으로 유의하려고 한 부분은 메일 내용 과 크게 다르지 않지만 정리 하자면

 

 지난주차에 시도했던 방법들의 계속된 적용과 유지보수 , 피드백 적용  그리고 이번주차 부터 가능한 

 

깃헙 디스커션 이라는 커뮤니티 자원 활용  과 이번주차 미션에 새로 주어진 함수 분리 ,  테스트 코드 작성 이 주요 목표이다.

 

 

 

1) 본격 적인 컨벤션 적용 

 

  1-1) 자바스크립트 컨벤션 

 

    저번에 내가 적용했던건 본격적인 컨벤션은 아니였다.

 

주로 클린코드의 '명시적으로 작성 '하라는 한가지 원칙의 집중적인 적용이였고

 

기타 컨벤션의 경우는 그냥 미션에는 따로 명시되어있지 않던 요구사항을 

 

혼자 찾아보고 몇 가지 테스트를 해본것에 불과했다면

 

이번 미션의 프로그래밍적 요구 사항에는  명시적으로 자바스크립트 코드 컨벤션 을 지킬것을 요구하고있었다. 

 

요번 미션에 적용해야될 코드 컨벤션은 Airbnb의 코드 스타일이였다( https://github.com/ParkSB/javascript-style-guide)

 

시간 분배 문제도 있을 것 같아서 정독하기 보단 한번 간독하고 다시 적용하면서 다시 읽을 생각이였는데

 

간독 하면서 느낀것은 생각보다 컨벤션에 문법적인 요소가 되게 많았다.

 

나는 컨벤션이라고 함은 저번 주차에 찾아봤듯이 카멜케이스 같은 것 이나 단순히 상수는 대문자 스네이크 정도나 생각했는데 그런 의미에서 굉장히 의외였다. 

 

예를 들자면 이런 항목들이였다. 

 

 hasOwnProperty, propertyIsEnumerable, isPrototypeOf와 같은 Object.prototype 메소드를 직접 호출하지 마세요.

왜? 이러한 메소드들은 객체의 속성에 의해 가려질 수 있습니다. - { hasOwnProperty: false } - 또는,

객체가 null 객체(Object.create(null))일 수도 있습니다.

// bad console.log(object.hasOwnProperty(key));

// good console.log(Object.prototype.hasOwnProperty.call(object, key));

// best const has = Object.prototype.hasOwnProperty;  // 모듈스코프에서 한 번 캐시하세요.

 

보다보니 양이 꽤 많았다. 

 

이걸 내가 직접 보고 자가 적용하기란 1주일 내론 불가능 하겠다 싶어 

 

 airbnb 정도의 코드 컨벤션이라면 eslint 에 추가 할 수 있지않을까? 하는 생각이 들어 찾아 보니

 

https://www.npmjs.com/package/eslint-config-airbnb-base

eslint-config-airbnb-base

 

 

어렵지 않게 찾을 수 있었다. 

 

 

 

 

 

다만 문제는 프로그래밍 요구사항의 

 

 

package.json 을 변경할 수 없고 

 

 

 

 

부분 이였는데  npm install 할때 --no-save  를 하면 dependencies에 등록이 되지않아 해당 방법으로 해결하였다.

 

 

 

참고한글 : 

https://xtring-dev.tistory.com/11

[NPM] npm install 할 때 --save 옵션을 함께 입력하는 이유? 하지만 이제는 사용하지 않아도 되는 이유.

 

 

 

 

 

+ 컨벤션 번외 ) 이런 규칙이 있다고?? 웃기고 있네 

 

 

 

 

airbnb 옵션을 적용하고 코드를 작성하다보면 스스로 위와 같은 말을 할 때가 있었다. 

 

예를들자면, 

 

for(let i=0; i<array.length; i++){}

다음과 같이 일반적인 for문을 돌리는데 에러가떴다.

 

 

no-plus plus?  뭔가 이름이 장난 같이 느껴졌다. 그래서 더 그랬는지도 모르겠다 

 

혼자 중얼거렸다 " airbnb 규칙에 이런게 있었다고? 없기만 해봐라 " 

 

 

 

https://github.com/ParkSB/javascript-style-guide#variables--unary-increment-decrement

 

 

ㅋㅋ...있네..

 

 

생각해보면 지난주차에 본 스타워즈 요다 규칙 같은것도 있는 마당에 

 

노 호빗 같은 비유의 규칙이 있다고 해도 이상할 건 없긴했다.

 

 

 

 

 

 

 

 

 

 

 

  1-2) 깃 컨벤션 

     1주차에 사용하려고 했던 깃 컨벤션과  한 가지만 제외하고 형태는 거의 동일 했다. 

 

• CHORE: 빌드 업무 수정, 패키지 매니저 수정

 

이 부분 만 빼고.

 

 요번 주차에서는 eslintrc 파일을 .gitignore 를 통해 뺄때 한번 사용한것 같다. 

 

 

 

  2) 커뮤니티 활용 

 

1주차 의 글에서도 적었듯이 전체 우테코 과정에 임하면서 개인적으로 가장 많이 신경쓰려 한 부분중 하나 이기도 하며 

 

우테코 측에서  공유하고 발전하는 경험을 하게 해주기 위해 

 

요번 기수에서부터 생긴 자원으로 슬랙과 깃헙 디스커션을 활용할수 있었다. 

 

 

    2-1) 슬랙 활용 

 

     사실 슬랙은 1주차에도 사용 가능했으며 따로 적진 않았으나 개인적으로 공지확인과 프론트엔드, 다른 참여자들의 회고를 볼 수 있는 주간 회고록 3개의 채널에 참가했다. 

 

프론트엔드나 공지확인 채널은 이슈를 확인할 요량으로만 들어가고 주간회고록 채널만 능동적으로 참여하고 있었다.

 

참고로 채널은 다른 동기들이 자유롭게 만들어서 사용할 수 있으며 주간 회고록 채널 또한 마침 있을거 같아 찾던 차에

 

이미 다른 누군가가 만들어놓으셔서 참가한 채널이다 

 

나는 다른 사람들의 글을 읽는것 도 좋아하기도 하고 보여지는 글을 쓰는 경험이 너무 오래되서 그런 측면에서도 내 글도 공유해보고 싶어서 들어가봤는데 회고에 관심 이 있는 분들의 글이라 그런지 볼만한 글이 많았던 것 같다.

 

 

 

 

 

    2-2) 깃 헙 디스커션 활용 

       OT에서 부터 토론의 장이 될것이라는 말은 들었는데  깃헙 이슈랑 뭐가 다른건지 잘 모르겠기도 했다

 

깃헙 디스커션이라는 기능자체를 처음 봐서 이에 대한 개론적인 이해가 필요할까? 했는데 너무 직관적이여서 사실 필요없다 판단했다.

 

비유하자면 좀 더 커뮤니티 스러워진 깃헙 이슈의 확장 판 같은 느낌이다.

 

그리고 중요한 피어리뷰 같은것들도 이루어질 수 있는 소통의 장인듯 했다.

 

자원을 최대한 활용해야되지만 가장 좋은 방법은 내가 먼저 다가가는것 이기 때문에 내꺼 해주세요 보단

 

잠깐이라도 남의 코드를 읽어보는 시간을 가졌다. 

 

참고로 2-1) 에서 적었던 참여하고 있던 주간 회고록 채널도 코치 님들이 좋게 봐주셔서 디스커션 쪽으로 합류가 되어 자연히  보기만 하는것이 아닌 참여하는 형태로 디스커션을 활용할 수 있는 계기가 되기도 했다. 

 

깃헙 디스커션 이 궁금한 분들을 위해 

 

프리코스 깃헙 디스커션 주소 : https://github.com/orgs/woowacourse-precourse/discussions

GitHub: Let’s build from here

 

 

3) 클래스 형 코드 작성 (OOP)

 

  2주차 부터는 클래스형식으로 코드를 작성해야했다. 

 

문제는 개념은 아는데  클래스형으로 코드를 작성 해 본적이없었다.

 

내가 리액트를 처음 했을때도 이미 함수형이 표준이였고 클래스는 어렵기만 한 개념이라고 생각했는데 요번에 다루게 되었다. 

 

  3-1) static method  

 

    클래스 형으로 코드를 작성한다고 해서 크게 막힐거라고 생각하진 않았었는데 

 

시작 부터 적용한 airbnb 코드 컨벤션 규칙에 의해 함수 부분에 에러를 띄우면서 어려움이 생겼는데 이 덕분에 자연히 OOP(객체지향 프로그래밍)과  static method 에 대해서 전보다 잘 알게 되었다.

 

클래스 안에서 함수를 선언할 때는 function 예약어 없이 선언하게 되는데 이 함수가 밖에서 쓰이느냐 아니냐에 따라 static 설정을 할 수 있었다. 

 

처음엔 개념은 알아도 뭔차인지 정확히 인지는 못하고있었지만 고민하다가 하루가 다 갈것같아.

 

너무 생각하지말고 만들어보자 하고 만들다가 

 

 이런저런 코드를 치면서 constructor 값에 접근 못하는 것이나, 메서드를 쓸때, 인스턴스 에 프로토타입 체인화  되지않는 점을 알게되면서 차이를 인지하게되었다.

 

static 을 공부함으로써 자연히 private/ encapsulation(캡슐화) 도 다시 한번 간략히 보게 되어서 간략하게나마 어떤 것을 static 으로 선언하고 어떤것을 그냥 선언해서 프로토타입 체인으로 상속시킬것인가 고민했는데 사실 상 이번건 

 

app.play() 만 되면 되고 나머지 로직은 다 인스턴스에 prototype 체인화 될 필요가없다고 느꼈음으로   

 

play()를 제외한 나머지 전부를 static으로 리팩토링 했지만 

 

객체지향의 핵심인 private 을 제대로 구현했다고는 할 수 없는 상태였다.

 

private 같은 경우 javaScript 에서 2019 Ecma 에서 부터 # 을 붙이면 private 이 된다곤 했으나 불완전했다.

 

 

 

https://developer.mozilla.org/ko/docs/Web/JavaScript/Reference/Classes/Private_class_fields

Private class fields - JavaScript | MDN

 

이래서 클로저를 쓰는 거구나. 공부했던 내용이지만 치면서 재접근 된건 또 신기한 경험이였다.

 

 

 

 

 

  3-2) 모듈화 와 캡슐화  

 

     공부하다가 보니 모듈화와 캡슐화의 차이 가 무엇인지 정확히 알기 힘들었다. 

 

덕분에   모듈화는 묶고 분리 / 캡슐화는 묶고 숨기기 라는 차이점을 인지하게 되기도한것 같다.

 

나는 모듈화를하면 분리가 되니까 알아서 캡슐화가 된다고 생각 했는데 

 

모듈을 구현하면 캡슐화의 묶기 가 구현되지만 숨기기가  온전히 구현되는건 아니라고 생각하여. 

 

모듈화를 구현한다는것과 캡슐화를 구현하는건 별개라는걸 공부 할 수 있었다. 

 

 

 

  3-3) static field

 

    맞는 표현인지 모르겠으나 static 메서드 전반에 대한 이해와 static 끼리는 field를 공유한다는 사실도 알게되었다 

 

무슨 말이냐하면 static 함수끼리는 static 함수 내에서 this.로 불러올수 있다는 말이였다.

 

하지만 일관되게 보이는것이 좋을것같아 this 말고 App.STATICMETHOD로 통일했다 

 

  static init() {
    this.userNumber = 0;
    this.gameEndStatus = false;
    this.gameOptionValue = 0;
    this.isValidUserNumber = false;
  }
  
  static test(){
  console.log(this) //   this.userNumber = 0; this.gameEndStatus = false;this.gameOptionValue = 0;    this.isValidUserNumber = false;

   
    
  }

 

 

 

https://developer.mozilla.org/ko/docs/Web/JavaScript/Reference/Classes/static#%EC%8B%9C%EB%8F%84%ED%95%B4%EB%B3%B4%EA%B8%B0

static - JavaScript | MDN

 

 

찾다보니 클래스 정적 초기 화 블록 이라는 것도 알게 되었는데  브라우저 호환성에서 노드 16버젼 이상부터 되고(우테코 과제 기능 구현이 14버젼에서 돌아 가야함) 사파리는 지원하지않아서 다행히(?) 읽어만 보고 넘겼다. 

 

https://developer.mozilla.org/ko/docs/Web/JavaScript/Reference/Classes/Class_static_initialization_blocks#%EA%B0%99%EC%9D%B4_%EB%B3%B4%EA%B8%B0

Class static initialization blocks - JavaScript | MDN

 

 

 

요약하자면 이번 객체지향에 관한 학습은

 

eslint에 의한 static 에러 발생 ->  static 에대한 개론적 파악 ->  private/ 캡슐화 개념에 대한 복기 -> 모듈화 캡슐화의 차이점에 대한 궁금증 -> 학습및 코드적용  ->  블로그 글 작성을 위한 mdn 문서 참조 순서로 학습했다. 

 

 

아마 eslint 를 통해 airbnb컨벤션을  적용하지 않았으면 이렇게 까지 굳이 보지도않고 좋을대로 구현 했을것이다. 

 

프로젝트를 제외하곤 eslint 를 개인프로젝트에 적용해서 사용한적이없어서  적극적으로 활용한적이 거의 없는데. 

 

앞으론 적극활용해야겠다는 생각이들었다. 

 

 

 

 

 

 

 

4) 라이브러리 사용 

 

라이브러리의 경우에는 우테코에서 제공하는 

https://github.com/woowacourse-projects/javascript-mission-utils#mission-utils 

GitHub - woowacourse-projects/javascript-mission-utils: Utility library for mission

가 있었는데

 

다만 이에 따른 우여곡절이 두가지 정도있었다.

 

   4-1)  ESmodules vs CommonJs 

 

    사실 별로 이건 큰 우여곡절은 아니였다 왜냐면 이전에 프로젝트를 하면서 한번 겪어본 문제였기 때문에. 

 

요약하자면 import 문법으로 가져오느냐 require 문으로 가져오냐 의 차이인데 

 

이전에 프로젝트를 하면서 별생각없이 서버쪽 node 는 require로 작업 하다가 음... 근데 둘다 자바스크립트인데 

 

뭔차이지? 싶어서 찾아보기도했고 require 문을 import 로 바꾸면서 고생한 이력도 있었기에 바로 생각이났다.

 

https://github.com/MAGHC/2022TIL/blob/master/Project%EA%B4%80%EB%A0%A8/MasterPokemon%ED%94%84%EB%A1%9C%EC%A0%9D%ED%8A%B8.md#node-js-require-vs-import

 

 

단지 import 문을 사용하려면 package.json 에 모듈 타입을 넣어줘야 되는데 위의 eslint 문제처럼 프로그래밍 요구사항에 package.json 을 건들지 말라는 부분을 건드리게 됨으로 

 

그냥 require 문으로 진행했다.

 

  4-2)  Console.readLine 

 

    이문제로 약 하루를 소요했다. 

 

 

Console.readLine 의 기능은 이러하다 

 

 

 

근데... 동작을 안했다 콘솔에 뜨는데 입력이 안됬다.

 

몇 가지 생각을 해봤다.

 

1. 음... 클래스를 안써봐서 그런데 혹시  this 바인딩 이슈인가?  

 

2. 사실 입력하라는것이  answer를 내가 목데이터로 만들어서 전달하라는 의미인건가 ? 

 

3. 내 환경이 특별하게 이상한건가? 

 

여러번 생각하고 코드를 쳐보고  README를 본결과 1,2는 아니라는 결론에 도달했다.

 

그리하여 3. 의 실험을 위해 코드 샌드박스 에 가서 되나 안되나 실험해보기로했다. 

 

...찾을수없다고? (참고로 설치했음)

흠 내 로컬에서의 문제점과는 다르지만

 

이쯤 되면 내가 잘못한 건 아니지 않을까?  생각하고 이슈에 들어가봤는데 

 

비어있었다

 

 

ㄴ...눌러야되나??.gif

 

손이 떨렸다. 근데 문제가 있었다면 이미 과제가 나온지 하루가 지났는데 이슈가 없을리가없었다

 

그리고 상식적으로 과제용으로 구현한 라이브러리 일텐데 이슈를 본다는것도 이상했겠지만 그만큼 생각나는게없었다

 

커뮤니티 를 봐야되나 별에별 생각을 다하다가 

 

고통스럽지만 일단 처음으로 돌아갔다. 

 

코드 샌드박스 말고 다른 뭔가가 문제가 있지않을까? 나 같은 문제를 가진 사람이없었을까 ?

 

내가 메서드를 잘못 이해하고 있나? 등등의 문제를 생각하며 여러번 순환 반복 했다.

 

그러다가 문득 생각난것이 

 

나는 코드 실행을 code runner 라는 extension 을 통해서 실행하고있었다.

 

여지껏 설마 그게 문제일 거라곤  생각하지 않았지만(그게 문제였다)

 

이녀석

 

내 실행환경은 이녀석을 의미하는 것이였음으로 얘로 인한 문제가아닐까?? 하고 생각해서 얘로 키지말고

 

서버 키듯이 

 

node App.js 명령으로 앱을 실행하니 

 

너무 기뻐서 연타

 

실행이 됬다. 

 

그렇게 이 문제도 해결.

 

해결 하고 너무 기뻐서 임시로 선언한 변수 나 실행함수를 안지우고 커밋하는 실수 까지 했다. 

 

 

여담으로 이걸 블로그 글에 올려야되나 말아야되나 고민도 좀 많았다.

 

이 문제를 붙잡고 반나절에서 하루를 고민했다는 사실이 해결하고 나선 한편으론 스스로가 멍청하다고 느껴졌는데

 

그런  멍청하다고 느낀 부분을 드러내야되나 하는 고민 이였다.

 

하지만 블로그 글을 적는것은 나에게 있어 능동적인 공부이자 기록임을 상기하며 그냥 적기로했다. 

 

 

 

 

 

 

 

 

 

 

 

 

5) 테스트 코드 작성 

 

 

테스트 코드 작성의 경우 제대로된 작성을 해본적은 한 번도 없었다 

 

그렇기에 나에게있어 테스트 코드 작성은 모든것이 다 엄청난 도전이였으며 굉장히 많은걸 느꼈다. 

 

나는 테스트 코드를 작성하는 목표가 여지껏 잘 돌아가는지 확인 용도 정도로만 생각하고 있었는데 

 

기능 테스트 코드 작성에 용의하게 함수를 변경 하다보니 

 

자연히 함수 자체만으로도 다른곳에 의존하지 않고 기능이 온전하게 돌아가게끔 만들려 노력하고 있는 자신을 느낄 수 있었다.

 

그리하여 함수의 분리라는것이 단순히 겹치는 로직 하나로 합치기 나 길이 줄이기 가 아니라 온전한 그 자체로써 기능을 하는 분리 를 다시한번 생각해볼 수 있게되었으며

 

그렇게 하기위해 매개변수 값을 잘 설정하려고 하다보면 자연히 필요 없는 지역변수가 다 사라지기도 했다. 

 

기능을 만드는거랑 테스트 코드 가 잘 돌아가는 코드를 만드는거랑 또 다른차원임을 느낄 수 있는 시간이었으며, 

 

이를통해 기능 테스트에 용이하게 함수를 만는다는게 자연히 어느정도 확장성과 재사용성이 용이하게 함수를 바꾸는 일이기도 함을 느꼈다.(느낀거랑 별개로 스스로 잘 만들진 못함)

 

 

모든 함수가 어떤 값을 return 을 하면 좀 더 편했을거 같은데

 

함수가 게임 결과를 위의 미션 라이브러리의 print 를 사용 하는 방향으로 연결되어있어서  전체적으로 테스트하기 까다롭다고 느껴,

 

리턴값을 만들어놓고 주석 처리 해놓는 아쉬움이 남았는데 이게 일반적으로 도 작성하는 방식인지 잘모르겠다. 

 

물론 테스트 방법론에 따라 다르겠지만 적어도 내가 요번에 한 기능 테스트에 맞게 작성하려고 하면서는 이런 점들을 느꼈다. 

 

나중에 많이 쳐보고 하다보면 알아서 처음부터 테스트 돌아가게끔 만드는 경지가 될지는 모르겠다만 현재로썬 기능구현 하고 테스트 코드 작성의 순서는 한동안 변하지않을것 같다. (그래도 리턴값 이나 매개변수는 좀 더 생각하면서 구현할것 같다. )

 

 

한 가지 테스트 코드를 작성한 예를 들자면 나는 컴퓨터가 3자리의 랜덤한 겹치지 않는 숫자를 만드는 기능을  미션 라이브러리를 통해 멤버변수로 저장해서 사용하고있었는데 

 

문제는 테스트 코드를 작성하자니 이 알아서 생성된 3자리의 랜덤 넘버에 대한 제어를 할 수 없었다. 

 

 

class App{

this.computerNumberArray = App.generateComputerNumberArray();


compareNumber(userNumber){
this.computerNumberArray !== userNumber 
}

//알아보기 간략하게 적자면 이러하다

}

 

앱은 인스턴스를 생성해서 정상적으로 돌아가고 나 역시 실행하며 확인할때는 console.log() 로 컴퓨터의 랜덤값을 확인했지만 테스트를 하려면 그런 방식이 아니라 컴퓨터의 값을 직접 제어해야됬는데 나는 만든 함수 부터가 매개변수에 컴퓨터값은 들어가있지 않았다. 

 

물론 멤버변수는 여전히 있어야됬지만 함수 자체는 멤버변수에 전적으로 의존하고 있고 저상태론 컴퓨터 의 수가 제어가 불가능했기때문에 

 

compareNumber(userNumber, computerNumber){

computerNumber!==userNumber

}

 

같은 형태로 바꾸면 자연히 멤버변수는 그대로 사용하고 함수 자체도 자체적으로 의존없이 기능할수있는 새로운 기능으로 탈바꿈되었다는 느낌 이였다. 

 

위에서 적은 깨달음은 이런 과정들 에서 느낀점들을 축약했다. 

 

 

 

 

 5-1)  jest 

   요번 테스트 코드는 참고 예시들이 jest로 적혀있었음으로 jest로 작성하게 되었는데 대략 expect 에 toBe.. 등등의 matcher 와 비교해서 결과가 맞는지 보는것이 기본 테스트 코드 작성이라 파악했는데 

 

별 생각없이 처음엔

 

jest 가 알아서 비교하겠거니 하고  테스트코드 형태로 expect([1,2,3]).toEqual([1,2,3]) 으로 작성했다가 통과가 안되길래 아아... 제기랄

 

22.11.11 추가 내용)  막바지에 테스트코드 적는다고 정신이없어서 toBe랑 toEqual 이랑 헷갈린듯하다... 

 

 하고 고치는 일들이나 ,  원하는 옵션값을 찾아보고 적용하는 일들의 연속이여서 

 

처음이라 더욱 그런 시간들 이 많았기에 아쉬움도 느꼇던것 같다. 

 

 

 

 

문서는 아래 두 곳을 참고했다. 

 

https://mulder21c.github.io/jest/docs/en/next/using-matchers

Jest · 🃏 Delightful JavaScript Testing

 

https://jestjs.io/docs/expect

Expect · Jest

 

6) 기능구현 목록 작성 

 

이건 좀 뜬금없어 보일수도있겠다.

 

1주차에도 했는데 새삼 적는다는것이 

 

이젠 기능구현 목록은 당연히 구현하다보면 수정될 문서라는걸 알고있고 (적어도 내가 칠때는)

 

개괄적으로 적는것에 대해서 망설임도 없는편이다.

 

단지 1주차와 2주차는 과제의 생김새 부터 가 많이 달랐다. 

 

그 만큼 기능 구현 목록 문서도 변해야된다고 느꼈다. 

 

비유하자면 2주차가 하나의 프로그램이고 1주차의 문제들은 하나의 프로그램 안에 있는 기능들을 구현하는 느낌이랄까?

 

그래서 1주차는 기능구현목록의 세부기능 구현 목록이라는 느낌의 문서였다면

 

2주차는 1주차 보다 좀 더 스스로 설계하고 세세하게 잡아나가야 됬다.

 

기능구현 목록을 작성할때 말했듯이 굉장히 개괄적으로만 적었는데

 

만들다보니  저번엔 이 문서에 기대하지 않았던 리팩토링 효과를 느꼈는데

 

요번주차 엔  유지보수 를 위한  문서역할 도 함을 다시 한번 느꼈다. 

 

그래서 몇 번 기능구현목록을 전면 수정했지만 

 

테스트코드  작성 하면서 또 다시 본 기능구현목록은 정말 엉망진창이였다....ㅋㅋㅋ

 

다음주엔 1주차에서 2주차로 넘어오면서 느꼈듯이 좀 더 넓은 설계를 요구하지 않을까? 하는 예상을 해 본다. 

 

 

 

 

 

 

 

#  2주차 소감 

 

왜 내가 설계, 테스트코드 같은 걸 배우고 싶어했었는지 다시한번 떠올렸다.

 

 

이게 그냥 중요하다는것은 이미 머릿속으로 얼추 느끼고 있었지만 처음 진하게 느낀 건 

 

취업준비를 하면서 기업 과제로 구현한 앱을 나중에 시간이 지나서 원하던 사양으로 바꾸고 싶었는데 

 

뭘 어떤 방식으로 만든건지 코드를 보고 파악하기도 너무 힘들었고

 

문서 같은 걸 안남겨놓으니 내가 짠 코드 였음 에도 불구하고 너무 피로해서 더 이상 건드리기 조차도 싫어졌다.

 

그때 처음으로 강렬히 느꼈던 것 같다.

 

"아 , 설계 문서를 남겨놓아야 되겠구나"

 

이 때만 해도 딱 이정도 정의에서 벗어나지도 표현하지도 못했다 말그대로 필요성만 느꼈을 뿐 

 

시간이 지나면서 유지보수 뿐만이 아니라 전체적으로 설계, 테스트코드가 중요한 역량인 이유에 대한 나의 생각은 갈수록  하나둘씩 더해져갔다.

 

특히 요번주차에는 처음으로 자기 자신이 만든 기능에 대한 기능 테스트 코드를 작성하면서 본문에 적었듯이  테스트 코드가 왜 중요한지에 대해 다시 한번 생각하고 깊어져서 더욱 감사한 경험이였다. 

 

 

개발자에게 중요한 역량으로 나오는 핵심 역량중 하나가 문제해결 역량이다. 

 

나는 이 문제해결 역량이 설계와 테스트코드 에서 절반 정도 온다고 생각한다.(문제 파악, 가설 , 검증)

 

그래서 배우고 익히고 싶다고 생각했지만

 

첫주차에 적었듯이 어찌  훈련 해야될지도 모르겠고 어떻게 익혀야되는지도 감이 잡히지 않았다

 

근데 그걸 단계별로 익히고 있다 는 사실이 감사하게 생각됬다

 

아마 그동안의 우테코 코딩테스트 수준이 어느정도였는지는 모르겠지만  이전 처럼 코딩 테스트를 쳐야 프리코스를 참여할 수 있었다면 

 

프리코스를 경험해볼수 있을 확률이 객관적으로 좀 더 떨어 졌을거라고  생각하니 새삼 더 감사했다.

 

물론 과정 을 진행하며 고통이 없진 않다 

 

하지만 정말로 감사함이 더 큰 거 같다. 

 

한편으로는 걱정도 된다 다음 주 는 잘 마무리 할 수 있을까? 

 

진행하면서 그냥 우테코에서 제시하는 방향대로만 열심히 해도 되겠다는 신뢰가 들었지만

 

나는 나대로 생각하는걸 멈추지 않을것이다. 

 

다음주에도 성실히 능동적으로 임하며 프리 코스 마무리 까지 우테코에서 제시해주는 방향대로 잘 임하고 싶다

 

 

 

 

 

 

 

 

 

 

 

 

 

---

<이전 우테코 글 목록>

 

우테코 프리 코스 1주차 후기 : https://hello-coding-world.tistory.com/45