우테코 5기 프리코스: 2주차 회고

 

 

일주일을 우테코 미션 생각으로 가득 채워 보내다 보니 시간이 정말 금방 지나가는 것 같습니다.

벌써 프리코스의 절반이 지났네요. 

2주 동안 방향성을 잡고, 피드백을 받으면서 공부하니까 짧은 기간임에도 성장하고 있다는 걸 체감하게 되는 것 같습니다!

저번 회고에서는 매주차 미션이 끝나고 과제와 함께 제출하는 소감문만 첨부해서 빠르게 회고를 끝냈었습니다.. 

2주 차를 시작해야 된다는 조급함이 앞섰기 때문이었죠..

1주차 미션을 끝내고 피어 리뷰도 진행했었는데 너무 다음 미션만 생각하다 보니 1주 차 때 받은 피드백을 제대로 반영하지 못하고 지나간 느낌이라 2주 차에는 목표로 했던 부분과 피드백받은 부분을 위주로 정리하고, 3주 차를 시작해보려고 합니다.

 

 

 

 

 

 

2주 차 미션 진행 과정

 

 

문제 설명 

 

 

2주차 미션은 야구 게임이었는데 우테코 프리코스에서 계속 출제되었던 문제였다고 합니다.

 

 

GitHub - oseunghyun/javascript-baseball: 숫자 야구 게임 미션을 진행하는 저장소

 

 

 

1주 차 미션에서 업그레이드된 요구사항 

 

기능 구현 외에도 1주차 미션에서 더 업그레이드된 프로그래밍 요구사항과 과제 진행 요구 사항이 있었습니다.

jest...!? 마침 지난주에 진행중이던 사이드 프로젝트에서 버그를 잡지 못해서 테스트 코드를 사용해볼까 하고 jest 사용법에 대한 간단한 강의를 찾아봤었는데 이렇게 바로 제가 사용하게 될 줄은 몰랐습니다.. 그래도 낯선 이름에서 오는 그런 막연한 두려움이 있는데 jest는 그나마 많이 들어보기는 해서 그래 해보면 되지 하고 크게 겁먹지는 않았던 것 같아요. TDD까지 생각하신 분들도 있는데 저는 그냥 할 수 있는 부분에서 최선을 다하자고 생각해서 예시를 참고해서 단위 테스트까지만 구현해보았습니다..! 

나머지는 클린 코드를 지향하는 부분, 그리고 제가 가장 어려워하는 메서드가 한 가지 일만 하도록 해라!! 는 내용이 있습니다.

 

 

---

•  JavaScript 코드 컨벤션을 지키면서 프로그래밍했는지
  •  Airbnb 자바스크립트 스타일 가이드를 기준으로 하고 있는지
•  indent(인덴트, 들여 쓰기) depth가 3을 넘지 않는지 (2까지만 허용)
  • depth를 줄이는 좋은 방법: 메서드를 분리
•  Jest를 이용하여 내가 정리한 기능 목록이 정상 동작하는지 테스트 코드로 확인했는지
•  MissionUtils 라이브러리에서 제공하는 Random 및 Console API를 사용하여 구현했는지
•  메서드가 한 가지 일만 하도록 최대한 작게 만들었는지

---

 

 

 

구현 기능 목록 작성 (Readme.md)

 

저는 우선 리드미에 미션에서 주어진 요구사항들 중 제가 체크해야 할 것들을 전부 작성한 후,

이를 바탕으로 구현할 기능 목록들을 작성하고 구현하면서 계속 업데이트해나갔습니다.

구현할 기능 목록 작성하는데만 하루를 꼬박 쓰게 되는 것 같습니다..

그랬는데도 부족한 점이 많았던 거 보면 3주 차는 시간을 더 써야 할 것 같아요..ㅎ

 

 

 

 

 

 

2주 차 미션 주요 이슈사항

 

