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

Seonwu-K · 2026-03-13T07:34:58Z

체크 리스트

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

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

블랙잭2 PR 리뷰 요청

리뷰 요청

이번 미션에서는 특히 설계를 결정하는 과정에서 어떤 기준으로 판단하면 좋을지에 대한 조언을 얻고 싶습니다.

1. Controller 도입에 대한 고민

이번 미션을 구현하면서 가장 고민했던 부분 중 하나는 Controller를 도입하는 것이 맞는가였습니다.

크루들과 토론을 진행하던 중, 지나가던 코치님이 '컨트롤러를 왜 사용해요?' 라는 질문을 던지고 가셨는데, 이번 미션에 컨트롤러를 적용했던 것이 옳았는지에 대한 고민을 하게 되었습니다.

제가 이해한 Controller의 역할은 다음과 같습니다.

Model과 View 사이를 연결하는 역할
여러 도메인 객체를 흐름에 맞게 호출하는 역할
사용자 입력과 출력 사이에서 게임 진행 흐름을 제어하는 역할

저는 게임의 전체 흐름을 담당하는 객체가 필요하다고 생각했고, 그 역할을 Controller가 맡는 것이 자연스럽다고 판단했습니다.

그래서 다음과 같은 흐름을 Controller에서 담당하도록 구현했습니다.

플레이어 입력 처리
게임 진행 흐름 제어
도메인 객체 호출
View와 상호작용

하지만 크루들과 리뷰를 주고받는 과정에서 이런 생각도 들었습니다.

굳이 Controller가 없어도, 도메인 객체들끼리 응집성 있게 협력하도록 만들고
외부에서는 단순히 하나의 진입 메서드만 호출하도록 만들 수도 있지 않았을까?

그래서 PR을 작성하는 순간에도 Controller가 흐름을 관리하는 구조가 꼭 필요했을까? 에 대해서는 부정적인 생각이 듭니다.

질문

주디가 생각하시는

Controller가 필요한 상황은 어떤 경우인지
이번 미션에서 Controller를 도입한 제 선택이 오버 엔지니어링으로 느껴지셨는지
혹은 Controller 없이 도메인 객체 중심으로 흐름을 구성하는 것이 더 나은 접근이었는지

에 대한 의견을 듣고 싶습니다.

2. 설계 결정을 내릴 때의 기준에 대한 고민

이번 미션을 진행하면서 설계를 결정해야 하는 순간들이 여러 번 있었습니다.

예를 들어 다음과 같은 고민들이 있었습니다.

배팅 금액을 Player가 가져야 하는가, 별도의 객체가 관리해야 하는가
Result를 상태로 관리해야 하는가, 계산 결과로 처리해야 하는가
딜러와 플레이어의 상속 구조를 유지할 것인가, 추상화를 새로 만들 것인가

이런 고민들을 할 때마다 스스로 나름의 기준을 세워 결정을 내렸지만
그 기준이 객체지향 설계 관점에서 적절한 기준이었는지 확신이 아직도 서지 않습니다.

그래서 주디에게 다음과 같은 부분을 질문하고 싶습니다.

질문

도메인 설계를 할 때

여러 설계 선택지 중 하나를 결정할 때 어떤 기준으로 판단하시는지
경험이 부족한 초보 개발자가 설계 결정을 할 때 중요하게 잡아야 할 기준이 무엇인지

에 대해 조언을 듣고 싶습니다.

3. 테스트와 설계의 관계에 대한 고민

이번 미션에서 테스트를 작성하면서 느낀 점은
테스트가 설계를 이끈다는 감각이 아직 익숙하지 않다는 것이었습니다.

현재 저는 다음과 같은 방식으로 테스트를 작성하고 있습니다.

도메인 로직 중심 테스트
입출력 로직은 테스트 제외
게임 전체 흐름은 일부만 테스트

