[🚀 사이클2 - 미션 (블랙잭 게임 실행)] 테리 미션 제출합니다.

[Yeji-Kim-Erica]

💌 인사말

안녕하세요, PK! 리뷰이 테리입니다.

우선 지난 PR 때의 상세한 코멘트들에 대해 감사드린다는 말씀을 드리고 싶습니다!

지난 사이클에서 주셨던 피드백과 도전 목표가 많은 도움이 되었습니다.

1. 최대한 적은 범위의 코드 변경을 통해 기능 추가 해보기
2. 테스트 커버리지를 높이기

우선 제가 생각하기에 많이 발전한 부분부터 말씀을 드려볼까 해요.
2번 항목을 어떻게 하면 잘 수행할 수 있을지 고민해봤는데,
README의 기능 목록 문서를 꼼꼼히 작성하는 것이 가장 우선적으로 행해져야 한다는 생각이 들었습니다.
첫번째 PR 당시, 클래스 구조 위주의 기능 목록을 base로 작성을 시작했더니
클래스의 구조가 계속해서 변경되면서 목록 관리가 되지 않았고,
이로 인해 엣지 케이스 커버는 커녕 기능이 제대로 구현되고 있는 건지도 파악하기 힘들었던 경험이 있는데요.
사전에 목록을 상세히 작성하니, 엣지 케이스를 상상해보는 과정을 통해서 서비스에 필요할 것 같은 기능을 구상하기 쉬워졌습니다.
설계 부분에 있어서 가장 깊이 와닿았던 것은,
지난 사이클 때 알려주신 "사용자의 입력 오류 처리와 도메인 규칙의 검증이 구분되어야 한다"는 부분입니다.
기능 목록에 이를 반영해 수정하는 과정에서 각 객체의 책임이 무엇인지를 더욱 명확하게 고민해볼 수 있었던 것 같습니다.
테스트 해봐야 하는 시나리오들을 미리 정리해두고 구현을 시작하니 확실히 TDD의 의의가 무엇인지 느낄 수 있었습니다.
기능을 추가하거나 수정하는 과정에서 아무리 코드가 변경되어도,
해당 도메인의 검증 테스트 덕분에 안심하고 코드를 작성할 수 있었던 경험이 인상적이었습니다.

(+ 실제로 '딜러의 점수가 16점 이하인 상태로 게임이 종료되면 안된다.'는 엣지 케이스를 기능 목록에 추가하고, 테스트 코드와 예외 발생 로직을 작성했는데, 덕분에 나중에 코드가 꼬이면서 딜러가 16점에서 한장 외에는 더 받아오지 않는 컨트롤러 흐름 오류도 잡을 수 있었습니다!! 중요성을 체감할 수 있었던 순간입니다!)

제가 조금 아쉽게 수행했다고 느끼는 부분은 1번 항목인데요.
제시해주셨던 '최대한 적은 범위의 코드 변경'을 제가 잘 수행한 것인지 모르겠습니다.
제가 해당 부분에 대한 이해가 아직 부족한 것 같기도 하네요.
이번 사이클에서 사용자마다 이름을 입력 받은 뒤 배팅 금액을 입력 받는다는 내용이 추가되면서,
Controller에서 검증 흐름을 돌리고 Player, Players가 받아오는 파라미터 인자가 많이 변하게 되었는데
기능 추가로 인해 어쩔 수 없이 변경된 '배팅 금액' 부분을 제외하더라도,
기존에 String으로 받아오던 이름 부분을 객체로 받아오도록 했으니..
해당 도전의 기준에 맞는 적절한 범위에서의 수정이 맞는지 확신이 가질 않습니다. (아마 이 외에도 수정한 사항이 있을 거 같기도 하고요..)
하지만, 이전 사이클의 리팩토링 때만큼의 대격변이 없었다는 점을 고려한다면,
이전에 비해서는 코드 변경이 일어나는 범위와 규모가 굉장히 축소되었다고 느낍니다!

우선은 제 선에서 할 수 있는 것들을 최대한 해보았는데,
지금 저의 시야로는 볼 수 없었던 부분들을 또 한번 살펴봐 주시고 짚어주시길 부탁 드립니다.
다시 한번 최선을 다해 개선하고 공부하겠습니다. 🙇‍♂️

