[우아한테크코스 6기 백엔드] 프리코스 3주 차 로또 🎰 회고

나도 로또 당첨되고 싶다아아

서론

프리코스 3주 차 미션은 로또였다.

https://github.com/woowacourse-precourse/java-lotto-6

GitHub - woowacourse-precourse/java-lotto-6

https://github.com/woowacourse-precourse/java-lotto-6/pull/240/

[로또] 최원준 미션 제출합니다. by jhon3242 · Pull Request #240 · woowacourse-precourse/java-lotto-6

이번 3주 차는 개인적으로 가장 힘들었던 한 주였다(4주 차는 더 힘들까??😂)
미션 시작날이 하필 자취방 이삿날과 겹쳐서 짐을 싸고 또 이사하느라 이틀 동안 미션을 보지도 못했다.

아무리 바빠도 리뷰는 못참지~

이사도 하지만 리뷰는 참지 못하고 패기 있게 미션 제출 12시가 땡! 하고 지나자마자 댓글을 달아주시면 피드백을 드리겠다고 글을 올렸다.

그리고 열렬한 관심으로 무려 31명의 동료분들이 리뷰 요청 댓글을 달아주셨고 더 이상 받으면 피드백을 못 드리겠다 싶어서 부랴부랴 마감글을 올리게 되었다.

 

그래서 결국 이사 이후에 코드 리뷰를 시작하여 이틀 동안 피드백만 남겼었다 ㅎㅎ

결론적으로 로또 과제는 미션 시작일로부터 4일이 지나고서야 제대로 시작할 수 있었다.

코드 리뷰를 많이 받는 것도 좋지만 미션을 풀 수 있는 시간이 얼마 안 남았다는 사실에 나도 모르게

급하게 코드 리뷰를 마무리한 경우가 종종 있었던 것 같다.

 

이건 코드 리뷰를 안드리는 것 만 못하다는 생각이 들었다.

그분도 시간을 내서 내 코드를 열심히 봐주실 텐데 나는 바쁘다고 대충 봐주면 얼마나 기분이 안 좋을까??😢😢

그래서 3주 차 미션 리뷰는 한분 한분 정성스럽게 리뷰를 남기기 위해 리뷰를 드리겠다는 글을 안 올릴 것 같다.

아니면 미션을 어느 정도 구현한 이후 여유가 있을 때 글을 올릴 것 같다.

어떻게 될지는 아직 잘 모르겠다! 그래도 리뷰는 무조건 할 거다!

 

리뷰를 하면서 정말 많이 배우는 것 같다.

단순히 코딩 관련 지식뿐만 아니라 어떻게 하면 내 의견을 상대방에게 잘 전달할 수 있는지도 배우는 것 같다.

다른 사람들의 댓글을 보면서 "와,, 어떻게 이렇게 말을 이쁘게 잘하실까??"라는 생각을 정말 많이 했던 것 같다.

 

나도 말 잘하고 싶어요ㅠㅠㅠ😭😭

 

아무튼 서론은 이 정도로 하고 3주 차 미션동안 무엇을 고민하고 배웠는지 작성해 보겠다!!

 

😋 TDD 찍먹 찍먹

다른 분들의 2주 차 회고글을 보면서 TDD를 잘 활용하신 것을 보았다.

그래서 나는 이번 3주 차에서는 TDD 를 시도해기로 결심했다!!

어머 이건 TDD가 딱이야!

그리고 3주차 미션을 확인해 보면서 어머 이건 TDD를 활용하기 좋았고 생각했었다.

기본적으로 로또 도메인이 주어졌고 도메인에 대한 기본 테스트도 주어져있었다.

그래서 바로 TDD 를 활용해 보면서 미션을 시작하였다.

 

도메인의 기능을 구현하기 이전에 테스트부터 추가해 보았다.

기능 구현 이전에 테스트부터 작성하니까 확실히 실질적이고 회피하지 않는 테스트를 만들 수 있었다.

명확하게 어떤 입력을 받고 어떤 응답을 해야 하는지 설계할 수 있었다.

그리고 만들었던 테스트를 실행해 보면서 테스트가 실패하는 것을 확인하였다.

(근데 굳이 실패하는지 확인해야 하나?? 안 해도 될 것 같다 ㅎㅎ)

 

