[우아한테크코스-프리코스] 2주차 경주게임 회고를 해보자🏁

 

 

🔗 나의 Pull Request Link

 

😎 1주차와 비교

---

 

지난 미션에서 공부했던 내용에 대해서 이번 미션에서도 적용을 해보려고 노력을 많이 했다.

1주차때의 경험을 통해 String의 + 기능에 대해서 어떤 방법이 더 효율적인지 비교해보는데 JMH를 사용해보기도 하고 코드를 작성하는데도 더 수월하게 작성할 수 있었던 것 같다.

 

⚠️ 지난 미션을 진행할 때 아쉬웠던 부분이 테스트 코드 작성과 git commit message 관련 부분이었다.

 

이번에 이를 보완하고자 테스트 코드를 작성하는데 시간을 더 많이 사용하고 TDD를 적용해보고자 했다.

처음에는 테스트 코드를 작성하고 이 코드가 정상적으로 동작하도록 실제 코드를 구현하고 이를 리팩토링 하는 식으로 구현을 했다.

하지만, 점점 시간이 지나고 처음 테스트 코드를 작성했을 때 생각지 못한 작은 부분에 대해서 리팩토링이 필요할 때 다시 테스트 코드를 작성하고 이에 대한 코드를 수정하는 과정이 생겼다. 좀 더 요구사항에 대해 분석을 잘 했으면 이런 일이 좀 줄어들었지 않았을까 라는 아쉬움이 있었다.

 

또, 이번에는 commit을 할 때 좀 더 메시지를 작성하는 데 있어서 내용이 드러나고 내가 어떤 의도로 이런 기능을 만들었는지 보여주려고 노력했다. 그렇지만 이번에는 commit한 부분을 보고 나서 너무 자주 commit을 했나? 너무 작은 단위로 commit을 한 것은 아닌지 고민을 하게 되었다.

내가 고민하고 아쉬운 부분에 대해서 더 좋은 방법을 찾아 다음 미션에서는 더 좋은 방식으로 적용해보는 것을 목표로 또 설정해보려고 한다.

 

🤔 고민

---

1️⃣ 클래스별 역할 분리

나는 이번 미션에서 MVC 패턴을 적용해보았다.

• 입출력에 필요한 View
• 자동차 Model
• 자동차 경주를 진행하는 Controller
• 자동차 경주에서 필요한 비지니스 로직을 처리해줄 Service

 

처음에는 자동차 모델에서 한 칸 전진하거나 정지하는 기능을 위해 임의의 숫자를 생성하는 메소드를 자동차 모델에 선언하고 사용했었다. 이렇게 코드를 작성하고 나니 책임이 제대로 나누어져 있는 것 같은 생각이 들었다.

따라서, 임의의 숫자를 만들어줄 Util Class를 따로 생성하고 해당 클래스내에서 임의의 숫자를 생성하는 메서드를 선언하고 이를 사용하는 식으로 리팩토링을 진행했다.

 

리팩토링을 하고 나니 자동차 모델에서는 자동차가 움직이거나 정지하는 기능에 대해서만 책임을 가지게 되었다고 생각한다.

 

2️⃣ 검증은 어디서 이루어져야 하나?

Controller에서 입력이 제대로 들어왔는지 검증을 해야할지? 아니면 다른 Model을 생성하는데 있어서 검증을 또 해주어야 할지 고민을 했었다.

입력된 String이 null인지 Blank인지 확인을 하는 검증 코드가 있는데 문제가 발생하지 않는 상황에서도 검증을 하는 것은 별로 의미가 없다고 생각을 했고 입력된 String을 구분자를 이용해 분리하는 경우나 String을 통해 객체를 생성하는 등 입력된 String이 Null이거나 Blank일 때 문제가 발생하는 경우에 검증을 하도록 했다.

validateInputNameString(inputNameString);
String[] carNames = StringUtil.splitByDelimiter(inputNameString, DELIMITER);

이 고민을 통해 실제 프로젝트에서는 어느 쪽에서 검증을 하고 어떤식으로 검증을 하는지 궁금해졌다.

 

3️⃣ 모든 코드에 대해 테스트 코드를 작성해주어야 하나?

최종 결과에 대해서 검증을 하는 코드뿐 아니라 내부 구현에 대해서 검증을 해주는 테스트 코드가 필요한지에 대해 고민을 했었다.

요구사항은 언제든지 변경될 수 있기 때문에 내부 구현 역시 언제든 바뀔 수 있다고 생각을 하면서 내부 구현에 대한 테스트 코드를 모두 작성한다면 테스트 코드를 수정하는데 더 많은 시간을 보내는 것이 아닐까? 라는 생각을 했었다.

 

이와 관련된 글들을 읽으면서 내 생각이 맞는지 아니면 내부 구현에 대해서 모두 검증을 하는 쪽으로 해야할지 알아보았고 비지니스 기능 단위로 테스트를 하기로 했다.

 

⭐ 4Ls 회고

---

❤️ LIKED

• 지난 미션에 대해 공통 피드백을 받아 이에 대해 다시 생각해보고 공부하며 이를 이번 미션에서 적용해보는 과정이 너무 재미있었다.

 

📖 LEARNED

📍 Mockito

• 테스트 코드를 작성하는 도중 임의로 생성되는 값을 미리 테스트 코드내에서 지정해주고 이를 통해 기능을 테스트하고 싶었다.
• Mockito를 활용해 가짜 객체에 원하는 결과를 Stub하여 단위 테스트를 진행할 수 있다.

📍 Commit Convention

• 전 미션 피드백뿐 아니라 스스로 commit을 하는데 부족함을 느껴 공부를 했다.
• 지난 미션때보다는 내가 커밋을 하려는 코드에 대한 설명을 더 자세히 하려고 노력했다.

 

🗑️ LACKED

• 이번 미션을 제출하고나서 다른 동료들의 회고록과 PR을 보았는데 기능 요구 사항에 대해 다양하게 해석하는 것을 보고 아직 내가 다양한 관점에서 보지 못하고 있다고 느꼈다.
• 예를 들어, 이번 미션에서도 입력된 수 만큼 레이스를 반복하는 기능에서 입력된 수가 1보다 작은 수가 들어오면 문제가 발생할 수 있기 때문에 최소 입력값을 설정한 부분을 보며 요구사항을 분석하고 이를 해석하는데 더 많은 시간을 보낼 필요를 느꼈다 🔥

 

➡️ LONGED FOR

• 지난 미션, 이번 미션에 대한 피드백을 통해 내가 부족한 부분을 찾아가는 과정을 꼭 거치고 이를 개선하고자 노력할 것이다.
• 이번 코드 리뷰에서는 참여하지 못했는데 다른 분들이 코드 리뷰를 하는 것을 보고 남의 코드와 나의 코드를 비교하며 많은 생각을 할 수 있었다. 이번에는 코드 리뷰에 적극적으로 참여해볼 예정이다.