[우아한테크코스] 5기 백엔드 3주차 프리코스 회고록

- 벌써 3주차가 끝났다. 사실 끝난 지 이틀 됐는데 정신 없어서 이제 회고록을 작성한다...

 

| 2주차 회고록

[우아한테크코스] 5기 백엔드 2주차 프리코스 회고록

 

| 3주차 코드

GitHub - Cl8D/java-lotto: 로또 미션을 진행하는 저장소

 

---

| 3주차 커밋 기록 살펴보기

- 사실 이번 주차도 커밋을 그렇게 많이 하려고 하지 않았다. 제한 시간 내에 풀어보는 게 목표였기 때문에...

- 하지만 어림도 없었다. 3주차 커밋은 78개가 되어버렸다...

그래도 영어로 커밋하는 게 꽤 익숙해진 느낌이다. 자연스럽게 내가 뭘 써야 될지 작성되는 기분...? (근데 여전히 파파고 못 놓는다)

그리고 커밋 컨벤션도 손에 완전히 익어서 이제 더 안 찾아보고 하고 있다. 좋은 습관을 가져간 것 같아서 좋다.

- 최종 시험을 앞두고 5시간 내에 풀어보려고 스톱워치까지 굴렸는데 거의 9시간이 걸렸다. 나중에 5시간 내에 이거 구현을 할 수 있을까 싶다.

물론 이것도... 프리코스를 붙어야 하는 말이지만... 잘할 자신 있는데........

---

| 기능 명세서 작성하기

- 저번 주 회고에서 다음 주차에 꼭 지키고 싶어 했던 부분 중 하나이다. 먼저 1차적으로 개발을 진행하지 않고, 명세서부터 작성하는 것.

그래서 이번 주차 과제에서 명세서 짜는 부분만 1시간 30분은 쓴 것 같다. 

요구 사항 하나하나 다 보면서 기능 분리를 했는데, 한 가지 아쉬운 건 처음부터 너무 모든 걸 챙기려고 했던 점이다.

아무리 잘 작성해도 코드를 짜다 보면 수정할 부분이 나올 수밖에 없기 때문에... 😥 다음부터는 30분 정도로 짧게 가져가볼까 한다.

살아있는 문서를 만들라는 2주차 피드백을 다음 주차에서는 꼭... 지켜보자.

 

- 그래도 뿌듯한 건 하나 구현할 때마다 ☑️ 표시하면서 진행한 점이다. 그리고 각 기능마다 메서드명도 함께 달아두었다.

이렇게 하니까 나중에 기능 명세서에서 메서드 찾아가기도 편하고, 내가 뭘 구현한지 확실히 알 수 있어서 편했다. 특히 테스트 코드 짤 때 매우 굿!

 

- 지금 와서 생각해보니까, 예외 사항에서 보너스 번호 입력 시 당첨 번호와 동일한 번호가 들어오는지도 체크했어야 했는데... 이 부분은 생각 못 했다.

그리고 당첨 금액을 long으로 처리하긴 했지만, 그 이상의 범위가 들어왔을 때 어떻게 처리할 것인지... 이런 것도 고민했어야 됐는데!!! 아쉽다 ㅠㅠ

문제를 보고 어떤 제한 사항이 발생하는지에 대해서 따져보는 것도 정말 중요한 습관인 것 같다. 

다음 주차에서는 조금 더 확실하게 따져봐야 할 것 같다... ㅠㅠ

 

---

| 도메인 구조?

- 이번 주차에서 가장 많이 고민했던 부분인 것 같다. DDD는 말로만 들어보고 습관처럼 entity / repository / service 나누는 게 다였는데 이번 주차 과제에서 작정하고 짜려고 하니까 머리가 굉장히 아팠다.

- 사실 그래서 MVC 구조로 설계를 진행해야 되나 싶었는데, 실제 시험 시간이라고 생각하니까 차마 손이 잘 안 떨어졌다. 다음 주차에는 한 번 시도해볼지 고민이다. 오히려 너무 구조를 복잡하게 만드는 것 같아서 여전히 고민이지만...

 

- 패키지 구조는 이렇게 짰다. 한 가지 달라진 점은 상수를 enum으로 관리한 것!

 

- 그리고 도메인을 크게 5가지로 나누었다.

- 로또 (주어진 클래스, 로또 번호에 대한 클래스)

- 로또 당첨 관리 (LottoPrize) -> 당첨 통계를 위한 기능을 담당한다.

- 로또 구매 (LottoPurchase) -> 사용자가 구매한 로또 정보를 관리한다.

