[우테코] Lv. 1 자동차 경주 구현 - 1단계(페어) 후기

배경지식!

01. racing은 비슷한 요구사항으로 최종 코테를 준비할때 구현해본 경험이 있다.

02. 기존에는 우테코에서 제공하는 유틸..어쩌구를 쓸 수 있었고 이번엔 사용하지 못한다는 것 빼고 다 동일 조건이었다.

03. 1단계는 페어로 이루어져 하나의 컴퓨터로 같이 코드를 짠다.

04. 기간은 총 3일이며 오전에는 교육/팀미팅이 있어 못했고 오후에만 했다.

05. 따지자면 17시간정도 짠 거 같다..ㅎ (이렇게 오래 걸릴 일이 아니었는데..?)

06. 누가 노트북을 잡고 쓸지는 커밋하면 체인지하기로 했는데 둘이 의견도 잘 내고 말도 잘 해서 크게 상관은 없었다.

 

---

악! 첫 미션이었다. 

어려운 미션은 아니었다.

하지만 어려웠다... 일주일 제한시간에서 3일로 줄은 상황이었고 같이 해야 하니 혼자 계속 붙잡을 수도 없었다.

더불어서 둘이 스타일이 다르니 상의하고 코드짜고 산으로 가고 그거 수정하고.. 하다보니 오래 걸렸다.

왜 같이 하는 연습을 해야 하는 지 크게 알겠는 부분이었다.

 

📍 학습 목표 성취도

• Github 기반으로 온라인 코드 리뷰 : 여러번 헷갈려 어려웠지만 3번 정도 받음
• 코딩 컨벤션을 준수하며 개발: 실패, 처음에 할 때 시간이 부족하다는 핑계로 하나도 신경쓰지 못함, 이후 설정을 함
• 단위 테스트를 작성하며 개발: 코드를 쓰며 하고 싶었는데 실패, 그래도 어느정도는..?
• 함수(또는 메서드)를 분리하는 리팩터링: 짝이 굉장히 나누는 사람이라 이런거까지도 나눠야하는구나 배움.

 

미션진행 중 어려웠던 부분

1. readline

정말 골치가 아팠다. 다른 사람들은 무난하게 넘어간거 같은데, 우린 왜 이게 그렇게 걸림돌이었는지..

두차례 input을 받아야하는데, 우리가 생각할때는 

const readline = require("readline");

const rl = readline.createInterface({
    input: process.stdin,
    output: process.stdout
})

rl.on("line", (line) => {
      callback(line)
      rl.close()
}) ;

이게 대표적인 사용법이었고, 그래서 rl.on을 두번 해주면 될 것이라고 생각했다. 

하지만 그렇게 생각대로 되지 않았고 어떻게 변형해서 굴러가게 했다.

나중에 찾아보니 잘못된 사용법이라고 했지만 너무 고치기엔 시간이 많이 흘러 건드릴 수 없었다.

이 readline은 좀더 찾아보고 공부해서 개인공부에 올리고 싶은 마음이다.

같은 팀에서 객체로 신기하게 쓰는 걸 봤는데 깃헙에 PR한걸 보고 공부 좀 해보고 정석적인 내용 말고 응용을 좀 해보고 싶다.

 

그래도 조금 깨달은 것은 readline은 한번 열리는 것 같다는 것..?

그리고 저렇게 있는 rl.on("이것", ( 이것 ) => { 내용 }), 여기에서 이것이 일치하지 않으면 돌아가지 않는다;;

기존에 우테코에서 제공한 readLine을 사용하던 습관으로 자연스럽게 저 ""가 message인줄 알고 고쳤다가 된통 헤맸다.

찾아보니 rl.question("message", (변수)=>{내용}) 이렇게 사용이 가능하다.

나중에 올릴때 rl.---도 찾아봐야 겠다.

 

 

2. 형 변환 

 이건 그냥 내 자신에게 화가 나는 부분이다.. input으로는 문자형으로 들어온다.

아무 생각없이 이걸 따로 형변환 없이 Number.isInteger(input)에 넣었으니 오류가 계속 났다.

나중에 깨닫고 나서는 아주 화가 났다. 다들 이렇게 하지 맙시다..

 

 

3. MVC패턴

이건 어려웠던 것은 아니다. 왜냐면 이걸 안했으니까!

이전에 프리코스 4주차 미션 중 잘하신 분의 코드를 분석하면서 알게된 건데,

완전히 이론적으로 아는 것이 아니니 엇비슷하게만 따라했다. 

그러다보니 더 형태가 이도저도 아니게 된 것 같았는데 내 스스로 개념을 정리하지 못해서 오는 혼란이었다.