• 비동기 문제: MissionUtils 라이브러리를 통해 사용자 입력을 받아왔는데 비동기 처리를 하고 나니 jest에서 테스트 실행이 정상적으로 되지 않았습니다. 테스트 파일을 변경하면 안 되었기 때문에 매우 찝찝하게 콜백으로 처리를 하긴 했습니다만.. 비동기에 대한 지식이 부족한 것 같아 공부가 더 필요한 것 같습니다.
• 클래스 사용: 클래스에 익숙하지 않습니다..💦 그렇다고 하나의 파일에 전체 내용을 넣는 것은 가독성도 떨어지고 분리가 필요하다고 생각해서 utils 폴더에 computer.js와 validations.js로 기능을 분리했습니다. 클래스에 대한 부분도 공부가 필요합니다..
• 영어로 커밋 메시지 작성: 커밋 컨벤션을 제대로 지켜보고 싶어서 한글보다 엄격한 규칙이 적용되는 영어로 작성해보았는데요.. 덕분에 시간이 더 걸리긴 했지만 계속 시도해볼 생각입니다..ㅎ

 

 

 

 

1주 차 피드백을 통한 2주 차 점검

 

1주차 때 공통 피드백받은 내용과 피어 리뷰에서 받은 내용인데 계속 생각하면서 미션에 임했습니다.

2주 차에서 얼마나 잘 지켰는지 체크해보겠습니다... 하하

 

 

 

💌 1주 차 공통 피드백 ✅

---

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

과제 제출 전에 기능 요구 사항, 프로그래밍 요구 사항, 과제 진행 요구 사항의 항목을 모두 잘 지켰는지 다시 한번 점검한다. 

 

 

커밋 메시지를 의미 있게 작성한다 ✅

커밋 메시지에 해당 커밋에서 작업한 내용에 대한 이해가 가능하도록 작성한다.

 

git을 통해 관리할 자원에 대해서도 고려한다 🙏🏻

앞으로 git에 코드를 추가할 때는 git을 통해 관리할 필요가 있는지를 고려해볼 것을 추천한다.

 

➡️ clone 해서 작업하고 추가되는 문서는 js와 테스트 파일뿐이었어서 아예 고려하지 않았던 것 같습니다.

다행히 이번엔 git에서 제외할 파일이 없는 것 같지만 앞으로는 코드 추가 전에 먼저 고려해봐야겠습니다.

 

 

Pull Request를 보내기 전 브랜치를 확인한다 ✅

기능 구현 작업을 fork 된 Repository의 main branch가 아닌, 기능 구현을 위해 새로 만든 브랜치에서 작업한 후 PR을 보낸다. 

 

 

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

PR을 이미 한 번 보냈다면, 새로운 PR을 생성할 필요가 없다. 수정이 필요하다면 추가 커밋을 하면 자동으로 반영된다. 단, 미션 제출 기간 이후에는 추가 커밋을 하지 않는다.

 

 

이름을 통해 의도를 드러낸다 🙏🏻

나 자신, 다른 개발자와의 소통을 위해 가장 중요한 활동 중의 하나가 좋은 이름 짓기이다. 변수 이름, 함수(메서드) 이름, 클래스 이름을 짓는데 시간을 투자하라. 이름을 통해 변수의 역할, 함수의 역할, 클래스의 역할에 대한 의도를 드러내기 위해 노력하라. 연속된 숫자를 덧붙이거나(a1, a2,..., aN), 불용어(Info, Data, a, an, the)를 추가하는 방식은 적절하지 못하다.

 

➡️ 고민은 열심히 했는데 여전히 부족한 것 같습니다..

 

 

축약하지 않는다 ✅

의도를 드러낼 수 있다면 이름이 길어져도 괜찮다.

 

 

공백도 코딩 컨벤션이다  ✅

if, for, while문 사이의 공백도 코딩 컨벤션이다.

 

 

공백 라인을 의미 있게 사용한다. 🙏🏻

공백 라인을 의미 있게 사용하는 것이 좋아 보이며, 문맥을 분리하는 부분에 사용하는 것이 좋다. 과도한 공백은 다른 개발자에게 의문을 줄 수 있다.

 