- 로또 결과 (LottoResult) -> 사실 서브 클래스로 쓰여도 된다. 로또 당첨 통계를 나타낼 때 용이하게 관리하려고 사용하였다.

서브 클래스로 쓰이면 해당 클래스에 대해서 테스트 시 어떻게 접근해야 될지 모르겠어서 (private라고 가정) 그냥 저런 식으로 뺐다... 

- 로또 당첨 번호 (LottoWinningNumber) -> 당첨 번호와 보너스 번호에 대해서 관리한다. 지금 생각해보면 둘을 나누는 게 더 낫지 않았을까 싶다... 

당첨 번호는 기존의 Lotto 클래스를 상속받는 식으로 했어도 됐을 것 같은데 아쉽다. 왜 이런 건 회고하면 보이는 걸까...

 

- 구현한 것 중에 뿌듯했던 거! 

- 메시지 관리할 때 어떻게 하면 동적으로 값을 넣어줄 수 있을까 고민하다가... 잊고 있던 %d %s를 알차게 써주었다.

- 특히 소숫점 둘째 자리에서 반올림 후 출력할 때 %.1f로 출력해줄 수 있었어서 더 깔끔했던 것 같다.

 

- 지금 와서 좀 아쉬운 것 중 하나. 에러 메시지는 그대로 상수 클래스를 사용하였다.

enum 타입의 값을 넣어줬어야 했는데, 이런 식으로 string concat 방식이 더 낫다고 생각했기 때문이다... enum에서 동적으로 설정할 수 있나?

당시 코드 짤 때는 enum의 value 값으로 저렇게 합친 값을 넣어주려고 했는데 enum은 사실 상수이기 때문에 변경될 수 없는 값이어서 그런 식으로 합쳐주는 게 안 됐다. (이 이유가 확실한지는 모르겠지만 당시 구현할 때는 그렇게 생각했다)

 

- 이렇게 안 하려면 %s 같은 걸로 바깥에서 동적으로 넣어주든지 하는 게 낫겠지만... 사실 고정된 값인데 굳이 그럴 필요가 있을까? 싶었다.

이게 옳은 선택인지는 모르겠지만 아무튼 뭔가 찝찝한 느낌... ㅠ

 

- 테스트 코드 짤 때 발견했던 부분 중 하나이다. List.of으로 인자를 넣어주기 때문에 오름차순 정렬을 할 수 없던 것...

그래서 그냥 저렇게 새로운 리스트를 할당해서 넣어주었다. 보통 코테 문제 풀 때 배열을 많이 사용해서 리스트 정렬 방식이 살짝 헷갈렸는데 저런 식으로 바로 sort를 이용해서 처리해줄 수 있는 게 신기했다. 

- 그리고 로또 번호 출력해줄 때 ","로 나누어서 출력했어야 했는데, 지금 생각해보니까 출력할 때 저런 식으로 구분해서 나눠주는 게 자바에 있었던 것 같은데 왜 사용 안 했지... 의문이다. 이건 한 번 찾아봐야겠다.

 

- 피드백 보고 뜨끔했던 부분 중 하나이다. 주어진 로또 클래스를 잘 사용하지 못했다는 점이다.

- 이런 식으로 getter로 받아와서 외부에서 처리하는 게 좋지 않다는 사실을 알고 있었지만... 커스텀으로 도메인 객체들을 생성하다 보니까 문득 Lotto 클래스를 잘 사용하지 않았다는 점을 뒤늦게 깨달았다. 다음에는 로또 번호에 대한 매치 카운트 계산하는 부분 같은 건 로또 클래스 내부에 구현해야겠다...

 

<LottoPrize#getMatchCount>

- 회고하다가 본 코드인데 스트림을 어떻게든 쓰고 싶어서 만들어낸 이상한 코드이다.

count()의 경우 long 값을 반환하기 때문에 int로 변환하고 싶어서 wrapper 사용하고... 다시 intValue()로 빼내었다.

이럴 거면 그냥 반복문 돌면서 처리하는 게 더 나았을까? 싶기도 하지만.... 당시에는 엄청 고민한 결과였다... ㅎㅎㅎ

---

| 테스트 코드로 삽질하기

- 그리고 대망의 메인 코드...! 사실 이번 주차 과제가 오래 걸렸던 것도 이 때문이 크다... 

'예외 테스트를 assertThat으로 가능하다고? assertThatThrownBy가 아니라...?'

 

- 나를 정말 힘들게 했던 친구... 여기서 분명 NoSuchElementException으로 잡는데 문제의 요구사항은 IllegalArgumentException으로 잡는 것이다!

그래서 예외 사항이 발생하면 테스트 코드가 정상적으로 실행되지 않는 문제를 발견해버렸다...

