[회고] 우아한테크코스 2주차 회고 (FE)

우테코 프리코스 2주차 회고

2주차 - 🚀 숫자 야구

1주차와 다르게 2주차는 문제가 숫자 야구 하나였다.

문제는 하나로 줄었지만 완성하는데 걸리는 시간은 1주차와 비슷했다.

 

🏃‍♂️ 시작하며

추가된 요구사항 부분에 indent depth 제한이 새롭게 생겼다.

 

while문 안에 if문이 있다면 들여쓰기는 2가 된다. 이러한 들여쓰기를 2까지만 허용한다.

 

indent depth를 줄이는 좋은 방법은 함수(메소드)를 분리하는 것이다.

 

또한, 각 함수(메소드)가 한 가지 일만 하도록 최대한 작게 만들어야 한다.

 

마지막으로 Jest를 이용해서 본인이 정리한 기능 목록이 정상 동작함을 "테스트 코드로" 확인해야 한다.

 

 

처음 문제를 읽어봤을때 당황했던 부분은 프로그램의 시작점 역할을 하는 App.js의 play 메소드가 클래스로 주어진 것이었다.

const app = new App();
app.play();

 

JS로 절차지향 프로그래밍만 해왔었기 때문에 OOP에 대해서 스스로 공부하게 되었다.

---

✨ 과정 및 배운점

OOP에 대해 배울 수 있었다.

 

OOP의 설계 방식과 원칙에 대해 알게 되었다.

 

처음 문제가 주어졌을 때, 객체로 주어졌기 때문에 OOP를 사용하라는 의도로 받아들였었다.

 

하지만, 내가 생각한 것은 아래와 같다.

1. 프로그램의 규모가 크지 않다
2. 코드의 재사용이 필요하지 않다 (각 함수가 독립된 기능을 하며 큰 유사점을 찾을 수 없다)
3. 규모가 크지 않기에 유지 보수에 큰 어려움이 없다 (함수 10개 이하로 구현할 수 있기 때문)
4. 순서가 정해져 있다 (컴퓨터의 숫자 생성 -> 사용자의 입력 -> 맞추면 다시 할 지 그만 할 지...)

위와 같은 이유로 처음에는 그냥 절차지향 프로그래밍으로 (함수를 이용하여) 구현하게 되었다.

 

프로그램을 완성하고 제출하기 전 다시 생각해보니 클래스로 문제를 준 것은 클래스를 활용하라는 뜻인것 같아 코드 리팩토링을 하게 되었다.

 

SOLID 원칙을 준수하기 위해 노력하며 OOP로 프로그램을 재설계하고, 각 클래스로 메소드를 분리하려 했지만 Node.js의 콘솔 입력 함수와 다른 함수들의 비동기 처리로 인해 변수가 undefined가 되는 문제가 발생했다.

 

별도의 모듈 설치가 불가하기 때문에 억지로 구현을 하려 했지만 실패했다.

 

결국, 모든 함수를 App 클래스 안의 메소드로 집어넣었고 this를 이용해 객체 안에서 메소드들의 연쇄 작용이 일어나도록 작성했다.

 

추가적으로 저번 문제에서는 집합을 사용했지만 이번 문제에서는 컴퓨터의 숫자와 사람의 숫자를 비교하는 과정에서 위치에 따른 구분이 있기 때문에 (index의 중요도가 높기 때문에) 리스트를 사용해서 사용자와 컴퓨터의 숫자를 저장 및 비교했다.

 

또 다른 점으로는 Airbnb의 JS 코딩컨벤션을 배우게 되었다.

 

예를 들어, JS의 경우 더블 쿼터와 싱글 쿼터를 사용할 수 있고 세미콜론을 붙이던 붙이지 않던 코드가 작동한다.

 

Airbnb의 컨벤션을 적용하면 싱글쿼터로 통일하고 각 줄의 끝에 세미콜론을 붙이게 된다.

 

기존에 작성하던 방법대로 세미콜론이 누락되는 경우도 있고 싱글 쿼터와 더블 쿼터를 혼합해서 사용할 때 보다 훨씬 코드가 깔끔해졌다.

 

또한, 길어지는 조건문에서 적절한 줄 바꿈 원칙을 지켜 코드를 수정하니 조건을 읽기 훨씬 쉬워졌다.

 

커밋 메시지를 작성하는 방법에 대해서도 배웠다.

 

커밋 메시지 컨벤션 문서를 읽어보고 어떻게 커밋 메시지에 중요한 내용을 담는지, 커밋의 단위는 어떻게 해야 되는지에 대해 배울 수 있었다.

 

마지막으로 Jest를 사용해볼 수 있었다.

 

NestJS를 학습하며 기본으로 Jest가 설치되어 있지만 실제로 사용해본적은 아직 없었다.

 

직접 테스트 코드를 작성하고 원하는 값이 출력되는지 비교할 수 있었다.

 

각 메소드를 기능별로 분리하는 것이 테스트를 하는 과정에서 편리함을 제공한다는 점을 배웠다.

---

💡 아쉬운 점

이번에는 오히려 커밋이 중구난방이었던 것 같다.

 

1주차에는 기능 목록을 너무 세분화 하고 그에 따라 커밋이 너무 많이 발생했다.

 

하지만, 이번주에는 커밋 메시지 형식을 지키고 OOP와 절차지향 방식을 넘나들면서 코드의 수정이 많았고 결국 기능별 커밋을 제대로 하지 못한 것 같다.

 

또한, 아직 OOP를 완벽하게 이해하지 못하고 있기 때문에 OOP 사용을 주저했던 것 같다.

 

추가 학습을 통해 절차지향 프로그래밍이 아닌 객체지향 프로그래밍으로도 구현할 수 있도록 해야겠다는 생각이 들었다.