➡️ 피어 리뷰에서 바로 피드백받았습니다..ㅎ

 

 

space와 tab을 혼용하지 않는다 ✅

들여 쓰기에 space와 tab을 혼용하지 않는다. 둘 중에 하나만 사용한다. 확신이 서지 않으면 pull request를 보낸 후 들여 쓰기가 잘 되어 있는지 확인하는 습관을 들인다. 

 

➡️ tab 써야죠.. 실리콘 밸리 또 보러 가야겠습니다..

 

 

의미 없는 주석을 달지 않는다 ✅

변수 이름, 함수(메서드) 이름을 통해 어떤 의도인지가 드러난다면 굳이 주석을 달지 않는다. 모든 변수와 함수에 주석을 달기보다 가능하면 이름을 통해 의도를 드러내고, 의도를 드러내기 힘든 경우 주석을 다는 연습을 한다.

 

➡️ 주석 없이 메서드 이름으로 잘 드러내 보려고 했는데 더 고민해보는 걸로 

 

 

linter와 Code Formatter의 기능을 활용한다 🙏🏻

 

➡️ 해당 컨벤션에 맞게 설정을 다시 체크해보기도 해야겠습니다. 린터만 믿었는데 제가 double quote 사용으로 해두어서 single quote를 사용하라는 가이드에 어긋나더라고요..

 

 

EOL(End Of Line) 🙏🏻

최종 제출하는 코드에서 EOL을 확인한다. 환경에 따라 의도한 바와 다르게 개행 문자 처리가 되지 않도록 EOL 설정을 확인한다.

 

➡️ 확인 안 했다!

 

 

불필요한 console.log를 남기지 않는다 ✅

 

➡️ 얼마 전 사이드 프로젝트 배포하면서 이런 피드백을 받은 적이 있어서 다 지웠다.

 

 

JavaScript에서 제공하는 API를 적극 활용한다 🙏🏻

 

➡️ 1주 차보다는 많이 사용했는데 freeze api 3주차에는 꼭 써보겠다.

 

 

 

 

---

 

💌 1주 차 피어 리뷰

---

메서드 분리 🙏🏻

 

➡️ 더 분리해보자!

 

 

if 문 중첩 줄이기 🙏🏻

else if 지양, early return, 기본 api 사용으로 줄이기

 

➡️ 많이 발전했지만 여전히 개선점이 보인다!

---

 

 

 

 

 

 

 

2주 차를 마치고

 

 

2주차 피드백

 

공통 피드백인데 어쩜 제가 고민했던 부분들에 대한 내용이 가득 담겨있는지 모르겠습니다..ㅎ

2주 차 때 얼마나 지켜졌는지 점검해보고 3주차 미션을 진행하면서 계속 고려하면서 개발에 임해야겠습니다!

 

 

💌 2주차 공통 피드백 ✅

---

README.md를 상세히 작성한다 🙏🏻

미션 저장소의 README.md는 소스코드에 앞서 해당 프로젝트가 어떠한 프로젝트인지 마크다운으로 작성하여 소개하는 문서이다. 해당 프로젝트가 어떠한 프로젝트이며, 어떤 기능을 담고 있는지 기술하기 위해서 마크다운 문법을 검색해서 학습해보고 적용해 본다.

 

기능 목록을 재검토한다 ✅

기능 목록을 클래스 설계와 구현, 함수(메서드) 설계와 구현과 같이 너무 상세하게 작성하지 않는다. 클래스 이름, 함수(메서드) 시그니처와 반환 값은 언제든지 변경될 수 있기 때문이다. 너무 세세한 부분까지 정리하기보다 구현해야 할 기능 목록을 정리하는 데 집중한다. 정상적인 경우도 중요하지만, 예외적인 상황도 기능 목록에 정리한다. 특히 예외 상황은 시작 단계에서 모두 찾기 힘들기 때문에 기능을 구현하면서 계속해서 추가해 나간다.

 

