[🚀 사이클2 - 미션 (블랙잭 베팅)] 바니 미션 제출합니다. by frombunny · Pull Request #1103 · woowacourse/java-blackjack

frombunny · 2026-03-13T05:57:23Z

안녕하세요, 주노! 바니에요🐰
벌써 두번째 리뷰를 요청드리게 됐네요! 우테코에서 보내는 시간은 정말 빠르게 흘러가는 것 같아요 ㅎㅎ
이번 리뷰도 잘 부탁드리며, 즐거운 주말 보내세요 😄

체크 리스트

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

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

베팅 금액을 관리하는 객체가 따로 필요할까요?

저는 베팅 금액 객체를 별도로 생성할까 고민을 하다가 따로 생성하지는 않았습니다!

일단 객체를 생성하는 이유는 역할을 부여하고 그에 맞는 책임을 다하도록 하는 거라고 생각해요.
제 생각에는 지금 단계에서 베팅 금액 자체가 가져야 할 책임이 그렇게 많지 않은 것 같아요.
베팅 금액 후 최종 수익 계산 로직 외에는 베팅 금액에 대한 규칙도 없고,
GameResult에서 calculatePlayerProfit 함수로도 현재 기능을 충분히 구현할 수 있다고 생각했습니다!

이 부분을 고민하면서 과한 설계와 확장 가능한 설계 사이에서 어떻게 균형을 잡아야 할지 궁금해졌어요.
도메인 객체를 분리할 때 어느 정도의 책임이나 규칙이 생기면 객체로 분리하는 것이 적절한지,
혹은 미래 확장을 고려해 미리 객체를 만드는 것이 좋은 경우는 언제인지 궁금해요!
일단 제 생각은 책임이 늘어가거나 도메인 규칙이 추가되면 객체로 분리하는 것이 좋다고 생각합니다.
과한 추상화는 오히려 코드 복잡도를 높일 수 있다고 생각하기 때문입니다!

테스트 주도 개발은 어떻게 해야 잘할 수 있는 걸까요?

물론 이제 막 TDD를 겨우 시작한 단계에서 벌써 잘하기를 바라는 건 조금 욕심이겠지만, 아직도 TDD가 너무 어렵고 낯설게 느껴지는 것 같아요.

예를 들어 구현을 하다 보면 테스트를 먼저 작성하려고 해도 어떤 인터페이스나 구조를 가정하고 작성해야 할지 막히는 순간이 있었고, 테스트를 작성한 뒤에도 구현 또는 테스트를 많이 수정하게 되는 경우가 있어서
이 과정이 제대로 된 TDD 사이클인지 고민이 되기도 합니다..!

그래서 테스트를 먼저 작성할 때 어느 수준까지 설계를 가정하고 테스트를 작성하는 것이 적절한지
실제로 TDD를 잘 하기 위해서 연습하거나 의식적으로 신경 쓰면 좋은 부분이 무엇인지 궁금합니다!

Signed-off-by: leejaeheon <jaeheon@leejaeheons-MacBook-Air.local>

세부사항: - 덱에 카드가 존재하지 않는 경우 예외 발생

세부사항: - ACE는 기본 11 - ACE가 존재하고 합계가 21을 초과하는 경우 1로 변경 - Cards 일급 컬렉션 도입

- Participant의 Card 일급 컬렉션은 Hand로 정의, Deck의 일급 컬렉션은 Cards로 정의

Choi-JJunho

바니~! step2 미션도 잘 수행해주셨네요 👍
몇가지 코멘트 남겼으니 확인 부탁드릴게요 🙏
step2도 화이팅입니다! 💪

Choi-JJunho · 2026-03-14T17:21:31Z

src/main/java/domain/game/GameResult.java

+            BigDecimal profit = calculatePlayerProfit(player, dealer);
+            playersProfitSum = playersProfitSum.add(calculatePlayerProfit(player, dealer));


calculatePlayerProfit 을 두번 호출하시는 이유가 있을까요?

헉😮 이 부분은 구조를 바꾸는 과정에서 실수했네요..! 수정하도록 하겠습니다..!

Choi-JJunho · 2026-03-14T17:24:02Z