처음에는 TDD를 시도해볼까 하는 생각에 테스트 코드를 먼저 써보고 코드 구조를 잡아가려는 시도도 해보았지만 도저히 기능을 어떻게 구현할지 구조가 그려지지 않아 결국 중간 부터 클래스 구조를 먼저 구상해두고 맞춰서 테스트 코드를 작성하는 방식으로 돌아간 것 같습니다.

하지만 테스트를 작성하면서도

어떤 부분까지 테스트해야 하는지
테스트하기 어려운 구조가 나타났을 때 설계를 어떻게 수정해야 쉬워질지

판단이 잘 되지 않습니다. 이는 이번 블랙잭 미션이 던져준 핵심 질문이기도 했는데 미션 마무리 단계에 들어서도 아직 확신이 없습니다.

질문

테스트하기 어려운 코드가 나타났을 때 어떤 설계 문제를 먼저 의심하시는지
테스트를 기준으로 설계하는 경험은 어떻게 연습해야 할지

에 대해 조언을 듣고 싶습니다.

4. 미션 요구사항과 도메인 설계 기준이 충돌할 때의 판단 기준

이전부터 미션을 진행하면서 이어져온 고민입니다.

우테코 미션에는 객체지향 생활체조 규칙과 같은 여러 제약들이 존재하며,
이번 미션에서도 다음과 같은 제약이 있었습니다.

인스턴스 변수를 3개 이상 만들지 않는다
컬렉션을 포장한다
getter 사용을 지양한다
...

이 규칙들은 객체지향 설계를 학습하기 위한 좋은 가이드라고 생각합니다.

하지만 구현 과정에서 한 가지 고민이 생겼습니다.

예를 들어 Player 객체는 다음과 같은 상태를 자연스럽게 가지게 되었습니다.

name
hand
playerStatus

이 경우 필드 수가 3개가 됩니다.

이 상황에서 두 가지 선택지가 있다고 느꼈습니다.

규칙을 지키기 위해 필드를 억지로 분리하거나 구조를 변경한다.
현재 도메인 모델에서 자연스럽다고 생각하는 설계를 유지한다.

저는 이번 구현에서는 도메인 모델 관점에서 더 자연스럽다고 생각되는 설계를 유지하는 방식을 선택했습니다.

그 이유는 다음과 같습니다.

Player와 관련된 정보가 하나의 객체에 모이는 것이 더 응집도가 높다고 느꼈습니다.
규칙을 맞추기 위해 구조를 억지로 분리하는 것이 오히려 도메인 모델을 흐리게 만들 수 있다고 생각했습니다.

다만 이 판단이 적절한 선택이었는지는 스스로 확신이 서지 않습니다.
그리고 이 규칙을 깨고 내 설계 판단으로 결정하기까지 고민하는 데에도 많은 시간을 소비했습니다.

질문

이런 상황처럼

요구사항으로 제시된 설계 제약
도메인 모델 관점에서 자연스럽다고 생각되는 설계

가 서로 충돌할 때

주디는 어떤 기준을 더 우선적으로 고려하시는지 궁금합니다.

이런 규칙들이 도메인 설계 원칙을 반영한 규칙인지, 객체지향 설계를 학습하기 위한 교육용 제약인지
그리고 그 두 가지가 충돌하는 상황에서는 어떤 방식으로 판단하면 좋을지에 대한 조언을 듣고 싶습니다.

마지막으로

이번 미션에서는 특히 다음 질문들을 스스로 계속 고민하며 구현했던 것 같습니다.

기능 추가 시 왜 기존 코드가 깨지는가?
변경 범위를 최소화하는 구조란 무엇인가?
테스트 코드를 중심으로 설계를 하려면 어떻게 해야하는가?

혹시 제가 놓치고 있는 설계 관점이나
더 고민해보면 좋을 부분이 있다면 어떤 피드백이든 감사히 배우겠습니다.

감사합니다.

jurlring

루디 안녕하세요!
코멘트 몇가지랑 질문에 대한 답변 달아두었습니다!
시간 괜찮으실 때 확인해주세요~!

