[우테코 5기] Level 1 - 자동차 게임 회고

🚩기나긴 여정의 시작

5기 OT가 끝나자마자, 첫 번째 미션이 나왔다.

 

회고 글을 쓰는 시점은 이미 미션을 완료한 지 2주가 지났지만... 여러 가지 준비할 게 많았고, 다른 글 쓸거리도 많이 밀려 있어서 이제야 작성하게 되었다 😅

 

첫 번째 미션은 자동차 게임을 구현하기였고, 페어와 함께 페어 프로그래밍을 진행해야 했다.

 

페어 프로그래밍...?

 

👨‍👦 첫 페어 프로그래밍

페어 프로그래밍이 있는 줄 알았지만 이렇게 빨리 시작되는 줄은 몰랐다 ㅎㅎ

페어가 발표됐다는 소식에 누굴까 두근두근 했고..... 첫 페어는 같은 온보딩 조였던 콩하나다!

 

우리 조는 두 번째 만남에서 모두 말을 놓기로 해서

편하게 대화하는 것에 대한 걱정은 하지 않았다.

미션 설명이 끝나고, 콩하나와 만나서 미션을 어떻게 진행할 건지 이야기했다.

 

우선 콩은 윈도우를 쓰고 있었고 나는 맥을 쓰고 있었다...!

지금은 노트북 2대로도 페어 프로그래밍을 할 수 있다는 것을 알게 되었지만, 저 때 당시에는 몰랐어서 하나의 노트북으로 진행해야 했다.

그래도 나는 오랫동안 윈도우를 썼었고, 맥을 처음 사용하게 되면 키보드와 환경에 모두 새로 적응해야 하기 때문에 콩 노트북으로 진행하기로 했다.

 

한 명은 지시하는 내비게이터, 한 명은 지시하는 것을 그대로 옮기는 드라이버의 역할을 한다.

첫 시작 후 한 시간 정도는 페어 프로그래밍이 적응 안 되고 버벅거렸는데, 나중에는 자연스럽게 진행했다.

오랜만에 윈도우를 쓰다 보니 키가 익숙하지 않아 어리바리 탈 때도 있었는데, 콩이 옆에서 잘 컨트롤해줬다!

 

프리코스때와 마찬가지로 요구사항을 먼저 정리하고..

 

기능 목록을 작성하고..

 

기능 목록에 따라 열심히 구현했다.

 

미션에 관한 이야기든, 잡담이든 쉬지 않고 이야기하면서 진행했다. 서로 코드를 작성하는 스타일이 다른 부분도 있고, 커밋 메시지를 작성하는 방법이나, 프로젝트 구조를 짜는 부분에서도 다른 점이 있었다. 당연히 다른 점이 있을 수밖에 없었다. 몇 년이 되었든, 혼자서만 개발하던 사람들이 모였으니. 그럴 때마다 콩하나가 의견도 잘 내주고, 내가 질문을 할 때는 항상 경청해 줘서 정말 정말 편하게 미션에 임할 수 있었다(1호팬이 되었다).

 

 

 

🚗 고민했던 부분

프리코스 때부터 이어져 온 고민이 첫 번째 미션에서도 똑같이 고민이었다.

 

Q1) 뷰에서 이미 검증된 데이터에 대해, 도메인이 또 검증을 해줘야 하나요?

 

자동차 미션을 처음 구현할 당시에는 뷰에서 객체 멤버의 타입에 맞게 처리한 후 넘겨줬다. 그렇다 보니 검증된 데이터를 또 검증해야 되나? 고민이 계속되었고, 페어와 이야기를 해봐도 딱 뭐가 정답이다라고 내릴 수 없었다. 그래서 PR을 제출하며 리뷰어분께 질문을 드렸고, 다음과 같이 생각의 방향을 정리해 주셨다.

 

view에서 자동차명의 글자 수 등을 이미 검증한 상태에서 Car를 생성할 때 carName에 대한 검증을 또 해야 할까요?

현재와 같은 요구사항에서는 view를 통해서 들어오는 경우밖에 없기 때문에, view에서만 검증해도 된다고 생각할 수 있어요.

하지만 carName이 변경될 수 있는 또 다른 진입점이 존재하게 된다면, 어떨까요?

 

그렇다. 도메인이 뷰에서 넘어온 입력된 값에 의해서만 생성될 수 있는 것이 아니고, 애플리케이션 곳곳에서 생성될 수 있는 여지가 충분하다.  그러므로 도메인도 자신의 멤버에 대해 검증할 책임이 있는 것이다. 이후 미션부터는 뷰는 입력 값에 대한 검증만, 도메인은 해당 값의 비즈니스 로직과 관련된 검증을 하도록 책임을 나눴다. 리뷰어분과 함께 이야기를 나눠보며 검증에 대한 기준을 명확히 세울 수 있었다.

 

 

 

 

Q2) 예외 메세지를 따로 관리하는 방법이 있으신가요? 현업에서 어떻게 관리하는지 궁금합니다 !

 