더 찾아봐야겠다는 생각을 했다. 그리고 내 나름의 규칙을 만들어봐야지.

 

 

 4. 깃허브

악. 나는 코드 짜는것보다 깃허브가 더 어려운 것 같다.

나보다는 내 짝이 더 잘해서 믿고 따랐는데 하다보니 나 진짜 못하는 구나 싶었다.

지금까지 우테코에서 안내해준 내용대로만 따라서 해서 명령어를 외우지도 못했다.

잘 못한다고 잘하는 사람한테 맡기기만 하다간 나는 영원히 못하겠지 싶다.

그래서 깃헙을 공부..까지는 아닌데 그 메커니즘을, 단어를 이해하는 정도로 알아봐야겠다.

 

그리고 이번에 제일 애먹었는데 허무하게 해결되었던게 있다. 

페어 프로그래밍이다보니 짝 컴퓨터에서 진행을 했는데,

짝은 그냥 PR했고, 내 차례였다.

우테코에서 준 힌트에 따라 짝 컴퓨터에서 내 저장소를 원격 저장소로 추가한 후 Push를 하려고 했지만 에러에 막혔고,

이는 간단히 내 컴퓨터에서 우테코것을 포크하고 클론하고 브랜치까지 파고, 짝 사이트 주소를 가지고 풀 하는것으로 내 노트북으로 가지고 올 수 있었다. 그리고 간단히 푸시.. PR을 했다. 

 

 

기억에 남았던 부분

1. 짝

 다행히 좋은 짝을 만났다. 나는 생각보다 사람을 많이 타는데, 특히 일과 관련되면 생각보다 예민하다.

자기주장도 강하고(아직은 모르는게 많아서 그러진 않지만), 상대방이 툭툭 던지는 말에 감정적이기도 하다.

그래서 걱정이 많이 되기도 했는데 다행히 비슷한 나이대에 잘맞는 짝을 만나서 즐거웠다.

그것과 별개로 파트너가 있다는 것에서 오는 단점이 분명히 있다. 

오래걸린다. 내 의견과 상대의 의견이 같을리 없기 때문에 조율해야하는데 이 시간이 오래 걸린다.

만약 이 과정이 부족하다면 코드가 산으로 간다. 목적지가 확실하기 때문에 길을 잃지는 않는다.

다만, 좋은 코드에서 점점 멀어진다..

때문에 설계 과정에서 방향성을 확실하게 정하고 최대한 구체적이게 상의해야 한다고 느꼈다.

더불어 뭔가 아닌거 같다 싶으면 바로바로 이야기하고 그 자리에서 정해야겠다고 생각했다.

 

 

2. 새로운 환경에서 오는 불안감

늘 내가 잘 하고 있는지에 대한 의문이 있다.

나는 내가 못난 사람이 아니라고 생각한다.

그렇기에 스스로 부족함을 느끼는 것도 근거있는 생각이라고 생각한다. 

남들은 동아리든, 수업이든, 전공이든, 플젝이든 무엇이든 해봤지만 그런걸 나는 해본 경험이 없다.

게다가 주변에 개발자도 그다지 없다. 같이 공부할 사람은 더더욱이나 없었다.

 

그래서 모르는 단어, 개념을 들으며 내가 많이 부족하구나 깨닫는 순간이 매우 많다.

거기서 오는 불안감이 있다. 

하지만 괜찮다. 적어도 처음 시작할 때보다 3개월 전 내가 더 잘했고, 3개월 전 나보다 지금의 내가 좀더 많이 알테니까.

더 공부하자는 자극제로 쓰고자 한다.

뭐.. 슬프긴 하지만 어쩌겠는가. 내가 잘해지면 되는거지. 아자.

 

 

 

앞으로 해야 할 부분

1. 모르는 개념 알아보기

지금 ICT기사 사설 스터디를 하고 있다. 단순히 기사를 공유하는 수준이지만 새로운 트랜드를 놓칠까봐 하고 있다.  

여기서 프론트엔트에 국한되지 않은 다양한 용어, 개념, 트랜드 등을 얻는데 모르는 것들이 많다.

이 단어들과 우테코를 하면서 듣게되는 단어, 개념들을 모아 정리할까 한다. 

해봐야 다른 사람들의 글을 모으는 것이라서 블로그에 올리지는 않을 것이지만 그렇게 "내가 모르는 것들"의 폭을 넓히고자 한다.

 

2. JEST 

 한번 했는데도 불구하고 다 까먹었고,, 어떻게 쓰는지 모르겠고.. 테스트가 중요한거 알지만 잘 못하겠다.. 공부해야겠다..