기능 목록을 업데이트한다 ✅

README.md 파일에 작성하는 기능 목록은 기능 구현을 하면서 변경될 수 있다. 시작할 때 모든 기능 목록을 완벽하게 정리해야 한다는 부담을 가지기보다 기능을 구현하면서 문서를 계속 업데이트한다. 죽은 문서가 아니라 살아있는 문서를 만들기 위해 노력한다.

 

값을 하드 코딩하지 않는다 🙏🏻

문자열, 숫자 등의 값을 하드 코딩하지 마라. 상수를 만들고 이름을 부여해 이 변수의 역할이 무엇인지 의도를 드러낸다.

 

구현 순서도 코딩 컨벤션이다 🙏🏻

클래스는 필드, 생성자, 메서드 순으로 작성한다.

 

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

함수 길이가 길어진다면 한 함수에서 여러 일을 하려고 하는 경우일 가능성이 높다. 아래와 같이 한 함수에서 안내 문구 출력, 사용자 입력, 유횻값 검증 등 여러 일을 하고 있다면 이를 적절하게 분리한다.

 

함수가 한 가지 기능을 하는지 확인하는 기준을 세운다 🙏🏻

만약 여러 함수에서 중복되어 사용되는 코드가 있다면 함수 분리를 고민해 본다. 또한, 함수의 길이를 15라인을 넘어가지 않도록 구현하며 함수를 분리하는 의식적인 연습을 할 수 있다.

 

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

JavaScript에서는 클래스 말고도 객체를 만드는 방법은 여러 가지가 있다. 객체를 생성하는 방법에 대해서는 MDN 문서의 JavaScript 객체 기본과 Classes을 참고한다.

 

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

단지 기능을 점검하기 위한 목적으로 테스트를 작성하는 것은 아니다. 테스트를 작성하는 과정을 통해서 나의 코드에 대해 빠르게 피드백을 받을 수 있을 뿐만 아니라 학습 도구로도 활용할 수 있다. 이런 경험을 통해 테스트에 대해 어떤 유용함을 느꼈는지 알아본다.

 

처음부터 큰 단위의 테스트를 만들지 않는다 ✅

테스트의 중요한 목적 중 하나는 내가 작성하는 코드에 대해 빠르게 피드백을 받는 것이다. 시작부터 큰 단위의 테스트를 만들게 된다면 작성한 코드에 대한 피드백을 받기까지 많은 시간이 걸린다. 그래서 문제를 작게 나누고, 그중 핵심 기능에 가까운 부분부터 작게 테스트를 만들어 나간다.

 

 

 

 

💌 2주 차 피어 리뷰 

---

1. getHintOfAnswer: 함수 더 분리
2. checkIfRestartGame: 메시지 상수로 따로 분리
3. Eol-last 적용
4. Const app = new App(); 삭제
5. Single quote 사용
6. Boolean 비교 시에는 단축형을 사용
7. undefined로 변수 선언하지 않기 randomNum에 Const 선언하고 바로 사용
8. if문 없애고 삼항 연산자 사용

---

 

 

 

소감문

 

부끄럽지만 과제와 함께 제출했던 소감문을 첨부해보며 오늘날의 회고를 잊지 않고 계속 성장해가겠다는 다짐을 해봅니다..!

함께 하는 사람들이 있어 더욱 힘이 나는 것 같습니다. 통제할 수 없는 일에 미련을 버리고 지금 내가 할 수 있는 일에 집중하는 태도로 3주 차도 힘내 보겠습니다!!

 