그리고 테스트가 통과할 수 있도록 기능을 추가해 주었다.

 

그리고 테스트가 통과했다고 다음 객체로 넘어가는 것이 아니라, 리팩터링 해줘야 한다.

리팩터링까지 마치고 다시 테스트를 통과해야 비로소 TDD 사이클을 완료하는 것이다.

 

😇 기능 구현 완... 료..??

이와 같이 TDD를 적용해 보면서 객체들을 하나씩 구현해 나갔다.

그런데 여기서 문제가 느껴졌다.

기능 구현 목록을 애플리케이션 흐름대로 작성하다 보니 요구사항 목록을 체크해줘야 할지 말지 애매해졌다.

왜냐하면 기능은 구현되어 있지만 입력 기능은 구현하지 않은 상태이기 때문에 기능이 동작하도록 구현되어 있는 것은 아니었다.

그래서 체크해 주기가 뭔가.. 애매했다.

 

😮‍💨 설계부터 하신다고 했잖아요,,

1주 차 미션 회고글에서 명확한 설계 없이 코드 작성해서 피를 봤었다..

그래서 2주 차 미션에서는 설계 이후 코드를 작성하는 것으로 고쳐봤었다.

그러나 인간은 같은 실수를 반복한다..

 

3주 차 미션 구현 시간이 부족하다는 생각에 "TDD를 적용해 보면서 설계하는 거야!"라는 마음으로 패기 있게 코드부터 작성했다.

그러나 결과는 역시 처참했다..

 

객체마다 어떤 인스턴스 변수를 가지고 있을지를 명확하게 설계하지 않다 보니 객체 필드값에 대한 수정이 계속해서 발생했다. 

그리고 새로운 객체의 탄생과 죽음이 여러 번 발생하면서 시간을 낭비하게 되었다.

 

또한 인스턴스 변수를 정하지 못하다 보니 테스트 코드를 작성하기에도 애매해졌다.

그래서 결국 테스트코드는 예외처리에 대한 테스트만 작성하게 되었다..

 

어떻게든 부랴부랴 만들긴 했지만 완성도가 떨어진다는 느낌을 스스로도 많이 받았다..

(코드 리뷰를 통해 혼날 예정..)

 

🧐 3주 차 미션동안 배운 것

아무리 시간이 부족했던 3주 차였지만 그래도 새로운 것에 대해 공부하면서 블로그 포스팅은 했다!!(다행이다..)

매주 하나씩 CS 글을 포스팅하는 스터디에 들어갔기 때문에 반 강제적으로 글을 작성하긴 했어야 했다. ㅎㅎ

아무튼 3주 차 동안 내가 배운 것을 작성해 보겠다!!

 

Enum을 사용해야 할까?

2주 차 미션에 대한 피드백 중에서 상수를 객체로 관리하는 것보다 Enum을 활용해 보면 어떻겠냐는 피드백을 받았었다.

Enum에 대해선 알고 있지만 예외 메시지 출력 시 상수로 관리하는 게 더 편하다고 느껴서 나는 Enum 대신 객체를 통해 관리하는 방법을 고수했었다. 그래도 피드백을 주신 이유가 있다고 생각해서 이번기회에 Enum의 장점에 대해 알아보고 객체로 관리하는 것과 어떤 차이점이 있을지 알아보았다.

 

https://flight-developer-stroy.tistory.com/49

Enum 을 꼭 사용해야 할까??

 

 

toString을 뷰에 맞게 재정의하면 안 되는 이유

또한 피드백 중에서 toString에 대한 피드백도 있었다. 나는 도메인 객체의 toString을 재정의해서 간단하게 출력할 수 있도록 했었다.

그런데 뷰에 맞게 toString을 재정의하면 출력 요구사항이 변경되는 경우 뷰뿐만 아니라 도메인 객체까지 수정해줘야 한다는 것은 어색하다는 피드백이 있었다.(듣고 보니 맞는 말이라고 생각했다.)

 

그래서 toString에 대해서도 알아보고 왜 뷰에 맞게 재정의하면 안 되는지에 대해서도 제대로 알아보았다.

https://flight-developer-stroy.tistory.com/50

toString 을 뷰에 맞게 재정의하면 안되는 이유