jurlring · 2026-03-17T11:22:25Z

 import java.util.ArrayList;
 import java.util.List;

 public class DtoFactory {


공개 규칙 차이가 딜러는 카드를 한장만 공개하고 플레이어는 받은 카드 2장을 모두 공개하는걸까요? 공개할 카드 open하는 것을 추상화하면 안되나요?

jurlring · 2026-03-17T11:25:51Z

+    private static final int MIN_BETTING_MONEY = 1;
+    private static final String INVALID_MESSAGE = "배팅 금액은 0보다 커야 합니다.";
+
+    private final int value;


Integer.Max보다 더 큰 값이 오면 어떻게 될까요? 😱 블랙잭은 도박입니다..!!
데이터 타입에 대한 고려도 해보시면 좋을 것 같아요.

Max값은 도메인 규칙상으로 정하는 것만 고려하고 있었는데 데이터 타입 자체의 Max가 영향을 받을 수 있을 거라고는 생각을 못해본 것 같습니다 🥲

블랙잭은 도박 게임인 만큼 큰 금액이 오갈 가능성을 고려해야 하는데 지금까지 큰 숫자를 다뤄본 적이 없다보니 Integer면 충분히 큰 수를 다룬다고 생각했던 것 같습니다. 확인해보니 20억이 최대기 때문에 블랙잭이라는 도메인에서는 충분히 문제가 있을 것 같다는 생각이 들어요.

요구사항에서 베팅머니에 대한 상한이 존재하지도 않기 떄문에 충분한 금액 설정이 가능하도록 Long으로 수정해두었습니다.

jurlring · 2026-03-17T11:27:14Z

수정해주신 부분이 제가 의도한게 맞습니다 💯

jurlring · 2026-03-17T11:31:43Z

+                .map(String::trim)
+                .filter(c -> !c.isEmpty())


중간 연산이 여러번 있어서 문제될 수 있는 부분이 어떤 포인트인지에 대해서는 아직 완전히 이해하지 못한 것 같습니다.
-> 가독성 측면에서 리뷰드렸어요!
학습해보시면 좋을 것은 stream이 보이길래 말씀드렸던 것이고, 아무래도 사람이 이해하기에는 순서대로라서 trim을 하고 문자열이 비었으면 제외 보다는 문자열이 빈값이면 제외가 좀 더 이해하기 쉬우니까요~

kang-hyungu

루디 몇 가지 피드백 남겼어요
궁금한 점 있으면 질문주세요

kang-hyungu · 2026-03-18T09:22:29Z

    private void registerPlayer() {
-        // TODO: 베팅 기능 추가 시 이름 입력 후 각 플레이어의 베팅 금액도 함께 등록
        while (true) {
            try {


2뎁스를 1뎁스로 줄여보세요

try-catch 역시 뎁스에 해당되는 것을 놓쳤네요
try-catch부분을 메서드로 분리하여 뎁스를 줄여보았습니다

kang-hyungu · 2026-03-18T09:24:48Z

+    }
+
+    private void registerPlayersWithBettingMoney(List<Name> playerNames) {
+        List<BettingMoney> bettingMoneyList = new ArrayList<>();


Suggested change

List<BettingMoney> bettingMoneyList = new ArrayList<>();

List<BettingMoney> bettingMoneys = new ArrayList<>();

타입에 이미 List가 쓰이고 있는데 변수명에 또 표시할 필요가 있을까요?
리스트의 변수명은 영어문법과 상관 없이 s를 붙이기도 하니 참고하세요

생각해보면 변수명에는 명시할 필요가 없을 것 같습니다.
문법과 상관없이 s를 붙이는 것은 처음 알게 되었어요. 해당 변수명은 수정해두겠습니다 감사합니다!

kang-hyungu · 2026-03-18T09:25:20Z

@@ -56,15 +67,24 @@ private void initGame() {
    }

    private void playPlayerTurn() {


메서드명을 그냥 play라고 해도 충분하지 않나요?

프리코스에서 공통 피드백으로 메서드 이름이 길어지더라도 확실한 이름을 지어주는 것이 좋다는 피드백을 받은 기억이 있습니다. 컨트롤러에서는 딜러턴과 플레이어턴을 구분해서 진행하기 때문에 처음에 playPlayerTurn과 playDealerTurn을 구분하여 읽기 쉽도록 메서드 이름을 지었습니다.

다시 생각해보니 실행 로직에서 핵심은 플레이어 턴이고, 이미 내부에서 playSinglePlayerTurn메서드를 실행하고 있어서 그냥 play로 작성하는게 더 명확한 것 같습니다.

해당 메서드는 play로 수정해두겠습니다. 감사합니다.

kang-hyungu · 2026-03-18T09:26:19Z

-    Result(String name) {
-        this.name = name;
-    }
+        if (player.isBust()) return BUST;


if절에 구문이 코드 한줄이라도 중괄호 붙이세요
변경 사항 생겨서 코드 추가하면서 중괄호 생략하면서 실수가 발생하기도 합니다

메서드 라인 수에 대한 의식 때문에 생략을 하게 된 것 같습니다.
if 중괄호 제약이 왜 있는지 의문이었는데 코드 수정 시 실수 방지를 위해서 였군요
수정해두겠습니다 감사합니다!

kang-hyungu · 2026-03-18T09:27:04Z

+import java.util.ArrayList;
 import java.util.List;

 public class GameManager {


게임 매니저라는 이름을 보면 팀원이 이게 무슨 작업을 처리하는지 쉽게 파악을 할 수 있을까요?
모호한 이름보다 블랙잭에서 쓰는 용어를 활용해보세요

도메인을 모르는 사람이 봤을 떄 동작을 기준으로 읽을 수 있는 네이밍과,
도메인을 알고 있는 사람이 봤을 때 어떤 역할인지 확실히 이해할 수 있는 네이밍 중에서 고민을 하다가 전자를 선택하게 되었습니다.

다른 크루들의 코드를 참고해 보았을 때 도메인 용어를 활용한 네이밍이 더 간결하고 명료한 것 같아서 수정을 고민하고 있었는데 GameManager 와 그 메서드들을 블랙잭 용어를 기반으로 수정해보았습니다.

Q. 실무에서도 도메인에 대해 이해하고 있다고 가정하고 도메인 용어를 활용한 네이밍을 하는 것을 선호하는지 궁금합니다

kang-hyungu · 2026-03-18T09:29:33Z

+    }
+
+    protected boolean hasTwoCards() {
+        return hand.size() == 2;


2가 무엇을 의미하는지 상수로 추출해서 의미 있는 이름을 붙여보세요

하드코딩 된 숫자를 추후 수정한다는게 놓쳤던 것 같습니다.

기존 OutputView에서도 초기 핸드 사이즈 2를 출력하는 상수가 있었어서 따로 규칙 클래스를 만들어 상수를 선언하고 불러 사용하는 방법으로 수정 해봤어요

kang-hyungu · 2026-03-18T09:29:53Z

+        return hand.isBlackjack();
+    }
+
+    public void receiveCard(Card card) {


receive 대신 게임에서 실제 사용하는 용어를 활용해보세요

도메인 행동을 나타내는 기존 GameManager와 그 메서드들에서 블랙잭 용어를 반영하였습니다.
ex. drawPlayerCard를 hit으로

Participant의 receiveCard는 플레이어의 선택 행동이 아니라
전달된 카드를 상태에 반영하는 역할이라고 판단하여,
동일한 용어인 hit으로 대체되면 혼동이 있을 것 같아 의미를 드러내기 위해 addCard로 수정해보았습니다.

kang-hyungu · 2026-03-18T09:30:04Z

+        hand.add(card);
+    }
+
+    public List<String> getHandToString() {


이 메서드가 필요한 이유가 뭔가요?

Hand는 Participant의 내부 상태라고 생각해서,
외부가 Hand에 직접 접근하는 것 보다 Participant가
필요한 값을 제공하는 구조가 더 적절하다고 판단했습니다.

다만 현재 getHandToString은 명확한 의도가 전달되지 않고 구현 시점에서 적은 이름이라
Participant의 의도가 충분히 전달되지 않았던 것 같습니다.
더 적절한 표현으로 수정하기 위해 revealCards로 수정해두었습니다.

혹시 구구가 질문 주신 의도가 단순히 중계 역할을 하는 getHandToString 메서드 자체에 대한 것이 아니라,
Hand에서 카드 정보를 문자열 형태로 변환하는 메서드 자체의 필요성에 대한 것인지 궁금합니다.

kang-hyungu · 2026-03-18T09:30:54Z


-    public void receiveCard(Card card) {
-        players.forEach(player -> player.receiveCard(card));
+    public static Players of(List<Player> playersList) {


팩터리 메서드를 추가한 이유가 뭐죠?
생성자를 써도 되지 않나요?

처음에는 정적 팩토리 메서드의 장점인 캡슐화와 의도가 드러나는 네이밍을 고려해서 도입했습니다.

리뷰를 받고 다시 보니 현재 Players의 생성 과정이 생성자를 감싸기만 하고 있고,
of라는 이름도 의도를 드러내는 역할은 못하고 있는 것 같아서
정적 팩토리 메서드의 이점을 제대로 적용하지 못하고 있는 것 같습니다.

별도 검증 책임도 없는 단순 생성만 하고 있기 때문에
생성자를 사용하는 편이 더 단순하고 자연스러워 보여서 생성자를 사용하도록 수정해보겠습니다.

kang-hyungu · 2026-03-18T09:31:34Z

        return List.copyOf(players);
    }
+
+    public List<Player> getNonNaturalBlackJackPlayers() {


NonNaturalBlackJackPlayers
이게 뭘 의미하나요? 실제 게임에서 쓰는 표현인가요?
다른 팀원이 봤을 때 바로 파악하기 어려운 이름은 피하세요

해당 메서드를 고려하던 당시 제가 생각한 로직의 흐름이었던
'네츄럴 블랙잭이 아닌 플레이어들을 거르고, 나머지 플레이어들만을 활용하여 로직 실행'
을 메서드에 그대로 적다보니 생긴 네이밍입니다.
다시보니 의미를 담기 부족한 메서드라는 생각이 들어서 getPlayersInTurn 으로 수정해보았습니다.

jurlring

루디 안녕하세요!

구구마을 주민이셔서 코멘트가 이미 많이 달렸네요..ㅎㅎ 눈에 띄는 몇개만 더 추가해보았습니다!
시간 괜찮으실 때 확인해주세요 :)

jurlring · 2026-03-18T15:02:49Z

+public class BettingMoneyTest {
+
+    @Test
+    void 배팅금액은_0보다_커야_한다() {


좀 더 많은 엣지케이스가 있을 것 같아요!

테스트 파일을 파두고 엣지케이스를 추가하고자 하였는데 작업을 하다가 잊은 것 같습니다..
값 검증 뿐 아니라 계산 로직도 가지고 있어서 해당 부분 반영하여 테스트 케이스를 추가해보았습니다.

jurlring · 2026-03-18T15:45:01Z

+        if (player.isBust()) return BUST;
+        if (player.isNaturalBlackJack()) return BLACKJACK;
+        if (playerScore > dealerScore) return WIN;
+        if (playerScore < dealerScore) return LOSE;


딜러가 21점이 넘었을 때 요구사항이 반영되지 않은 것 같아요!

기능을 구현하다 딜러가 버스트 된 상황의 케이스를 놓친 것 같습니다.. 😂

초기 구현에서는 플레이어의 상태를 PlayerStatus로 분리하고,
naturalBlackJack 여부도 해당 상태 객체에서 관리하는 방향으로 설계했었습니다

놓쳤던 딜러 bust, 동시 블랙잭 등의 요구사항을 반영하면서
결과 판정 로직을 다시 살펴보니, naturalBlackJack은 플레이어 뿐 아니라 딜러에게서도 판단 되어야 하는 로직이라 PlayerStatus에서만 체크하는 것은 부자연스럽다고 판단되었습니다.

그래서 PlayerStatus에서 naturalBlackJack을 제거하고,
Participant에서 hasTwoCards()와 isBlackJack()을 기반으로 계산하도록 변경했습니다.

이 과정에서 PlayerStatus의 역할이 줄어들었기 때문에 해당 클래스를 제거하고
Player가 BettingMoney를 직접 가지도록 수정하였습니다.

이후 Result.from() 로직에서

딜러 bust 시 플레이어 승리

플레이어와 딜러가 동시에 블랙잭인 경우 무승부

등의 요구사항을 반영하도록 코드를 수정하였습니다..!

jurlring · 2026-03-18T15:46:06Z


 public class Deck {
-    List<Card> cards = new ArrayList<>();
+    final List<Card> cards = new ArrayList<>();


final은 잘 붙여주셨지만 접근제어자는 빠진 것 같아요 😢

접근제어자를 자꾸 빼먹네요.. 의식적으로 고쳐보겠습니다
접근제어자 반영해두었습니다..!

jurlring · 2026-03-18T15:53:49Z

 import java.util.ArrayList;
 import java.util.List;

 public class DtoFactory {


루디 재밌는 고민을 하셨군요! ㅎㅎ 필요한 고민이라고 생각해요~

정답은 아니지만 제 생각을 공유드리면요,

저는 DTO 생성은 도메인의 책임이 아니기 때문에, Players가 DTO 형태의 결과를 직접 만들어 반환하는 방식까지 가져갈 필요는 없다고 생각합니다.
이렇게 되면 도메인 객체가 DTO에 의존하게 되는데, 이는 레이어 아키텍처 관점에서 도메인 → DTO 방향의 역방향 의존이 생기는 구조라서 지양하는 것이 좋다고 생각해요!
또한 Players가 자기 데이터를 어떤 형태로 표현할지까지 알게 되는 것은 캡슐화를 강화하는 방향이라기보다는, 오히려 표현 계층의 책임까지 가져오는 책임 과잉에 가까운 설계라고 느껴집니다..!

jurlring

루디 안녕하세요!
블랙잭 미션 하시느라 정말 고생 많으셨습니다 :)
다음 미션도 이번처럼 잘 하실 것 같아요~ 응원하겠습니다!

tjdakf added 30 commits March 4, 2026 16:49

docs: 구현할 기능 목록 작성

4f3dfba

feat: 덱 생성 기능 및 테스트 추가

3bbf654

feat: 덱 셔플 기능 및 테스트 추가

63f556a

refactor: 패키지 이동

33badfd

test: 플레이어 등록 테스트 추가

e3e2962

feat: 플레이어 등록 기능 추가

c885805

feat: 딜러 생성

0a84a82

feat: 카드 돌리기 기능 추가

47dd596

feat: J, Q, K, A 점수 처리 기능 추가

6975c3f

refactor: 테스트 코드 리팩토링

a806680

refactor: 패키지 이동

426d150

test: 카드 점수 합산 테스트 추가

cb34963

feat: 카드 점수 합산 기능 추가

fddb58f

test: Ace 처리 테스트 코드 추가

969d642

feat: Ace 처리 기능 추가

2039b00

refactor: 점수 계산 기능 통합

2892a54

feat: 버스트 판정 기능 구현

1a8250b

feat: 실행 기능 연결

0610c26

refactor: 플레이어 등록 및 게임 준비 구조 개선

d9861e2

test: 게임 초기화 데이터 전달 테스트 추가

c876868

feat: 게임 초기 데이터 전달 기능 추가

e4516ed

test: 블랙잭 확인 테스트 추가

5984dcf

feat: 블랙잭 확인 기능 추가

86e65ea

test: 블랙잭 확인 기능 테스트 케이스 추가

87d0052

feat: 사용자 입력에 따른 분기처리 추가

00142ff

test: 딜러가 카드를 받을 수 있는지 확인 테스트 추가

7c6c131

feat: 딜러가 카드를 받을 수 있는지 확인 기능 추가

f4ff0ab

feat: 딜러 드로우 기능 추가

034a4da

feat: 최종 승패 출력 기능 구현

e28165f

feat: 게임 초기화 정보 입출력 기능 구현

50b2d81

Seonwu-K added 8 commits March 16, 2026 21:42

refactor : DtoFactory에 Participant 활용하여 중복 코드 제거

ad251f5

refactor : hand 계산 로직 캡슐화

2048dde

refactor : 사용하지 않는 toString 제거

2a52494

refactor : betting money를 다루는 일급 객체 추가

a123b83

test: BettingMoney 사용하는 테스트 코드 오기입 수정

6e9d2c5

refactor: final 적용

f8c8092

refactor: 미사용 import 제거

7dee081

refactor: 이름 검증을 위한 Name 객체 도입 및 검증 책임 이동

6aef9d4

Seonwu-K requested review from jurlring March 16, 2026 14:00

jurlring requested changes Mar 17, 2026

View reviewed changes

Seonwu-K added 2 commits March 18, 2026 15:45

refactor: 초기 카드 세팅 로직을 Participant로 추상화하여 DtoFactory 중복로직 제거

e01f060

refactor: 베팅머니 데이터 타입 long으로 수정

1caa6df

kang-hyungu requested changes Mar 18, 2026

View reviewed changes

jurlring requested changes Mar 18, 2026

View reviewed changes

Seonwu-K added 13 commits March 19, 2026 13:18

refactor: 플레이어 등록 메서드 depth 리팩터링

33b9e8f

refactor: 네츄럴 블랙잭이 아닌 플레이어 메서드 이름 변경

e01d179

refactor: playPlayerTurn 메서드명 수정

4c13325

refactor: Result if문 중괄호 작성

8429e89

refactor: bettingMoneyList 이름 수정

1ced2bc

refactor: GameManager 네이밍을 블랙잭 용어로 수정

10f0ad3

refactor: 초기 핸드 카드 숫자를 별도 규칙 객체 상수로 분리

9d3cd88

refactor: 플레이어 카드 추가 메서드 네이밍 수정

09ab050

refactor: getHandToString 네이밍 수정

0ce9b00

refactor: Players 팩토리 메서드 제거

4762f61

refactor: PlayerStatus제거 및 딜러 버스트 & 네츄럴 블랙잭 상황 추가

03893cd

refactor: Deck 필드 접근제어자 추가

d19358d

test: 베팅머니 테스트 케이스 추가

20893de

jurlring approved these changes Mar 19, 2026

View reviewed changes

jurlring merged commit 2a70bc4 into woowacourse:seonwu-k Mar 19, 2026

	List<BettingMoney> bettingMoneyList = new ArrayList<>();
	List<BettingMoney> bettingMoneys = new ArrayList<>();

		@@ -56,15 +67,24 @@ private void initGame() {
		}

		private void playPlayerTurn() {

Conversation

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

Uh oh!

체크 리스트

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

블랙잭2 PR 리뷰 요청

리뷰 요청

1. Controller 도입에 대한 고민

질문

2. 설계 결정을 내릴 때의 기준에 대한 고민

질문

3. 테스트와 설계의 관계에 대한 고민

질문

4. 미션 요구사항과 도메인 설계 기준이 충돌할 때의 판단 기준

질문

마지막으로

Uh oh!

jurlring 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!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kang-hyungu 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!

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!

Seonwu-K Mar 19, 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!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jurlring left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Seonwu-K commented Mar 13, 2026 •

edited

Loading

Seonwu-K Mar 19, 2026 •

edited

Loading