2주 차 미션은 주어진 요구사항 목표에 1주 차 미션에서 받은 피드백을 더해 학습하고자 하였다. 1주차에 비해 많아진 요구사항들을 놓치지 않기 위해 개발에 앞서 기능, 프로그래밍, 과제 진행 요구사항별 체크리스트와 제출 전 확인해야 할 목록을 포함한 문서를 작성하고 이를 바탕으로 내가 구현할 기능 목록을 작성하였다. 1주차 미션을 마치고 코드 리뷰를 통해 함수를 더 작은 단위로 분리할 수 있었겠다는 아쉬움을 느꼈기 때문에 1 기능 1 함수를 구현하고자 신경을 썼다. 예외 처리도 하나의 기능으로 분리하고, 예외에 해당하는 케이스도 구체적으로 작성하였다. 기능 목록 작성에만 하루가 걸린 것 같다. 리팩터링을 하면 할수록 수정할 것들이 새로 보였지만 그만큼 리팩터링 하기 쉬운 가독성 좋은 코드가 되는 것 같아 완벽하지 않아도 의미 있는 고민이었다고 생각한다.

이번 미션부터는 커밋 컨벤션을 철저하게 준수해서 작성해보고 싶었는데 참고 자료와 같기도 하고 한글보다 영어로 작성되는 커밋에 더 엄격한 규칙을 적용하고 있는 것 같아 영어로 작성해보기 시작했다. 컨벤션 문서를 통해 scope이라는 부분을 처음으로 작성해보았는데 scope을 통해 어떤 부분에 대한 커밋인지 한눈에 확인할 수 있어서 편리했다. 또 상황에 따라 어떤 타입으로 작성해야 할지 애매하다고 생각되는 부분은 우아한테크코스의 레포지토리의 커밋 예시를 찾아보며 배웠다. 하나하나의 커밋 작성에 시간이 많이 들었는데 처음에 제대로 고민하고 작성하니까 다음번 비슷한 상황에서는 나만의 기준이 생겨 시간도 줄고 가독성도 높아져서 제대로 된 문서 작성의 중요성을 또다시 느꼈다.

기능 구현에서는 함수가 한 가지 일만 하도록 최대한 작고, 가독성이 좋은 코드를 작성하는 데 집중했다. 1주 차 미션에서 조건문의 중첩이 많아 가독성이 떨어진다는 피드백을 받았었는데 early return으로 조건을 배제해 나가면서 중첩 수준을 낮출 수 있었고 javascript에서 제공하는 기본 api를 찾아 코드를 줄일 수 있었다. indent를 3이 넘지 않도록 구현하라는 요구사항을 충족시키려다 보니 자연스럽게 클린 코드를 지향하는 마음 가짐을 가지게 된 것 같다.

테스트 코드는 프리코스에서 처음 사용해봤기 때문에 익숙하지 않았지만, 작은 기능부터 단위 테스트를 시도해보았다. 테스트 코드를 작성하면서 함수명은 getHintOfAnswer인데 막상 hint는 리턴을 받는 게 아니라 출력만 하고, 해당 함수의 실행 이후에 작동할 다음 함수를 반환해서 제대로 테스트를 진행해 볼 수 없는 상황도 있었다. 함수명과 함수가 담고 있는 내용이 다르다는 것을 알게 되었고, 이 함수가 더 작아질 수도 있겠다고 생각했다. 테스트 코드를 아직 잘 작성하지 못함에도 테스트 코드를 통해 내가 작성한 코드에 대해 피드백을 받는다는 게 이런 의미구나 라는 걸 배울 수 있었고 기능이 커지면 커질수록 테스트의 유용성도 커지고 보다 체계적으로 개발이 가능할 것 같아 차후에도 이 방식을 적용해 개발해야겠다고 생각했다.

1주 차와 2주 차의 미션 내용은 다르지만, 프로그래밍 전체를 관통하는 클린 코드 작성, 문서의 중요성 등을 느낄 수 있었고 혼자 공부를 하다 보면 늘 내 방식대로 공부하게 되는데 다른 사람들의 코드를 보고 이렇게도 할 수 있구나를 많이 배울 수 있었다. 수업이나 선생님이 따로 있는 과정이 아님에도, 공부의 방향성을 잡고 학습해갈 수 있어 어떤 점이 부족한지를 파악하고, 부족한 부분을 채우는 과정에서 성취를 많이 느껴 앞으로의 과정이 더 기대된다.