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

[jhk01007]

체크 리스트

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

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

TDD 개발 방식에 대해서

TDD로 개발을 하다 보니 실제 로직이 아니라 테스트가 먼저 작성되는 구조가 조금 어색하게 느껴졌습니다. 또한 시간이 더 오래 걸리는 것 같다는 생각도 들었습니다. 로직이 그렇게 복잡하지 않은 경우에도 TDD가 꼭 필요한지 의문이 들었고, 차라리 메서드 구현을 먼저 끝낸 뒤 테스트를 작성하는 방식이 더 낫지 않을까 하는 생각도 들었습니다.
그래서 실무에서는 TDD를 어떻게 적용하고 있는지 궁금합니다. 예를 들어 복잡한 메서드에 한해서만 TDD를 적용하는지, 아니면 모든 메서드에 대해 TDD를 실천하는지 등 실제로 어떤 방식으로 활용하고 계신지 알고 싶습니다

---

랜덤 같은 통제 어려운 값에 대한 테스트

현재 카드를 뽑는 메서드내에는 랜덤 로직이 존재하여 매번 반환하는 값이 달라지기 때문에 테스트가 어려웠습니다.
현재는 단순히 범위로 검증하고 있는데 리턴값이 매번 달라지기 때문에 언젠가 테스트가 깨질지도 모른다는 생각이 들었습니다.
실무에서는 이러한 통제가 어려운 로직은 어떻게 테스트하는지 궁금합니다.

---

패키지 구조를 어떻게 정리하는 것이 좋을지

현재 패키지 구조는 컨트롤러/서비스/도메인/뷰와 같이 레이어 기준으로 나누었는데요. 다만 domain 패키지 내부에 Card, CardDeck, HandCards, Participant 등 여러 객체가 있어 한눈에 보기엔 좋지 않은 것 같다고 느꼈습니다. 그 외에도 패키지 깊이 면에서 어떤 구조가 좋은지 의견을 구하고 싶습니다.

• domain 내부에 Card 관련 객체 / Participant 관련 객체 등으로 한 번 더 패키지로 나누는 것이 좋은지
• constant, exception 같은 패키지들은 common과 같은 상위 패키지로 묶어 관리하는 것이 더 나은지
• 지금처럼 패키지 깊이를 최소화하는 구조가 더 가독성이 좋은지

---

Dealer와 Player의 관계에 대해

일단 딜러도 결국 블랙잭에 참여하는 한 명의 플레이어라고 생각했습니다.

그러나 상속을 적용하기 보다는 isDealer 불리언 필드로 구별하도록 구현했습니다. 공부를 하면서 상속을 통한 구조보다는 조합이나 단순한 모델을 우선 고려해야한다고 듣기도 했고, 상속을 무조건 지양해야 하는지도 고민됩니다. 그래서 만약, 리뷰어님이 블랙잭을 구현한다고 했다면 Dealer와 Player를 어떻게 모델링했을지 의견을 듣고 싶습니다!

---

메서드 길이 10라인 이내 규칙

페어와 고민하면서 최대한 10라인 내외로 이뤄지게 메서드를 추출하며 노력했음에도 불구하고, 10라인을 넘는 메서드가 아직 존재하는데요.

그러다보니 실무에서도 메서드 길이를 10라인 이내로 작성하는지도 궁금해졌습니다. 그리고 지나치게 메서드를 잘게 나눈 것은 아닌지, 오히려 흐름을 따라가기 어려워지진 않았는지 고민하게 됐습니다..

---

랜덤 로직의 위치

저는 트럼프 카드를 섞는 랜덤(shuffle) 로직을 CardDeck 도메인 객체 내부에 둘지, 아니면 infra 계층에 별도의 클래스로 둘지 고민했었습니다.

• 도메인 객체 내부에 둘 경우
  • 카드 덱을 섞는 행위 자체는 CardDeck의 책임처럼 보이기 때문에 모델링 측면에서는 자연스러움.
  • 하지만 랜덤 로직이 도메인 내부로 들어오면 결과가 매번 달라지기 때문에 도메인의 순수성이 흐려지고 테스트가 어려워짐.
