[우아한테크코스 8기] 프리코스 2주차 회고

🎯 목표설정 & 다짐

내가 설정한 2주 차 목표는 "매일 매일을 기록하기"다.

 

1주 차가 끝나고 가장 먼저 느낀 건 소감문과 회고록 작성이 생각보다 어렵다는 것이다.과제를 수행 중 했던 고민과 깨달음이 막상 회고록을 작성할 때 생각이 안 나서 1주 차 회고록을 어렵게 작성했다.그래서 2주 차 시작 전에는 내가 매일 공부한 것, 고민한 것, 배운 것들을 조금씩 기록하기로 다짐했다. 

 

현재 2주차 끝에서 회고록을 작성하면서 매일의 기록을 살펴보니 일주일 동안 많이 고민하고 배우고 성장했다는 사실이 느껴진다.

 

천천히 가고 있다고 생각했는데 어느 순간 뒤돌아보니 많이 걸어왔구나.

 

💎  새로운 도전 : 오프라인 스터디(판교 상륙작전 스터디) 후기

보석 같은 경험이었다.

이렇게 과제 내용보다 먼저 스터디 경험을 전달하는 것은 그만큼 값진 경험이었기 때문이다.
스터디 개설 목적은 아래와 같다.
  1. 5주라는 긴 시간 동안 지치지 않게 서로 책임감 부여
  2. 스터디원들과 피드백을 통한 메타인지
  3. 오프라인으로 퀄리티 높은 코드 리뷰

[💎 5주라는 긴 시간동안 지치지 않게 서로 책임감 부여]
5주라는 시간은 생각보다 길다(심지어 작년 프리코스 기간보다 1주가 늘었다!). 매일 많은 시간을 프리코스에 몰입하기에는 지칠 거 같았다. 커뮤니티가 있다고 하지만 분명히 초반에 활활 타오르는 열정이 식을 것이라고 생각했다. 그래서 스터디원들과 매주 오프라인으로 만나 대화하고 서로 좋은 자극을 받으면 책임감도 생기고 5주라는 긴 기간 동안 성실하게 몰입할 수 있을 것이라 생각했다.

[💎 스터디원들과 피드백을 통한 메타인지]
글로 코드리뷰를 하는 건 한계가 있다고 생각했다. 서로 질문과 답변을 하면서 스스로 알고 있다고 착각한 것을 깨닫는 메타인지의 기회를 얻을 수 있다 생각했다.

[💎 오프라인으로 퀄리티 높은 코드 리뷰]
직접 얼굴을 마주 보고 코드리뷰를 하는 것은 생각보다 부담이 막중하다. 그래서 질문자는 질문하기 전에 더 고민해 볼 것이고 답변자도 자기 생각과 의도를 말로 표현해 봄으로써 서로에게 도움이 되는 퀄리티 높은 코드 리뷰가 가능할 것이라고 생각했다.

판교 상륙작전 스터디 1회차

 

[❄️ IceBreaking]
서론이 너무 길었다ㅎㅎ
스터디는 총 5명으로 진행했고 5시간 정도 걸렸다(인천 송도 10.25.(토) 13:00 ~ 18:00)
본격적인 1주차 과제에 대한 코드리뷰 전에 내가 준비한 간단한 IceBreaking을 통해 서로 긴장감을 없앨 수 있었다. IceBreaking중 인상적이 었던건 스터지원 5명중 MBTI가 나만 FJ고 나머지는 다 TP였다.(개발자는 T가 많나??🤔)
계속해서 서로에 대해 알아가면서 우테코에 얼마나 진심인지?, 개발 공부 어떻게 하고 있는지?, 프리코스 관련 꿀팁 등등 많은 대화를 나누면서 긴장감을 풀 수 있었다. 제목에서 스포했지만, 스터디원이 "판교 상륙작전 스터디"라는 이름을 추천해줘서(아주맘에 든다😘) 더 재미있었다. 우리가 인천 지역 스터디여서 아주 센스있는 이름이라고 생각한다.

[👨‍💻 본격적인 오프라인 코드리뷰]
생각보다 내 코드를 말로 설명하는게 어려웠다. 스터디원들에게 내 설계 구조, 코드의 근거를 설명하는게 어려웠다. 심지어 말로 설명하는데 머리가 하얘져서 식은땀을 많이 흘렸다. 나만 이렇게 느낀게 아니고 스터디원 전원이 같은 경험을 공감했다. 심지어 내가 알고 있다고 생각했는데 말로 설명하려니까 못하는것들이 대부분이었다😂. 이것이 메타인지인가? 싶을 정도로 생각보다 내가 알고 있다고 착각한것들이 많아서 당황스러웠다. 그래도 결과적으로 빨리 이 것을 알게 되어서 정말 귀중한 경험이라고 생각한다. 다음주에는 내 코드를 설명하는 연습을 한번 하고 스터디에 참가해야 겠다고 생각했다.

