[BE 8기] 우테코 프리코스 2주차 회고

디스코스에서 포비님의 글을 보고 많은 생각을 하게 되었다.

잘할 수 있을까? 잘 모르는 데 어떡하지?라는 걱정만 가득했다. 스스로 잘해야 된다는 생각에만 빠져있었고, 잘하는 사람들과 비교하면서 나의 위치를 판단하고 좌절만 했다.
피드백을 듣고나서 생각을 다시 정리했다. 지금 모르는 것이 당연하다. 내가 모르는 것을 인지하고, 하루하루 채워나가는 것이 도전인 것이다. 완벽하게 해내는 것에 집착하지 않겠다. 새로운 시도를 멈추지 않는 자세로 최종 목적지까지 달려 가보겠다.

그래서 이번 주의 목표는 내가 모르는 것을 확인하고, 배우고, 미션에 적용해보는 시간으로 만들어보려고 한다.

---

2주차 미션: 자동차 경주

---

2주차 미션을 시작하기 전,

1주차 미션 코드 리뷰와 공통 피드백을 보면서 내가 공부해서 적용할 수 있는 내용을 정리해보았다.

1. 큰 함수를 단일 역할을 수행하는 작은 함수로 분리(단일 책임 원칙 준수하기)
2. 테스트 도구 사용하는 방법 배우기
3. 커밋 메시지 의미있게 작성하기
4. 코드 포맷팅 사용하기
5. MVC 패턴 적용하기
6. 상태가 없는 객체에 static 사용하기
7. 요구사항 분석 잘하기

코드 리뷰를 하는 과정에서 많은 동료들이 MVC 패턴을 사용한 것을 파악할 수 있었다. 나의 코드와 비교했을 때 확실히 패키지가 분리되어 있어, 어디서 어떤 기능을 하는지 한 눈에 파악할 수 있어서 좋았다. 그래서 나도 2주차에는 MVC 패턴을 공부하고 적용하기로 마음 먹었다.

---

요구사항을 분석하면서

이번 주에는 요구사항 분석을 잘해야지라는 마음으로 시작했지만 역시나 잘하는 것 자체가 쉽지 않았다.

그래서 요구사항을 어떻게 하면 잘할 수 있을지 고민하다가 커뮤니티에서 기능 요구사항을 기능 단위로 나누는 기준에 대해 토론 보았다. 그래서 나도 요구사항 분석에 대한 기준을 세우는 시간을 가졌다. 1,2주차 미션 과정을 돌아봤을 때 나는 입력 -> 처리 -> 출력흐름 중심으로 기능을 쪼개고, 이후 책임에 따라 객체를 나누는 것이 편했 던 것 같다.

1. 행동 중심으로 나누기
2. 구현 단계에서 '누가 이 일을 맡을까?' 고민하면서 책임 중심으로 전환

처음부터 완벽한 구조를 세우는 것이 좋겠지만, 이렇게 단계적으로 전환하는 게 초보자에게 가장 현실적인 접근인 것 같다. 처음엔 행동으로 시작해도, 리팩토링 단계에서 책임 중심으로 다듬어가는 과정이 결국 객체 지향 설계 연습으로 자연스럽게 이어지는 것 같다.

---

미션을 진행하면서

MVC 패턴 적용하기

코드 리뷰를 하면서 많은 동료들이 MVC 패턴을 사용한 걸 알 수 있었다. 나의 코드와 비교했을 때 확실히 한 눈에 파악하기 좋았다. 그래서 나도 2주차에는 MVC 패턴을 공부하고 적용해보기로 마음 먹었다.

MVC패턴이 정리된 블로그들을 찾아보고, 우테코 제리 선배님의 영상을 참고했다.

https://www.youtube.com/watch?v=ogaXW6KPc8I&t=331s

 

개념적으로 Model은 데이터를 처리를 담당하고, View는 화면 처리 담당, Controller는 View와 Model의 상호작용 담당이라는 사실을 쉽게 이해할 수 있었다. 해당 영상에서 제공하는 기준을 바탕으로 내 코드에 MVC 패턴이 적용되었는지 확인하면서 리팩토링을 반복했다.