미션을 진행하며 코드 곳곳에 흩어져있는 예외 메세지가 거슬렸다. 분명 여러 곳에서 중복해서 사용되는 메세지도 있고, 한 도메인에서만 사용되는 메세지도 있는데 다 흩어져 있는 게 뭔가 불..편한 기분이 들었다. 그래서 콩하나와 예외 메세지를 한 곳에서 관리할 수 있도록 enum 객체로 분리했다.

 

Enum 객체로 분리했을 때 얻을 수 있었던 장점은, 예외 메세지에 관한 요구사항이 변경되었을 때 유지 보수하기 편하다는 점이 있었다. 그러나 어떤 도메인에서 정확히 사용되는지 한눈에 파악하기는 힘들다는 단점도 존재했다. 도메인 내부에 예외 메세지가 있는 경우에는 바로 어떤 도메인에서 사용하는지 알 수 있기 때문이다.

 

마찬가지로 리뷰어분께 질문을 드렸고 돌아온 답변은..

 

우선 회사마다 다 달라서 한 가지 답변을 드리긴 어려울 것 같아 여러 가지 답변을 드려볼게요. 그레이가 생각해 보시고 가장 좋다고 여겨지는 방법으로 적용하시면 될 것 같아요.

 

1. ErrorMessage라는 이넘 타입을 활용하게 된다면 에러 메시지와 관련된 변경이 필요할 땐 ErrorMessage 객체에서 확인할 수 있다는 것이 명확해지기 때문에, 관리하기에 좋을 수 있어요.

 

2. 다른 경우로 저는 가끔 ErrorMessage는 Exception 객체에서 지정해서 사용할 때도 있어요. 보통 메시지와 Exception 클래스를 1:1로 두는 경우가 잦을 때 주로 사용해요. 아래와 같은 간단한 예시 남겨드릴게요.

public class CarNotFoundException extends RuntimeException {
	public CarNotFoundException(String id) {
		super("car with " + id + " is not found.")
	}
}

 

역시나 정해진 정답은 없었고 새로운 방법인 Exception 객체를 지정해서 사용하는 방법을 배울 수 있었다. 계속 경험을 쌓아가고 깨지면서 배우다 보면 스스로의 명확한 기준을 세울 수 있지 않을까 싶다.

 

 

 

Q3) 객체의 toString에 원하는 메세지를 출력해도 될까요?

 

페어와 미션을 진행하며 아무 생각없이 Car 객체의 toString에 결과를 보여주도록 설계했다. 코드를 작성할 당시에는 크게 신경쓰지 않았지만 PR을 제출하고 다음 단계를 진행하려고 보니 이게 맞나? 싶었고 toString을 이용해 출력하자고 제안했던 내가 뜨끔했다. 왜냐하면 뷰의 요구사항이 변경되면 도메인까지 수정해야하는 상황이 발생하기 때문이다. 개선해야할 사항이라는 점을 바로 인지했고, 1단계 리뷰에서 toString에 대해 리뷰어분이 별다른 말씀이 없으셔서 2단계 리뷰때 질문을 드렸다.

 

결론적으로 우려했던 점이 맞았다 !

조앤이 toString을 제대로 사용하는 방법에 대해 알려주셨고, 미션이 끝나자 마자 바로 공부하고 기록으로 남겼다. 크루들과 함께 이펙티브 자바 스터디를 하고 있는데 마침 이펙티브 자바에도 toString에 관련한 내용이 있어 스터디때 해당 내용을 소개하며 마무리했다.

 

toString을 재정의하라 보러가기

 

 

🙇🏻 마치며

1주일이라는 기간 동안 정말 많은 것을 느낄 수 있었다. 첫날부터 미션이 나왔고, 그다음 주에는 연극을 해야 돼서 정말 정신없는 시간을 보냈던 것 같다. 특히 연극은 평생 잊지 못할 기억으로 남을 것 같다 ! 연극을 준비하라는 소식을 들었을 때는 왜 해야 되지?라는 생각이 가득했는데, 같이 연습하고 대본을 짜면서 호흡을 맞춰가다 보니 어느샌가 재미를 느끼고 즐기고 있었다. 다 우리 조원들 덕분이 아닌가 싶다 ㅎ

 

발표 당일, 연습할 때는 그렇게 긴장되지 않았는데 막상 우리 차례가 오니 긴장이 슬슬 됐고 내 차례가 시작되는 순간부터는 기억이 없다. 정말로 기억이 없다 ㅋㅋㅋ 정신 차려보니 연극이 끝났었고 마무리 인사를 하고 있었다..!

온보딩 조원들과 연극을 하면서도 많이 배웠고, 페어였던 콩하나와 미션을 진행하면서도 많이 배울 수 있었다. 앞으로 10개월간 지내며 다양한 상황을 마주하게 될 텐데

함께 소통하는 방법을 계속해서 배워가고, 그 속에서 개발적인 측면뿐만 아니라 사람 대 사람으로서 많은 것을 느끼고 성장할 수 있도록 노력해야 할 것 같다.