[🗓️ 다음주 스터디 계획은?]
오프라인 코드 리뷰 종료 후 스터디원과 다음주 목표에 대해서 이야기를 했다. 상호 온라인 코드 리뷰를 사전에 진행하고 오프라인 스터디 시 구체적으로 설명해주기로 했다. 매일 일일 회고록 작성 후 스터디 노션방에 공유하여 서로에게 자극이 되도록 했다. 매일 일기를 쓰고 공유하는 느낌이다. 다음 주에는 서로 2주 차에 목표했던 것들을 잘 지켰는지 확인하고 어떤 배움을 얻었는지 이야기 나눌 예정이다.

 

🛠️ 온라인 코드 리뷰 후기

생각보다 시간이 오래 걸린다. 매 주차 과제에 대해서 10명의 코드 리뷰를 하자고 마음먹었는데 막상 코드리뷰를 해보니 1명당 30분~40분씩 걸렸다. 눈이 피곤해서 인공눈물을 넣어가며 목표한 10명에 대해서 리뷰를 완료했다. 코드 리뷰를 하고 나서 깨달은 점은 아래와 같다.
 1. 같은 입력, 같은 출력이어도 코드 구성과 로직은 정말 다양하다.
 2. 개개인 별로 코드가 이렇게 다른데, 협업을 위해서라면 코드 컨벤션이 정말 중요할 거 같다.
 3. 다른 사람의 코드를 읽는 게 생각보다 도움이 많이 된다.

1주 차 과제를 하면서 배운 점 보다 코드 리뷰를 통해 배운 점이 더 많다고 생각한다. 왜 이렇게 작성했는지, 근거가 뭔지, 의도가 뭔지 질문하고 답하는 과정에서 더 깊이 생각할 수 있었고 메타인지의 기회가 되었다. 특히 같은 역할을 하는 간단한 함수인데 서로 다른 생각 서로 다른 근거가 있어서 토론하는 재미가 있었다. 앞으로도 과제별로 최소 10명씩 코드 리뷰할 예정이다.
(+ 제 코드 리뷰해 주신 8명에 대해서 감사를 표합니다!)

제 코드를 리뷰 해주신 고마운 분들👍

🗒️ 2주차 과제 진행 과정

우아한테크코스 8기 프리코스 2주차 과제 링크

[자동차 경주] 최형석 미션 제출합니다. by GamzaCoding · Pull Request #118 · woowacourse-precourse/java-racingcar

 

과제 진행 흐름은 1주차와 같아서 생략하고 중요한 점 위주로 설명하겠다.

 

🥕 2주차 학습 목표 달성

과제 진행 전에 2주 차 학습 목표 달성을 위해 집중했다.
[2주차 학습 목표]
  1. 여러 역할을 하는 함수를 한 가지 기능만 하도록 작은 함수로 분리하기.
  2. 테스트 도구를 사용하는 법을 배우고 프로그램이 제대로 작동하는지 테스트하기.
  3. 1주 차 공통 피드백을 최대한 반영하기.

if() 조건절도 함수로 분리할 수 있다 판단했고 isXxx() 형식으로 한 가지 기능만 하는 함수로 분리하려고 노력했다.
2주차 과제부터는 단위 테스트를 작성했다. 일반 기능을 테스트하는 데 어려울게 없었지만 Random값 테스트를 작성할 때 굉장히 고생했다.(자세한 과정은 뒤에서 설명하겠다.) git commit시 scope를 명시하고 커밋 본문을 작성하여 이 커밋에서 수행한 작업을 이해할 수 있도록 했다.

 

🥕 과제 수행하면서 느낀 점 & 배운 점

1. Service 계층이 필요한 이유

2. DTO를 사용하는 이유

3. Validation 계층이 필요한 이유

4. 원시 값 포장에 대한 고민

5. static 주의해서 사용하기

6. 랜덤값 테스트를 위한 전략패턴 도입

 

🍅 Service 계층이 필요한 이유

지난 과제에서는 model의 로직이 많지 않아 controller에서 직접 model의 메서드를 호출해 view와의 흐름을 제어했다. 하지만 자동차 경주 과제에서는 controller에서 model의 메서드를 직접 호출하니 controller의 run() 메서드가 너무 비대해졌고 복잡해졌다.
그래서 Service 계층의 필요성을 느꼈고. 비즈니스 로직들을 service 계층을 통해 캡슐화했다.

 

🍅 DTO를 사용하는 이유

계층 간 데이터 전달을 위해 원시 타입(primitive type)을 사용하다 보니 변환 메서드(StringToList 등등)가 계속 사용되는 것을 확인 할 수 있었다. 변환 로직은 메인 비즈니스 로직이 아니고 오히려 코드를 이해하는 데 방해가 되는 부분이었다. 그래서 원시 타입 대신 객체 그 자체를 전달하는 방법을 도입했다. 하지만 Car 같은 model을 직접 전달하자니 출력에 필요한 부분뿐만 아니라 Car의 내부 메서드가 외부로 노출되는 문제가 발생했다. 그래서 DTO를 통해 출력에 필요한 부분만 전달하도록 했다. 특히 DTO를 통해서 record라는 불변 객체를 공부할 수 있었고 불변 객체로 설정해야 데이터 전송 중 신뢰성을 확보할 수 있다는 것을 알았다.

 

