레벨1 자동차 경주 - step1

개요

미션	기간	Repository	PR & Review
자동차 경주 1단계	23-02-07 - 23-02-09	Repo	PR & Review

 

🚀 미션 회고

우테코 5기의 첫 미션은 자동차 경주이다. 해당 미션은 지난 기수의 프리코스 미션으로 이미 최종 코딩테스트를 준비하기 위해 한 번 구현을 했었다. 그렇기 때문에 큰 두려움 없이 미션을 시작할 수 있었다.

자동차 경주미션은 단 일주일동안 이루어진다. 그중 3일 동안은 페어프로그래밍으로 진행되며 이는 step1에 해당된다. 이후 리뷰어의 피드백을 받은 후 진행되는 step2는 스스로 리펙터링을 하는 과정이 이루어진다. 즉, 첫 리뷰를 기점으로 앞은 step1, 뒤는 step2가 된다. 우테코에서의 첫 미션이기도 하니 미션이 어떤 과정으로 이루어지는 간략히 적어보았다.

다시 미션으로 돌아와서, 레벨 1에는 총 4개의 미션이 주어진다. 그중 첫 미션인 자동차 경주는 프리코스 미션과 동일하게 html, css 없이 javascript로만 진행되었다. 때문에 다른 3개의 미션과 다르게 기간이 짧은 듯하다. 보다 편하게 적응하라는 우테코의 뜻이지 않을까 싶다.

이번 미션의 학습 목표, 기능 요구사항, 프로그래밍 요구사항, 과제 진행 요구사항을 읽은 뒤 페어프로그래밍을 시작하였다.

👬 페어프로그래밍 회고

누군가와 함께 같은 화면을 보며 코드를 작성하는 페어프로그래밍은 이번이 처음이었다. 지금까지 페어프로그래밍에 대한 경험이 없었기 때문에 과연 도움이 될까? 더 발전된 코드를 작성할 수 있을까?라는 의문이 들었다. 하지만 경험하지 못하면 페어프로그래밍의 장점도 모르는 법이다. 비록 3일이라는 짧은 기간 동안 페어프로그래밍을 해보았지만 그 기간에 나는 페어프로그래밍의 장점을 발견할 수 있었다. 그중, 하나는 내가 미쳐 생각하지 못했던 다른 사람의 생각이다.

하나의 기능에 대해서도 사람마다 작성하는 코드의 위치, 사용하는 메서드는 모두 다르다. 당연히 이번 페어프로그래밍에서도 이를 느낄 수 있었다. 때문에 하나의 메서드 또는 기능을 코드를 작성하기 위해서는 혼자 하는 것보다 많은 시간을 투자해야 했다. 시간만 늘어나는 것이 무슨 장점이냐? 할 수 있지만 그 늘어난 시간이 과연 허투루 쓴 시간일까? 하면 전혀 그렇지 않다. 내 의견을 페어에게 전달하는 과정에서 나의 생각을 다시 정리할 수 있었고, 페어의 의견을 들으면서 내가 생각하지 못했던 다른 관점에서 코드를 바라볼 수 있었다. 이런 의사소통의 과정이 전혀 아깝지 않은 시간이었다. 빨리 기능 구현을 하면 무엇이 좋을까? 코딩 테스트를 보는 것도 아니다. 코드 한 줄에서도 많은 의견 오고 가며 생각을 넓히는 것이 더욱 중요하다. 이를 도와주는 것이 페어프로그래밍이구나 라는 것을 깨닫게 되었던 시간이었다.

이런 페어프로그래밍을 계속 이어나가면 혼자서 리펙터링을 할 때에도 이전의 페어프로그래밍 경험들이 많은 도움이 될 수 있을 것 같다. 나의 생각을 페어에게 친절히 전달하고 페어의 의견을 경청해보자.