1. Model은 Controller와 View에 의존하지 않아야 함
2. View는 Model에만 의존해야 하고, Controller에는 의존하면 안됨
3. View가 Model로부터 데이터를 받을 때, 사용자에게 보여질 데이터에 대해서만 받아야 함
4. Controller는 Model과 View에 의존해도 된다.
5. View가 Model로부터 데이터를 받을 때, 반드시 Controller를 통해서만 받아야 함

하지만 실제로 코드에 적용하려다보니 어떤 코드를 어디에 넣어야 할지 선택하기가 힘들었다. 특히 Controller 영역에 들어갈지, Model에 들어갈지에 대한 기준을 세우기 힘들었다. 예를 들어 "경주를 N번 진행한다"는 반복 로직을 어디에 둬야 할지 애매했다. Controller가 직접 반복문을 돌면서 Model의 메서드를 호출해야 하는지, 아니면 Model에 "N번 진행하라"는 메서드를 만들어야 하는지 헷갈렸다. 이번 주 과제를 수행하면서 Controller는 '무엇을 할지만 결정하기'로 이해하고 적용했다. 즉, Controller는 '입력받기->검증하기->게임진행하기->결과출력하기'와 같은 흐름만 제어하고, 실제로 어떻게 검증하고 어떻게 게임을 진행하는지는 Model이 담당해야 한다는 것을 깨달았다. 하지만 여전히 경계가 명확하지 않아 더 많은 연습이 필요하다고 느꼈다.
그리고 동료들의 1주차 코드를 보면서 service라는 패키지를 보았다. Controller랑 뭐가 다르지?라는 궁금증이 생생겼고, "비즈니스 로직을 담당한다"는 설명을 봤지만 아직 개념을 완전히 이해하지 못해 미션에 적용하지 못했다.
다음 주차에는 Service 계층의 역할과 필요성에 대해 더 공부하고, MVC 패턴 내에서 각 계층이 어떤 책임을 가져야 하는 지 더 명확하게 이해해야겠다고 느꼈다.

Static 메서드 사용 기준

코드 리뷰에서 상태를 가지지 않는 객체에 대해서 static 메서드를 사용하면 좋겠다는 의견이 있었다.
그래서 util 클래스뿐만 아니라 InputView와 OutputView 클래스도 static으로 생성할까?라는 고민을 했다.

고민 끝에 나는 외부 의존성과 확장 가능성을 기준으로 판단하기로 했다. util 클래스처럼 외부 의존성 없이 순수하게 특정 기능 처리만 하는 메서드는 static으로 만드는 것이 적합하다고 생각했다.
InputView와 OutputView는 Console이나 System.out같은 의존성을 가지고 있고, 콘솔 입력이 아닌 파일 입력으로 변경해야 할 수도 있다는 확장 가능성도 고려했다. 따라서 View와 같은 클래스는 인스턴스로 생성했다.

1. 상태를 가지지 않음
2. 외부 의존성이 없음
3. 확장 가능성이 없음

---

마무리하면서

완벽하게 해내는 것보다 새로운 시도를 멈추지 않는 것

이번 주 배우고 시도한 것

1. MVC 패턴 공부 및 적용
2. 일급 컬렉션 공부 및 적용
3. private 생성자 + static 메서드 적용
4. 요구사항 분석 기준 세우기

기준 세우기

1. MVC에서 Controller의 기준
2. 정적 메서드 사용 기준

다음 주에는 더 많은 동료들과 코드 리뷰를 해서 공부할 수 있는 부분을 찾아 볼 것이다. 그리고 MVC 패턴을 더 완벽하게 이해해야겠다.

과제 제출 링크: https://github.com/sinequanonn/java-racingcar-8/tree/sinequanonn

GitHub - sinequanonn/java-racingcar-8

---

**블로그 새로 만들어서 프리코스 기간 때 작성했던 내용을 다시 옮겨 적었습니다.

2주차 회고