src/main/java/domain/game/GameResult.java

+    private ParticipantResultInfo participantResultInfo(Participant participant) {
+        return participantResultInfos.stream()
+                .filter(participantResultInfo -> participantResultInfo.name().equals(participant.name()))
+                .findFirst()
+                .orElseThrow(IllegalStateException::new);


이름으로 참가자를 찾고있군요!
이름이아닌 다른 값으로 확인해야한다면 어떤 자료구조를 사용해볼 수 있을까요?
ex) 가장 돈을 많이 번 사람

말씀해주신 것처럼 이름을 식별자로 사용하는 게 뭔가 어색하게 느껴지더라구요..!
다시 생각해보니, Map 구조로 관리하면 참가자 객체 자체를 key로 사용할 수 있어서 좋겠어요 🐰

++) 추가로 도메인이 dto를 들고 있는 로직도 이상하다고 생각하여 이 부분도 수정해보겠습니다..!

Choi-JJunho · 2026-03-14T17:25:33Z

src/main/java/domain/game/GameResult.java

+            ));
        }
+
+        participantResultInfos.add(new ParticipantResultInfo(dealer.name(), playersProfitSum.negate()));


딜러를 3번째에 출력해야한다 라고 요구사항이 변경되면, 도메인 로직을 변경해야할까요?
List의 마지막에 딜러를 둔다는 행위가 출력에 의존적일 수 있지 않나 하는 생각이 드는데 바니의 생각은 어떠신가요?

주노의 말에 완전 동의해요.. 그 부분을 전혀 고려하지 못하고 있었네요!
GameResult가 딜러와 플레이어 최종 결과 정보를 각각 필드로 들고 있도록 수정하는 게 좋겠어요 👀

++) 위와 같이 먼저 답했었는데, Map을 사용하면 굳이 필드를 분리할 필요가 없을 것 같아요 😮
그래서 Map 구조로 변경하였습니다!

Choi-JJunho · 2026-03-14T17:27:04Z

src/main/java/domain/game/WinningStatus.java

+            return TIE;
+        }
+
+        return null;


메서드가 null을 반환하는군요 👀
null을 반환하는 메서드가 있을때 어떤 문제가 발생할 수 있을까요?
Optional을 활용해보시는것도 하나의 방법이 될 수 있습니다 👍

null을 반환하는 메서드가 있다면 NPE가 발생할 수 있습니다.
따라서 해당 메서드를 호출하는 모든 곳에서 null 체크를 해줘야 하는 번거로움이 생깁니다..!
제가 Optional을 활용할 생각을 못했네요..😢 Optional을 반환하도록 수정하겠습니다!

Choi-JJunho · 2026-03-14T17:28:29Z

src/main/java/domain/participant/Player.java

 import static domain.BlackjackRule.BLACK_JACK;

 public class Player extends Participant {
+    private BigDecimal betAmount = BigDecimal.ZERO;


베팅 금액을 관리하는 객체가 따로 필요할까요?
이 부분을 고민하면서 과한 설계와 확장 가능한 설계 사이에서 어떻게 균형을 잡아야 할지 궁금해졌어요.
도메인 객체를 분리할 때 어느 정도의 책임이나 규칙이 생기면 객체로 분리하는 것이 적절한지,
혹은 미래 확장을 고려해 미리 객체를 만드는 것이 좋은 경우는 언제인지 궁금해요!
일단 제 생각은 책임이 늘어가거나 도메인 규칙이 추가되면 객체로 분리하는 것이 좋다고 생각합니다.
과한 추상화는 오히려 코드 복잡도를 높일 수 있다고 생각하기 때문입니다!

좋은 기준이라고 생각합니다! 저도 바니의 의견에 동의해요 :)
저는 개인적으로 돈이라는 도메인을 중요하게 생각하는 편이라 돈을 다루는 값은 반드시 래핑해야한다고 생각하는 편이에요
1원이라도 오차가 나면 안되는 도메인이라고 생각하거든요!

이건 제 개인적인 의견이고, 바니의 주장과 근거도 타당하다고 생각합니다!