처음에는 코드 오류인 줄 알고 너무 이해가 안 되어서 우테코에 문의까지 넣어봐야 하나...? 싶었는데 그냥 내가 잘못된 거였다...

 

사실 생각을 전환해보면 간단하다. 테스트 코드가 실패한 이유 = 예외가 던져져서.

예외가 던져진다 = 어딘가에서 처리되지 않고 계속 전파되어서 시스템 종료 시점까지 계속 던져진 것. 

= 그렇다면 예외를 잡아서 시스템이 정상 종료되도록 하자!

 

- 그래서 처음에는 try catch문을 그냥 여기다가 바로 박았다. (지금은 수정해서 저렇지만)

- 근데 이렇게 되면 테스트는 정상 통과하지만... 이 이후 로직이 실행이 된다는 점이다. catch로 잡고 시스템을 종료시켜줘야 하는데 System.exit를 사용할 수 없기 때문이었다. 그리고 콘솔 출력도 사실 System.out으로 직접 하는 사태까지 벌어졌다. 저기 내부에 넣어놓고. ㅋㅋㅋㅋ

 

'예외를 발생시키고, 메시지를 출력하고, 정상 종료시켜라' << 이 말이 진짜 이해가 안 되기 시작했다.

아니... 예외가 발생하면 프로그램이 종료되는데 어떻게 정상 종료를...?

 

- 그래서... 또 다시 삽질을 했다!!!! 디버깅 하나씩 찍어보면서..... ㅠ

- 결과적으로 나온 코드! 아마 요구사항도 이런 게 아니었을까 싶다.

getPurchaseInfo() -> 여기서 사용자의 입력 받고, 검증 로직을 타면서 1000j가 들어오면 예외가 발생했을 것이다.

예외는 계속 타고타고 올라올 것이고, 메인 로직까지 왔을 때 try-catch에 의해서 예외는 잡히게 된다.

그럼 여기서 출력을 해주면 된다! 예외에 담았던 걸 e.getMessage()로 꺼내주고, 예외 처리 후 정상 종료까지 가능하게 된다.

 

이렇게 되면 예외 발생 > 메시지 출력 > 정상 종료 이 로직을 완벽하게 만족하게 된다.

이번 주차 과제에서 엄청 삽질했던 부분인데 잘 처리한 것 같아서 뿌듯했다...ㅎㅎ

앞으로 예외 처리는 진짜 꼭 이런 식으로 해야겠다고 다짐했다...

 

---

| 단위 테스트와 통합 테스트

 - 저번 주차에서 테스트 코드를 너무 신경쓰지 못했던 것 같아서 이번 주차는 테스트 코드를 여러 개 짰다.

특히, private로 구현된 거에 대해 단위 테스트 > public으로 접근할 수 있는 것에 대해 통합 테스트를 진행하였는데

다 구현하고 나서 알아보니까 private 메서드는 테스트 안 하는 게 맞다고 한다... ㅠ

왜냐면 private는 단독으로 어차피 실행되지 않을 것이니까, public을 통해서 처리하는 게 맞다고 한다.

 

- 지금 이 리플렉션의 향연을 보고 있으니 다시 이렇게 하면 안 되겠다는 생각이 몰려온다.. ㅎㅎ

- 다음 주차에서는 케이스를 다양하게 해서 public 메서드에 대해서만 해야겠다...!

그래도 리플렉션에 대해서 공부해볼 수 있어서 좋은 시간이었다.

 

- 이건 그냥 보너스로... 당첨 번호 케이스를 진짜 엄청 고민하면서 짰었는데 다 통과되고 나서 엄청 뿌듯했다. ㅋㅋㅋㅋ

- 하나의 테스트에 저렇게 여러 개의 assertThat 있는 게 별로라고 생각했는데, 이번 주 슬랙 확인하니까 어떤 분이 .as를 사용하면 좋다고 하셔서 다음 주차에는 as를 통해 description을 작성해보고자 한다. 

- 그리고 테스트 어노테이션이 되게 다양하던데, 다음 주차에서는 그 부분도 최대한 활용해봐야겠다! 특히 command() 메서드 재활용 대신에 @ValueSource와 @ParameterizedTest를 활용해서 해야겠다... 테스트 코드에 대한 중복도 없애는 게 중요하니까!

 

험난했던 3주차... 4주차 미션 엄청 어렵던데 벌써 긴장된다... ㅠ

특히 3주차 피드백은 너무 배운 점이 많아서 4주차 열심히 달려보려고 한다. 마지막까지 파이팅 ㅠ_ㅠ...!!!