🍅 Validation 계층이 필요한 이유

지난 과제에서는 inputView에서 검증을 전부 담당하도록 해서 따로 검증 계층의 필요성을 느끼지 못했다. 하지만 이번 과제를 진행하다 보니 view와 model에 전부 검증이 필요했다. 처음에는 각 객체 내부에 검증 로직이 있었지만 리팩터링 과정에서 흩어져 있는 검증 로직을 캡슐화하는 것이 더 가독성 있는 코드라 판단했고 Validation 계층을 만들었다.

 

🍅 원시 값 포장에 대한 고민

Car 객체는 내부에 name과 position이라는 값을 가지고 있다. 이 중 name만 원시값 포장했고 position은 원시값을 그대로 사용했다. name을 원시값 포장한 이유는 "자동차 이름은 5글자 미만만 가능하다"라는 조건에 대한 검증 책임이 name에 있다고 판단했기 때문이다. position은 이 값이 책임을 가져야 할 로직이나 검증이 없다고 판단해 원시값을 그대로 사용했다. 물론 여기도 정답은 없다고 생각한다. 추후 필요성이 있다면 그때 가서 리팩터링하면 된다고 생각한다. 다른 크루원 코드 리뷰를 통해 다양한 의견을 듣고 싶다.

 

🍅 static 주의해서 사용하기

static은 GC의 영향 밖에 있어 메모리 부족의 원인이 될 수 있다는 것을 배웠다. 자바 메모리 구조(Static, heap, Stack)에서 객체는 GC가 관리해 주지만 static은 프로그램이 끝날때 까지 메모리를 계속 차지하기 때문에 무분별한 static의 사용은 메모리 부족의 원인이 될 수 있다는 것을 배울 수 있었다. 객체들 사이의 메시지를 주고받아 프로그램을 구성하는 객체지향의 원리와도 맞지 않다는 것을 알 수 있었다. 그래서 이번 과제에서는 validation을 제외하면 static을 사용하지 않도록 설계했다.(스터디원이 알려줬다 🤗)

 

🍅 랜덤값 테스트를 위한 전략패턴 도입

이번 과제에서 가장 어려웠던 부분이다. car의 이동은 Random 메서드가 호출될 때마다 나오는 랜덤한 값에 의존한다. 결과적으로 항상 통과하는 테스트는 작성할 수 없다. 처음에는 외부에서 값을 주입하는 형식으로 메서드 시그니처를 변경할지 고민했지만 결국 테스트를 위한 비즈니스 로직의 변경이어서 좋은 방법이 아니라고 생각했다. 그렇게 방법을 찾아보던 중 전략 패턴을 떠올릴 수 있었다. 랜덤한 값이 문제인 거면 랜덤값과 정적인 값 두 전략에 대해서 유연하게 해결할 수 있는 전략 패턴이면 되겠다고 생각했다. 이 방법은 테스트만을 위한 비즈니스 로직 변경이 아니다. 나중에 다른 조건으로 Car의 이동방법이 변경되더라도 유연하게 대응할 수 있는 확장성 있는 방법이라고 생각했다. 그렇게 MoveStrategy를 도입했고 테스트 코드도 전략패턴을 통해 일관적인 테스트가 가능할 수 있었다.(쫌 더 좋은 방법이 있는지는 코드리뷰를 해보면서 살펴봐야 겠다.)

 

💡2주 차 진행 소감

정말 바쁘다. 아침에 눈 뜨고 눈 감을 때까지 프리코스에 몰입하고있다. 과제를 제외하고도 코드 리뷰, 스터디 준비, 개발 공부, 운동 등 매일 할 일이 넘쳐난다.

매일 성장하고 있다고 느낀다. 다음날 내가 작성 완료한 코드를 보면 리팩터링할 부분이 보인다. 처음에는 내가 꼼꼼하지 못했다고 생각했는데 매일 이런 것이 반복되니 "혹시 내가 매일 성장한 게 아닐까?"라는 생각이 든다.(초긍정적 마인드)

코드 리뷰는 정말 소중한 기회이다. 생각보다 시간이 오래 걸리는 일이고 힘든 일이다. 나중에 현업에 가면 이렇게 정성스럽게 코드 리뷰 해주는 분들을 만나기 힘들거라고 생각한다. 그렇기에 프리코스 기간에 최대한 많은 코드 리뷰를 통해 부족한 부분을 배우고 성장하는 기회로 만들자

스터디를 모집하기 정말 잘한거 같다.(나 자신 칭찬해👍) 역시 사람은 만나서 눈을 보고 이야기 해야 활력이 생기는거 같다.

벌써 2주차도 이렇게 끝나간다. 3주차에는 어떤 성장과 경험 그리고 도전이 나를 기다리고 있을까? 화이팅 하자!!