사실 이전까지는 현시점에서 굳이 돈을 래핑해야 할까 하는 생각이 있었는데,
주노의 의견을 듣고 보니 돈이라는 도메인을 별도의 값 객체로 다루는 이유를 알겠어요😃
다시 생각해도 중요한 건은 스스로 그 선택의 근거를 설명할 수 있어야 하는 것이라는 생각이 드네요!

Choi-JJunho · 2026-03-14T17:32:30Z

src/main/java/controller/BlackjackGame.java

+                .map(Player::new).toList()
+        );
+
+        players.getPlayers().forEach(player -> player.bet(inputView.getBetAmount(player.name())));


일급컬렉션에서의 요소를 받은 뒤 그 요소가 player가 변경되는 구조네요!
구조적으로 불안정한 형태가 되는 것 같은데 어떻게 안정적인 형태로만들어 볼 수 있을까요?
방어적 복사를 적용해보시죠!

말씀해주신 내용을 바탕으로 players를 반환하는 부분에서 방어적 복사를 적용하였습니다!

그런데 개발을 하다가 한 가지 고민했던 부분이 생각났습니다.
[이름을 입력 받아 Player 객체를 생성한 후, 베팅 금액을 입력 받는 방식] VS [이름과 베팅 금액을 모두 입력 받은 후 Player 객체를 생성하는 방식] 중 무엇이 더 적절할지 고민되었습니다..!

개인적으로 코드를 작성할 당시에는 이름을 입력받아 Player 객체를 생성한 후 베팅 금액을 입력 받는 것이 실제 게임 흐름과 더 유사하다고 생각해서 이렇게 작성했는데, 그로 인해 저런 코드가 나오게 된 것 같아요!

혹시 이름과 베팅 금액을 모두 입력받은 뒤 Player 객체를 생성하는 방식이 더 적절한 설계일지 궁금합니다!

Choi-JJunho · 2026-03-14T17:34:17Z