애정이 담긴 리뷰 정말 감사드리고, 이번 리뷰도 잘 부탁 드리겠습니다!!

체크 리스트

• 미션의 필수 요구사항을 모두 구현했나요?
• Gradle test를 실행했을 때, 모든 테스트가 정상적으로 통과했나요?
• 애플리케이션이 정상적으로 실행되나요?

어떤 부분에 집중하여 리뷰해야 할까요?

고민했던 부분

• 컨트롤러에 도메인은 어느 정도까지 노출되어도 되는 걸까요?

게임의 초기 설정 부분 흐름이 기능 추가로 인해 많이 변했습니다.
이에 맞춰서 꽤나 많은 도메인이 현재 Controller에 노출되고 있는 상황인데요.
이렇게 산발적으로 분포해있는 형상이 정상적인 현상이라고 보아도 괜찮은지 여쭤보고 싶습니다.

• 컨트롤러에서 검증 흐름이 결정되고, 검증 메서드가 호출되어도 괜찮은 건가요?

현재 Controller에서 Players 의 validatePlayersCount 정적 메서드를 호출하고 있습니다.
저는 이것이 객체지향적이 아니라 절차지향적인 코드가 작성된 것이라는 느낌이 드는데요.
(블랙잭 자체가 순차적 흐름을 가진 프로그램이고, Controller의 코드이니 어쩔 수 없는 건가, 하는 생각이 들기도 합니다.)
현재의 흐름을 바꿀 수 있는 구조를 다시 한번 고민해봐야 할지, 아니면 이런 현상이 자연스러운 것인지 여쭤보고 싶습니다.
또, 해당 흐름으로 인해 현재 Player 최대 인원수가 Controller에서 한번, Players 객체 생성 시에 한번.
이렇게 두번 검증이 되고 있는데, 이 문제를 해결할 방법이 도저히 떠오르질 않아서.. 좋은 힌트가 있다면 부탁드리고 싶습니다!

• Game 클래스 에서 현재 인스턴스 변수를 3개 보유하고 있는데, 해당 문제를 해결하기 위해 시도해보면 좋을 방향이 무엇일까요?

처음에는 List<Participant> 로 Dealer와 Players 필드를 통합해보려 했으나,
둘의 성격이 다른 부분이 꽤 존재해서 구분이 필요하다고 느꼈습니다.
현재 Deck, Dealer, Players로 인스턴스 변수를 3개 가진 Game 구조 외에는 떠오르지 않는데,
'3개 이상의 인스턴스 변수를 가진 클래스를 쓰지 않는다.' 라는 제약을 지킬 좋은 방법이 무엇일지..
직접적인 정답은 스스로 찾아야 한다면, 방향성에 대한 힌트가 될만한 말씀을 해주실 수 있는지 여쭤보고 싶습니다!

(동일하게 3개의 인스턴스 변수를 가지고 있던 Controller의 경우, CardShuffleStrategy는 상태로 갖지 않고 메서드 파라미터로 주입받도록 개선해 해결을 시도해보았습니다.)

• 메서드 위임, 이대로 괜찮은 걸까요?

현재 Participant 클래스에서 Cards 클래스의 메서드들을 단순히 호출만 하는 식의 public 메서드들이 꽤 되는데,
이러한 위임 방식이 과도해지면 클래스들 간의 결합도가 너무 높아지는 것이 아닌가 하는 우려가 있습니다.
해당 부분을 좀 더 분리할 수 있는 방안을 고민해봐야 할까요?

• 불변 객체 사용을 연습해보려고 하는데, 다음 리팩토링에서 해당 내용을 반영해봐도 괜찮을까요?

미션에서 그룹으로 토론하며 설계 규칙을 만들어보는 시간을 가졌는데요,
'모든 객체는 불변 객체로 만든다' 라는 규칙이 사이클 2에서 새롭게 생겼습니다.
사이클 2 진행 과정에서 타협안이 필요하다는 목소리가 나오면서 현재는 다수결로 사장된 규칙입니다만...
우테코의 교육 자료에도 언급되어 있던 내용이라.. 도전을 해보는 것이 좋을지 고민이 되어 여쭤봅니다.