이러한 관점에서 이번 페어프로그랭의 페어인 제레미에게 큰 도움을 얻었다. 프리코스를 하면서 굳어졌던 습관에 대해 다시 돌아볼 수 있었다. 물론 나의 의견과 페어의 의견이 충돌되는 과정에서 많은 혼란을 받기도 했었다. 하지만 이를 고민하여 나만의 기준을 세우는 것도 성장하는 하나의 길이라고 생각한다. 정답은 없다. 다만, 정답을 구하는 과정에서 혼자보다 페어와 함께 고민하는 것은 더 다양한 시각을 가지게 한다. 넓혀진 시각은 분명 나에게 도움이 될 날이 온다. 땡큐 제레미!

페어프로그래밍은 기본적으로 한 명의 레포를 가지고 코드 작성을 진행한다. 때문에 이번 페어프로그래밍은 제레미의 레포를 기준으로 진행하였다. 해당 과정에서 같은 화면을 통해 코드를 작성해야 했기 때문에 Live Share 익스텐션을 설치하여 이를 활용하였다. 이 또한 신세계였다... 페어가 작성한 코드가 그래도 내 노트북의 에디터에서도 보인다니... 짱이었다!

걱정되었던 부분도 있었다. 미션을 진행하다 보면 커밋이 쌓이게 되는데 이를 내 저장소로 가져와야 했다. 이를 어떻게 해야 할지를 첫날부터 걱정하고 있었다. 하지만 이런 말이 있지 않는가? 지나가 보면 정말 아무것도 아닌 것으로 걱정한다. 정말 아무것도 아니었다. 그렇다고 쉬운 과정이라고는 생각하지 않지만 페어와 함께 고민하고 시도하다 보니 금방 해결되었다. 일단 remote 명령어로 페어의 레포를 연결하고 pull로 코드를 땡겨오면 그만이었다! 성공하고 나니 이 또한 너무 재밌었다!

👍 잘한 점

1. 페어프로그래밍 과정에서 의견에 대한 충돌이 생겨도 각자의 의견을 서로 존중하며 페어프로그래밍을 이어나갔다.
2. 기능 구현은 물론 나름의 테스트 코드와 리펙터링도 페어와 함께 마무리하였다.
3. 정규 표현식, 메서드 체이닝, Jest 문법에 대한 개념이 페어에게 도움이 되어 뿌듯하다.
4. 페어의 코드를 나의 저장소로 땡겨오는 과정을 함께 고민하여 해결하였다.

👎 아쉬운 점

1. 학습 목표를 도달하기 위한 고민과 노력이 적었다.
2. 보다 꼼꼼하게 요구사항을 읽어보지 않았다.
3. 미션을 진행하면서 생긴 고민을 바로 정리하지 않았다.
4. 페어프로그래밍을 진행하면서 서로 지켜야 할 규칙을 정했지만 잘 지켜지지 않았다.

👊 앞으로의 각오

1. 나의 의견을 조리 있게 말하기
2. 페어의 의견을 경청하고 이에 대한 나의 생각 말하기
3. 부족한 부분이 있으면 학습해서 공유하기
4. 학습 목표에 도달하기 위해 노력하기
5. 문서 잘 읽기!
6. 페어와 페어프로그래밍을 하면서 지켜야 할 규칙을 문서화하기

🛠️ 리팩터링

1. 도메인 로직과 UI 관련 로직 분리하여 관리하기
   • 두 로직의 하위 모듈은 서로 의존하지 않는다.
2. 도메인 로직에서 테스트하기 어려운 부분은 분리하기
3. 도메인 로직에서 테스트 가능한 부분에 대해서만 단위 테스트 작성하기
   • mock함수를 사용하지 않는다.
4. 요구 사항에 명시되어 있진 않지만 고려해야 할 예외 상황 정리하기
5. 이름을 통해 의도 드러내기
   • 축약 금지, 범용적인 용어 금지, 실제 동작과 이름이 일치
6. 함수가 한 가지 기능만 담당하기
7. boolean 값만 리턴해주는 함수라면 조건문 없이 리턴하기
8. 반복문보다는 Array 내장 메서드 사용하기
9. util(lib)의 의미에 맞게 사용하기
10. Validator의 메서드명 검토하기
11. 자동차게임을 관리하는 객체 만들기
12. ES6 모듈 시스템 도입하기