src/main/java/domain/game/GameResult.java

 public class GameResult {
-    private final Map<Player, WinningStatus> playerWinningStatus = new LinkedHashMap<>();
+    private final List<ParticipantResultInfo> participantResultInfos = new ArrayList<>();

    public GameResult(Players players, Dealer dealer) {
+        BigDecimal playersProfitSum = BigDecimal.ZERO;
        for (Player player : players.getPlayers()) {
-            playerWinningStatus.put(player, WinningStatus.of(player, dealer));
+            BigDecimal profit = calculatePlayerProfit(player, dealer);
+            playersProfitSum = playersProfitSum.add(calculatePlayerProfit(player, dealer));


GameResult의 책임이 많아진것 같아요!

수익계산, 결과저장, 조회의 책임을 가지고있는데 calculatePlayerProfit 와 같은 로직이 GameResult 책임이 맞을까요?

제가 보기에도 수익 계산은 확실히 GameResult의 역할은 아닌 것 같습니다..!
ProfitCalculator라는 클래스를 따로 두어 수익 계산 책임을 분리해보도록 하겠습니다 🐰

Choi-JJunho · 2026-03-14T17:44:29Z

src/test/java/domain/WinningStatusTest.java

    }

+    @Test
+    void 플레이어가_처음_받은_카드_두_장의_합이_21이고_딜러는_아닐_경우_플레이어가_승리한다(){


테스트 주도 개발은 어떻게 해야 잘할 수 있는 걸까요?
그래서 테스트를 먼저 작성할 때 어느 수준까지 설계를 가정하고 테스트를 작성하는 것이 적절한지
실제로 TDD를 잘 하기 위해서 연습하거나 의식적으로 신경 쓰면 좋은 부분이 무엇인지 궁금합니다!

TDD를 한다고하면 보통 Red-Green-Refactor 단계로 진행을하죠!
근데 이 Red 단계를 작성하는게 불안해서 Green 영역을 미리 구현한다는 등의 행동도 자주 나올 수 있는 것 같아요
저도 이 TDD가 너무 어려운 과정이라고 생각해요

테스트 작성할때는 당장 필요한 요구사항을 단위로 작성해보는게 가장 현실적인것 같아요. 가능하다면 그 요구사항을 더 잘개 쪼개보는거죠

실제로 TDD를 더 잘 하기 위한 연습으로 추천드려볼만한건 미션이 끝난 뒤에 구현부를 다 지우고, 테스트만 보고 다시 구현하는 과정을 진행해보면 고통스럽지만 성장할수는 있는 연습이 될 수 있을 것 같아요 ㅎㅎ

좋은 조언 정말 감사합니다 🙇
저도 테스트를 작성하다가 도중에 green 영역을 미리 구현해버리는 일들이 많았던 것 같아요..!
주노의 조언대로 미션이 끝난 후에는 테스트만 보고 다시 구현하는 과정을 한번 거쳐봐야겠습니다!

Choi-JJunho · 2026-03-14T17:45:09Z

src/test/java/domain/GameResultTest.java

+
+    @Test
+    void 무승부일_경우_플레이어는_자신이_베팅한_금액을_돌려받는다() {
+        Cards playerCards = new Cards(List.of(new Card(Rank.ACE, Suit.HEART), new Card(Rank.JACK, Suit.HEART)));


테스트코드에서 new Cards(...) 와 같은 패턴이 반복되고있네요!
Fixture를 만들어두면 더 간단하게 테스트코드를 표현해볼 수 있을것 같아요 :)

fixture를 만들어서 카드 생성 로직을 조금 더 간소화 시켜보겠습니다!

Choi-JJunho · 2026-03-14T17:47:10Z

src/main/java/domain/game/GameResult.java

+    private final List<ParticipantResultInfo> participantResultInfos = new ArrayList<>();

    public GameResult(Players players, Dealer dealer) {
+        BigDecimal playersProfitSum = BigDecimal.ZERO;


BigDecimal을 사용해주셨군요!
왜 BigDecimal을 사용하셨는지 궁금합니다

float, double 같은 경우는 부동소수점을 이용해 수를 저장하는데, 이 과정에서 오차가 발생할 수 있다고 알고 있습니다. 돈은 미세한 오차도 허용되면 안된다고 판단하여, BigDecimal를 사용하였습니다 🐰

frombunny · 2026-03-15T14:37:30Z

안녕하세요, 주노!
주말은 잘 보내셨나요? 리뷰해주신 내용을 바탕으로 수정을 진행했어요 😄
이번 주도 즐거운 한 주 보내셨으면 좋겠습니다 🐰

leejaeheon added 30 commits March 1, 2026 21:15

pre-study: 합계가 21 초과인지 판단

4a53628

Signed-off-by: leejaeheon <jaeheon@leejaeheons-MacBook-Air.local>

init: 초기화

045dc35

Signed-off-by: leejaeheon <jaeheon@leejaeheons-MacBook-Air.local>

test(parser): 입력 검증 테스트 작성

9018e64

feat(parser): 입력 파싱 기능 추가

177d7f2

docs(readme): 요구사항 정리

e1a792c

test(cardTest): 카드 테스트코드 작성

cc97a30

feat(card): 카드 객체 구현

c561832

Signed-off-by: leejaeheon <jaeheon@leejaeheons-MacBook-Air.local>

docs(readme): 요구사항 구체화

3de16ad

Signed-off-by: leejaeheon <jaeheon@leejaeheons-MacBook-Air.local>

test(parser): 빈 입력의 경우 예외처리

b4200f5

Signed-off-by: leejaeheon <jaeheon@leejaeheons-MacBook-Air.local>

feat(parser) 빈 입력 검증

29ddc2f

Signed-off-by: leejaeheon <jaeheon@leejaeheons-MacBook-Air.local>

test(domain): 참가자 이름 중복 검증

5831766

feat(domain): 참가자 이름 중복 검증

f9de3da

feat(domain): 카드 점수 계산

655ae0d

test(domain): 덱 생성 및 섞기

3f1bfc6

feat(domain): 덱 생성 및 섞기

1bc1525

feat(domain): 카드를 한 장 뽑는 기능

4e2335d

세부사항: - 덱에 카드가 존재하지 않는 경우 예외 발생

feat(domain): 카드 점수 합산 및 버스트 판별

1d31d46

feat(domain): ACE 처리

3dddaa6

세부사항: - ACE는 기본 11 - ACE가 존재하고 합계가 21을 초과하는 경우 1로 변경 - Cards 일급 컬렉션 도입

feat(domain): 카드 숫자 및 무늬 반환

06d5182

refactor(domain): 의존성 분리

7aab304

- Participant의 Card 일급 컬렉션은 Hand로 정의, Deck의 일급 컬렉션은 Cards로 정의

feat(domain): 참가자에게 카드 분배

1d7d3d0

refactor: 도메인 로직 수정

9553464

feat(domain): 딜러와 플레이어 간의 카드 합 비교

6bbf0b6

feat: 게임 결과 반환

9cce391

feat: 흐름제어 및 입출력

e688417

refactor: 참가자 이름 원시값 래핑

49b1638

refactor: 메서드명 변경

2a266d6

refactor: 테스트 코드 개선

d90de0e

refactor: 메서드 명 개선

f28f3c1

refactor: 매직넘버 처리 및 dto 도입

871df97

frombunny added 18 commits March 11, 2026 11:08

refactor: 필요없는 import문 제거 및 Name 클래스를 레코드로 선언

9b83197

refactor: 접근제어자 점검

f31f43d

refactor: Stream의 ditinct 함수 사용

439ed40

refactor: Cards 일급 컬렉션 적용

543030e

refactor(domain): 카드 셔플 전략 사용 시, 전략이 전달된 리스트를 수정하지 않도록 변경

9fb4070

docs: 변경 및 추가된 요구사항 정리

bcd3028

fix: 입력 예외 처리 추가

7e52ef0

feat(domain): 블랙잭 판별 로직 작성

6b95dc1

docs: 누락된 요구사항 추가

3a70643

refactor(domain): 블랙잭 판별 로직 수정

3b36f8e

feat(doamin): 수익 계산 기능 추가

055878a

refactor: 사용되지 않는 임포트 및 변수 정리

1be0dd0

refactor(domain): 블랙잭 여부에 따른 승부 판별 로직 개선

2671cb0

style: 람다식으로 구문 변경

c7b94b8

fix: 충돌 해결

a68d9a0

refactor: 사용되지 않는 파일 삭제

8d7d9c1

refactor: 개발 시 사용했던 출력 로그 삭제

ab26a90

docs: 요구사항 수정

175f494

Choi-JJunho requested changes Mar 14, 2026

View reviewed changes

frombunny added 9 commits March 15, 2026 12:26

refator: 중복 로직 제거

3ed8f3a

fix: 플레이어의 카드 합이 21일 경우에는 카드를 뽑지 못하도록 수정

c4681f6

refactor: GameResult의 플레이어와 딜러의 게임 결과 필드 분리

89a28ba

refactor: GameResult 필드 자료구조 변경

1137dea

fix: 애플리케이션 실행 오류 해결

689d625

refactor: judgeBlackjack 함수가 null 대신 Optional을 반환하도록 수정

4e52c38

test: GameResultTest에 헬퍼 메서드 추가

018bcb0

refactor: Players에 방어적 복사 적용

5e7c895

refactor: 수익 계산 로직을 별도의 클래스로 분리

fefcf5b

frombunny force-pushed the step2 branch from 9427bb2 to fefcf5b Compare March 15, 2026 14:35

		BigDecimal profit = calculatePlayerProfit(player, dealer);
		playersProfitSum = playersProfitSum.add(calculatePlayerProfit(player, dealer));

Conversation

frombunny commented Mar 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

체크 리스트

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

베팅 금액을 관리하는 객체가 따로 필요할까요?

테스트 주도 개발은 어떻게 해야 잘할 수 있는 걸까요?

Uh oh!

Choi-JJunho left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

frombunny Mar 15, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

frombunny Mar 15, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

frombunny Mar 15, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

frombunny Mar 15, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

frombunny Mar 15, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

frombunny commented Mar 15, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

frombunny commented Mar 13, 2026 •

edited

Loading

frombunny Mar 15, 2026 •

edited

Loading

frombunny Mar 15, 2026 •

edited

Loading

frombunny Mar 15, 2026 •

edited

Loading

frombunny Mar 15, 2026 •

edited

Loading

frombunny Mar 15, 2026 •

edited

Loading