• 인프라 계층에 둘 경우
  • 랜덤 생성 로직을 인터페이스로 추상화하여 구현체를 교체할 수 있음
  • 테스트에서는 랜덤 대신 고정된 결과를 반환하는 구현체를 사용할 수 있어 테스트 작성이 훨씬 수월해짐

저는 여기서 테스트 용이성과 로직의 통제 가능성을 더 중요하게 생각하여 랜덤(shuffle) 로직은 인프라 계층에 두는 방식으로 선택했습니다. 이와 관련하여 의견을 듣고 싶습니다.

[jhk01007]

피드백 주셨던 부분들 반영했습니다! 중점적으로 리뷰받고 싶은 부분, 질문 몇가지를 정리해봤습니다.

1. Dealer와 Player 처리

가장 오래 고민했던 부분은 Dealer와 Player를 어떻게 처리할까였는데요. 기존처럼 isDealer를 두게되면 말씀해주신대로 외부에서 분기문을 작성해야 하고 추후 Dealer나 Player에게만 유효한 기능이 추가되면 하나의 클래스가 너무 많은 책임을 가진다고 생각해서 좋지 않다고 판단했습니다.
따라서 저는 이를 해결하기위해 Pariticipant라는 추상 클래스를 두고 Dealer, Player가 이를 상속받도록 하였습니다. 이를 통해 Dealer, Player의 공통된 기능은 Participant에 작성하고 Dealer, Player 각각이 필요한 기능은 각 클래스에서 작성하도록 하였습니다. 이 부분 중점적으로 봐주시면 감사하겠습니다!

2. Service 클래스에 대해

또한 추가적인 피드백을 반영하는 과정에서 Service 클래스의 필요성을 크게 느끼지 못해 제거하고, Service에 있던 기능을 각 도메인으로 분산 배치했습니다.하지만 이렇게 변경하니 도메인 간 의존성이 생기는 문제가 있었습니다. (예: Participant의 drawCard() 메서드)
이와 관련해 제나의 의견을 듣고 싶습니다. 해당 로직을 기존처럼 Service 클래스로 분리하는 것이 더 적절할지, 아니면 도메인에 두는 것이 더 나은 선택일지 궁금합니다. 또한 Service 클래스의 역할이나 정의, 그리고 어떤 상황에서 사용하는 것이 좋은지도 함께 조언해 주시면 감사하겠습니다!

[yenawee]

"플레이어는 입력받은 순서대로 출력한다"는 요구사항이 있는데 HashMap 이 적절할지 다시 확인해주세요!

[yenawee]

이 유효성 검증 존재하지 않는거같아요!

[yenawee]

Suggested change

	if (!input.matches("[y|n]")) {
	if (!input.matches("[yn]")) {

[yenawee]

외부에서 같은 List를 수정하면 Hand의 상태가 오염됩니다. 방어적 복사 사용해주세요!

[yenawee]

안녕하세요 제이!
피드백 반영 잘해주셔서 머지하겠습니다. 추가로 달아둔 코멘트는 다음 단계에서 반영해주세요 :D

1. Participant 추상 클래스 도입
   잘 처리해주신 거 같아요! 👏 각 클래스가 보다 자신의 책임만 가지는 것으로 보입니다.

2. Service 클래스의 역할
   여기서 서비스는 제거해주신 BlackJackService 를 말씀해주신거겠죠?
   핵심 판단 기준은 이 로직이 특정 객체의 책임인지, 아니면 객체들 사이의 관계에서 발생하는 책임인지가 될 거 같아요. 예를 들어서 MatchResult 를 계산하는 로직은 딜러, 참가자 어느 곳에 둬도 좀 어색했죠.
   현재는 이걸 Participants에 두었는데 Participants는 딜러 + 플레이어 전체를 묶은 개념이고, 결과를 계산하는 것은 "이 그룹 전체의 상태에서 나오는 정보" 이기에 Participants 에 있어도 어색하지 않다고 봐요. 하지만 점수 계산하는 과정에서 Participants 와 연관되지 않는 다른 요소 (e.g 점수별 배당) 이 들어간다면 도입을 고려해보는게 좋다고 생각합니다 :)

+) Deck과 CardShuffler는 동일 도메인의 협력 객체입니다. 참여자가 자신이 카드를 뽑는 방법을 알고 있는 것은 자연스러워보여요.