[🚀 사이클1 - 미션 (블랙잭 게임 실행)] 테리 미션 제출합니다. by Yeji-Kim-Erica · Pull Request #1020 · woowacourse/java-blackjack

Yeji-Kim-Erica · 2026-03-08T15:23:38Z

들어가며..

안녕하세요, PK! 리뷰이 테리입니다.
바쁘신 와중에도 시간 내어 리뷰에 참여해주셔서 감사드립니다.
가감 없이 부족한 부분들에 대해 알려주시길 부탁 드립니다.
최선을 다해 개선하고 공부하겠습니다. 🙇‍♂️

체크 리스트

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

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

이번 미션은 페어 프로그래밍 과정에서 치열한 설계 토론이 오갔습니다.
그 과정에서 제가 겪었던 패러다임의 충돌과 고민에 대해 PK의 조언을 구하고 싶습니다.

고민했던 부분

디자인 패턴의 적용, 어디까지가 적절한 선택인가?

이번 미션에서 Facade, Observer 등의 디자인 패턴을 도입할 것을 제안해준 페어 덕분에 해당 패턴들을 처음 접하게 되었습니다.
개인적인 판단으로는 도메인과 뷰, 컨트롤러 정도가 존재하는 구조가 이번 미션의 규모에서 가장 적합하다고 생각해 해당 의견에 대해 반대 의견을 내기도 했는데요.

Facade패턴의 경우, 페어가 주장했던 서비스 클래스들을 한 데로 묶는 GameServiceFacade와
제가 주장했던 Deck, Players 등을 한 데로 묶는 Game 클래스가 지향하는 바가 비슷하다고 생각했습니다.
또한, 서비스 계층의 경우, 실제로 추후 스프링에서 싱글톤으로 생성된다는 점을 고려했을 때,
GameService 등의 서비스에서 Deck, Players등을 필드멤버로 가지는 것은 전역 자원의 위험성 때문에 적합하지 않다고 판단했습니다.
게임의 로직 및 상태를 관리하는 것은 Game 도메인 클래스가 맡는 것이 적합할 것이라는 생각이 들어서 그렇게 코드 구현을 진행했습니다.

Observer 패턴의 경우, 처음엔 순차 로직인 블랙잭 미션에서 필요한 내용은 아니라고 생각해서 반대했다가,
열린 마음으로 새로운 영역에 도전해보는 것이 배움을 목적으로 한 우테코 과정에서 필요한 태도라고 판단해
해당 패턴을 채택하는 방안에 합의해 구현을 진행했습니다.
구현 과정에서 Controller와 Observer의 경계가 모호해지는 지점이 생겼고, 저의 의문에 페어가 새로운 방식을 제안하면서 Delegate 패턴을 또 새롭게 접하게 되었습니다.
처음에 ObserverImpl로 구현했던 메서드를 Controller로 옮기면서 Controller가 해당 인터페이스를 구현하도록 코드를 수정했고, Observer를 Delegate으로 인터페이스명을 변경하면서, 최종적으로 위임(Delegate) 패턴을 가진 아키텍처를 디자인하게 됐습니다.

이렇게 논의하고 토론하는 과정을 거치면서, 문득 '내가 너무 규칙과 틀에 얽매여 사고하고 있는 것은 아닌가' 라는 생각이 들었습니다. 저는 지금의 미션 구현이 결국은 웹 환경에 나가기 전 객체 지향적 구조를 연습하기 위한 하나의 연습 과정이라고 생각했고,
그로 인해 콘솔 환경이라는 '현재의 상황'에 집중하지 못하고 고정적인 사고 방식을 가지게 된 것 같습니다.

앞으로의 미션에 임할 때, 얼마나 열린 사고로 대해야 할까요?
'Service에 상태를 두면 웹에서 싱글톤으로 전역 자원화 되기 때문에 사용해서는 안된다.',
'순차 로직을 구현하는 현재의 미션에서는 이벤트 기반의 패턴을 사용하는 것은 과하다.'
제가 했던 말들을 돌아보면서 스스로가 도전적이고 자유로운 시도들을 가로막고 있는 것 같다는 느낌을 받았습니다.

디자인 패턴은 어디까지 적용해보는 것이 현명한 선택일까요?
콘솔 환경에서 웹을 고려하면서 웹 환경으로 인해 생겨난 관례와 규칙들까지 지키는 것이 맞는 선택일까요?

이 부분에 대한 PK의 생각이 궁금합니다!
리팩토링 때 시도하고자 하는 선택들, 적합한가?
- Deck의 분리:
  기존의 Deck 클래스가 두 가지 역할을 동시에 하고 있다는 생각이 드는데요,
  참가자들이 카드를 뽑아갈 때 사용할 전체 카드 덱과 참가자들 개개인이 가지고 있는 개인 카드 덱을 분리하고 싶습니다.
  전체 카드 덱을 관리하는 Deck과 참가자 개개인의 덱을 관리하는 Card의 일급컬렉션 Cards 클래스로 분리해
  자신의 덱에 카드를 추가하는 메서드와 카드의 총 점수를 계산하는 메서드를 Cards에 두려고 하는데,
  해당 사항을 리팩토링 때 적용해봐도 괜찮을까요?
- AceScoreDiscriminator 주입 받아오기:
  현재 Deck 클래스의 메서드 내부에서 AceScoreDiscriminator의 객체를 직접 생성해 사용하고 있는데요, 해당 부분을 의존성 주입으로 해결했으면 좋겠다는 생각이 있습니다.
  하지만 이 경우, Deck의 필드 멤버로 AceScoreDiscriminator 구현체를 받아오는 식인데
  현재 Deck이 Card의 일급컬렉션 클래스와 같이 쓰이고 있는 상황이라,
  일급컬렉션 클래스 내에 List를 제외한 또 다른 필드멤버를 두는 것이 맞는지 망설여집니다.
  메서드 파라미터로 해당 인스턴스를 받아오도록 처리하는 것 또한 결국엔 Deck의 메서드들을 호출하는 Game에서 AceScoreDiscriminator를 주입받아오도록 만들기 때문에 비슷한 이유로 반려되었는데요.
  AceScoreDiscriminator를 주입받아오는 것이 Deck, 리팩토링 후라면 Cards여도 괜찮은 건가요?
DTO의 도입, 적절한 선택인가?

왠지 도메인 이곳저곳에 getter 호출이 정해진 Depth가 없이 흩어져있는 형상이 불편하고 관리가 안된다고 느껴져서
차라리 DTO를 만들어 관리하자는 제안을 하게 되었는데요.
앞서 패턴을 사용하자는 제안 또한 오버 엔지니어링으로 판단하고 경계했던 만큼, 스스로가 불편을 느끼는 부분 또한 개선을 하는 것이 과연 정당한지 고민이 많이 되었습니다. 명확한 이론적/학술적인 이유 없이, 단지 '흩어져 있는 것이 보기에 좋지 않다, 유지보수하기 불편할 거 같다' 라는 감만으로 DTO를 만들자는 제안을 한 선택이 옳은 것인지 잘 모르겠습니다.
평소 개발하시는 과정에서 '왠지 이러면 안 될 거 같은데' 라는 생각으로 구조의 변경이나 분리를 결정하시는 경우가 있나요?
DTO까지 구성한 것이 오버 엔지니어링인지 아닌지 스스로 판단하기 힘들었던 이유가 뭘까요?
계속해서 개념의 기초와 근본을 다지다 보면 스스로의 선택에 자신을 가질 수 있게 될까요?
현재 아키텍처에서 DTO의 도입은 적절한 선택이 맞을까요?

딜러와 플레이어를 추가하였고, 그들의 공통 조상인 참가자를 추가함. 이후 카드와 카드들을 관리하는 덱의 정의를 추가함.

- 신규 덱 제공 기능 테스트 - 카드 뽑기 기능 테스트 추가(정상, 실패)

- 새로운 덱 제공 기능 - 카드 선택 기능 을 추가하였습니다.

Ace 값 판정과 전체 카드 점수 합 기능은 상호 의존성을 띄기 때문에 Ace는 제외한 카드 점수 합을 계산하는 기능을 추가함.

- add card score total sum feature - add bust discrimination feature

딜러 생성 시 필요한 파라미터 Deck의 인스턴스 종류를 명시함

공통 로직을 제거하기 위해 participant 추가

딜러만의 고유한 카드 추가 로직을 위해 별도의 메서드가 선언되어 있습니다. 차후 다른 개발자가 addCard 메서드 호출 시 현재 설계상으로는 오류가 발생하기 때문에 UnsupportedOperationException을 던지는 것으로 override 해두었습니다

기존 변수 deck의 모호성을 제거하기 위해 변경

딜러와 플레이어의 카드 추가 메서드를 단일화하여 차후 Participant 로 사용이 가능하도록 변경

- 클래스 내부에서 필드 멤버로 List 사용하는 것을 줄이기 위해 - 추후 참가자들의 전체 정보를 알아야만 계산할 수 있는 내용들을 다룰 클래스가 필요해서

BufferedReader 사용 시 IOException 관련 문제가 존재. 해당 문제를 핸들링 하는 것 보다 속도가 다소 느리더라도 Scanner 을 이용하여 문제를 핸들링 하지 않게 되는 것이 더 좋다고 판단하여 변경함

테스트 로직 작성의 용이성을 위해 mockito 추가

- 부모 클래스(Participants)가 자식 객체를 생성하는 구조적 모순을 해결하기 위해 해당 공통 클래스 제거 - 다수의 플레이어를 관리하는 일급 컬렉션 Players 클래스 신규 추가 - Game 도메인이 Dealer와 Players를 각각 독립적인 필드로 분리하여 관리하도록 객체 구조 개선 - 도메인 구조 변경에 따라 Dealer에 getCards() 메서드를 추가하고, OutputView 출력 로직 수정

가독성을 위해 메서드 분리를 진행함

This reverts commit 2fb6f4b.

- 사용자의 이해를 돕기 위해 기능 목록 위주로 체크 리스트 변경. - 클래스 다이어그램 추가.

pkeugine

안녕하세요 테리,
미션 진행하시느라 고생 많으셨어요.

정말 치열한 토론을 했다는 느낌이 리뷰하면서 저도 느껴졌습니다.

테리가 남겨주신 질문과 생각 모두 꼼꼼하게 읽어봤고,
진행하시면서 느꼈던 것들, 고민한 것들 등등 다 파악했어요.

그래도 리뷰는 리뷰이니, 제 솔직한 생각과 의견을 남겨보겠습니다.

우선,
리뷰가 제 기준에서 생각보다 오래 걸렸는데, 크게 두 가지 이유에서 였습니다 :

코드가 따라가기 힘든 구조입니다. 기능 대비 복잡도가 높다고 생각했어요.
테리와 페어의 생각을 따라가기가 힘들었습니다. 지금도 제가 다 이해했는지 확실하지는 않아요.

이를 간단하게 요약해보자면 생각이 많았다 인 듯 한데요,
테리가 말해주신 상황은 제가 어느정도 이해한 듯 해서,
리팩터링 하면서 이 부분은 해결해나갈 수 있을거라 생각합니다. :)

제 코멘트가 단호하거나 차갑게 느껴지는 경우도 있을텐데,
테리가 잘못해서가 아니라 이런 투 머치 띵킹 상황을 막고 싶은 마음에 강조하는거라고 봐주세요.

그렇다면 테리의 질문인 생각이 많아지는 것에 대해 어느정도 열린 마음을 가지고 있어야 하나...

어려운 문제예요.
그리고 어쩔 수 없는 부분인 것 같습니다.

오히려 지금 이 미션, 제 리뷰에 너무 무게를 두지 말고 전체를
다양한 것을 배우는 흐름이라고 보면 좀 더 열린 마음으로 새로운 영역에 도전해볼 수 있을 것 같네요.

그리고 반대로, 페어의 의견을 존중했다면
테리의 의견 역시 존중받아야 한다는 것을 잊지 않으셨으면 하고요.

실제로 코드 리뷰, 기술의 선택, 페어와의 협업에서 의견이 채택될 때,
기술적인 이유가 아닌 사회적인 이유 가 중요시 되는 경우가 (생각보다) 많습니다.
하지만 이를 반대로 얘기하면, 앞서 말했듯 테리의 의견 역시 그만큼 중요하다는거죠.

협업 할 때 서로 의견이 많이 다르다면, 한 발 물러설 줄도 알고, 한 편으로는 강하게 어필하는 순간도 경험해보시길 바랍니다.

일단 request changes 하고, 리팩터링 기대하겠습니다 :)
해피해킹하세요!!! 🔥 🔥 🔥

pkeugine · 2026-03-09T12:16:56Z

src/main/java/domain/Game.java

+    public void play(GameDelegate observer) {
+        List<Player> individualPlayers = players.getPlayers();
+        for (Player player : individualPlayers) {
+            while (!player.isBust() && observer.askDrawCard(player.getName())) {
+                player.addCard(totalDeck);
+                observer.showPlayerCards(ParticipantDto.from(player));
+            }
+        }
+        while (dealer.addCard(totalDeck).isPresent()) {
+            observer.showDealerOneMoreCardMessage();
+        }
+    }


play()는 현재 for -> while 구조라 indent depth 1 제약을 지키지 못하고 있어요.

이번 PR은 설계 고민이 정말 많았는데,
그 전에 우선 명시된 프로그래밍 요구사항을 먼저 맞추는 게 더 중요하다고 생각해요.

가능하면 플레이어 순회와 한 사람의 턴 진행을 분리해서
깊이를 줄이는 방향으로 나눠보시면 좋겠습니다.

프로젝트의 다른 클래스들도 깊이, 그리고 10줄 요구사항 한 번 확인해주세요!

pkeugine · 2026-03-09T12:17:32Z

src/main/java/domain/Participant.java

+        this.deck.addCard(newCard);
+        return Optional.of(newCard);
+    }
+}


파일 끝에 빈 줄(trailing newline)이 없어요.

POSIX 표준에서는 텍스트 파일이 개행 문자로 끝나야 하고, Git diff에서 \\ No newline at end of file 경고가 뜨면서 diff가 지저분해져요.

IntelliJ 설정에서 Editor → General → Ensure every saved file ends with a line break를 켜두면 자동으로 처리돼요 👍

디테일한 리뷰 감사합니다!
말씀해주신대로 파일 끝에 개행 문자 추가하여 반영 완료했습니다.
IntelliJ 설정 팁까지 알려주신 덕분에 바로 적용해볼 수 있었습니다. 감사합니다!
앞으로는 파일 끝 개행 문자가 누락되는 일이 없도록 신경 써서 관리하겠습니다!

pkeugine · 2026-03-09T12:18:45Z

src/main/java/domain/Game.java

+import controller.GameDelegate;
+import dto.GameResultDto;
+import dto.ParticipantDto;


이번 PR의 핵심 복잡도는 이 import 들부터 시작되는 것 같아요.
이름만 보면 Controller -> Game -> View처럼 한 방향으로 흐를 것 같은데,
실제로는 Game이 다시 controller 쪽 인터페이스와 DTO를 붙잡고 입력/출력 흐름까지 알고 있네요.

저는 여기서 Game이 controller 인터페이스와 DTO를 아예 모르도록 바꾸는 쪽을 먼저 추천드려요.
Game은 상태와 규칙만 관리하고,
입력/출력 흐름과 변환은 Controller가 순서대로 조립하게 해보면 어떨까요?

이에 대한 테리의 생각도 궁금해요 :)

pkeugine · 2026-03-09T12:22:23Z

src/main/java/controller/GameDelegate.java

+public interface GameDelegate {
+
+    /**
+     * 사용자의 입력을 요구.
+     */
+    List<String> askPlayerNames();
+
+    boolean askDrawCard(String playerName);
+
+    /**
+     * 각종 정보 출력
+     */
+    // 초기 카드를 보여주기
+    void showInitialParticipantCards(ParticipantDto dealerDto, List<ParticipantDto> playerDtos);
+
+    // 참가자 한명의 카드를 보여주기
+    void showPlayerCards(ParticipantDto participantDto);
+
+    // 딜러가 카드 한 장 더 받았음을 보여주기
+    void showDealerOneMoreCardMessage();
+
+    // 게임의 결과를 보여주기
+    void showGameResult(GameResultDto resultDto);
+}


PR 본문에서 적어주신 흐름을 보면,
처음에는 Observer로 시작했다가 구현 과정에서 controller와의 경계가 흐려졌고,
그걸 풀기 위해 Delegate로 이름과 구조를 다시 옮기신 거죠?
(아니라면 알려주세요 ㅋㅋㅋ 제가 제대로 이해하지 못했을 수도 있어요)

그런데 제가 보기에는 패턴 이름이 Observer에서 Delegate로 바뀌었는지가 핵심이라기보다,
그 과정을 거친 뒤에도 읽는 사람이 여전히 "이게 지금 controller인가, observer인가, delegate인가?"를 헷갈린다면
현재 문제 규모에서 그 추상화가 구조를 더 명확하게 만들지 못했다는 뜻일 수 있어요.

지금 구조라면 저는 두 방향 중 하나를 더 추천드려요 :
하나는 이 interface를 없애고 Controller가 직접 흐름을 조립하게 두는 것,
다른 하나는 정말 유지하고 싶다면 input 과 output 역할을 분리해서 각각 더 분명한 인터페이스로 나누는 것입니다.

이왕이면 저도 의도와 동작 방식을 이해하기 쉬운 방식이었으면 해요.
지금은 제가 느끼기엔 설명과 구현이 모두 이해하기 어려운 구조예요.

pkeugine · 2026-03-09T12:24:05Z

src/main/java/domain/Game.java

+    public void play(GameDelegate observer) {
+        List<Player> individualPlayers = players.getPlayers();
+        for (Player player : individualPlayers) {
+            while (!player.isBust() && observer.askDrawCard(player.getName())) {
+                player.addCard(totalDeck);
+                observer.showPlayerCards(ParticipantDto.from(player));
+            }
+        }
+        while (dealer.addCard(totalDeck).isPresent()) {
+            observer.showDealerOneMoreCardMessage();
+        }
+    }


play() 안에서 observer.askDrawCard(player.getName()) 와 같은 view 로직을 직접 호출하고 있네요.
그렇다면 지금 게임 진행 로직은 도메인 안에 있지만,
실제 흐름 제어는 UI 입력에 묶여 있는 셈이에요.

이럴 때는 domain이 스스로 진행하기보다,
controller가 "입력 받기 -> domain 호출" 순서를 조립하는 쪽이 더 깔끔하다고 생각해요.
즉 Game은 턴 진행 규칙만 알고,
질문을 언제 던지고 결과를 언제 보여줄지는 Controller가 맡는 방향을 추천드려요.

전반적으로 Game 이 입출력을 몰라도 되는 구조로 바꿔보면 어떨까요?

pkeugine · 2026-03-09T12:58:24Z

src/test/java/domain/DeckTest.java

+
+            return new ArrayList<>(List.of(spadeJ, clover5));
+        }
+    };


테스트에서 이런 anonymous CardCreationStrategy 구현체가 계속 반복되네요.

우선 사용한다면, 이보다 더 간결한 문법을 사용하실 수도 있습니다.
어떤 방법이 있는지 한 번 알아보시길 바라요.

그런데 저는 더 나아가 해당 전략 관련 클래스 (전략패턴이라고 부르기엔 제대로 도입되지는 않은 것 같습니다) 를
더 단순하게 만들 수 있을 것 같다는 생각도 들어요.

테리가 말씀해주신 Hands 객체가 생긴다면 어느정도 해소될 것 같네요.
그 구조가 만들어지면 Player 를 생성할 때 이런 전략을 매번 구현할 필요가 없어질테니까요 :)

pkeugine · 2026-03-09T13:02:28Z

src/test/java/domain/GameTest.java

+import org.mockito.Mock;
+import org.mockito.junit.jupiter.MockitoExtension;
+
+@ExtendWith(MockitoExtension.class)


Mockito 를 사용해주셨네요.
해당 라이브러리는 어떤 기능을 가지고 있고, 어떨 때 사용하면 유용한지 말해주세요!

이 질문을 남기는 이유는, 잘못되었다기보다는
저는 개인적으로 도입하지 않아도 괜찮은 프로젝트 규모라고 생각했기 때문이에요.

pkeugine · 2026-03-09T13:05:53Z

src/test/java/controller/BlackJackControllerTest.java

+    //private List<Card> createSampleCards() {
+//        CardShape[] shapes = CardShape.values();
+//        CardContents[] contents = CardContents.values();
+//
+//        List<Card> sampleCards = new ArrayList<>();
+//        for (CardShape cardShape : shapes) {
+//            for (CardContents content : contents) {
+//                sampleCards.add(new Card(cardShape, content));
+//            }
+//        }
+//
+//        return sampleCards;
+//    }


주석 처리된 코드는 지워주세요.
이런 미완성된 모습은 리뷰 반려 이유가 되기도 합니다.

pkeugine · 2026-03-09T13:06:42Z

src/main/java/view/OutputView.java

+    private static final String DELIMITER = ", ";
+    private static final String NAME_PROMPT = "게임에 참여할 사람의 이름을 입력하세요.(쉼표 기준으로 분리)";
+    private static final String INITIAL_CARD_SHARE = "딜러와 %s에게 2장을 나누었습니다.\n";
+    private static final String HIT_OR_STAND_PROMPT = "%s는 한장의 카드를 더 받겠습니까?(예는 y, 아니오는 n)\n";
+    private static final String ADDITIONAL_CARD_FOR_DEALER_DESCRIPTION = "딜러는 16이하라 한장의 카드를 더 받았습니다.";
+    private static final String PARTICIPANT_CARD_INFO_FORMAT = "%s카드: %s";
+    private static final String PARTICIPANT_CARD_INFO_FORMAT_LINE = "%s카드: %s\n";
+    private static final String PARTICIPANT_CARD_INFO_WITH_SUM_FORMAT = "%s - 결과: %d\n";
+    private static final String WIN_LOSS_RESULT_HEADER = "## 최종 승패\n";
+    private static final String WIN_LOSS_RESULT_FORMAT = "%s: %s\n";


OutputView에서는 메시지들을 거의 전부 파일 상단 상수로 빼두셨네요.
상수화 자체가 항상 나쁜 건 아니지만,
재활용되지도 않고 그 자리에서만 쓰이는 출력 문구라면 오히려 읽는 흐름을 끊기도 해요.

저는 여기서는 상수화보다 문맥 가까이에 두는 편이 더 읽기 쉬웠을 것 같아요.
정말 여러 곳에서 같이 쓰이는 문구만 남기고,
나머지는 사용하는 메서드 가까이로 되돌리는거죠.

이에 대한 테리의 솔직한 생각이 궁금한데, 어떻게 생각하시나요?

pkeugine · 2026-03-09T13:07:18Z

src/main/java/domain/CardShape.java

+public enum CardShape {
+    스페이드, 하트, 다이아몬드, 클로버
+}


저는 코드의 식별자(enum 상수, 클래스명, 메서드명 등)는 가능하면 영어로 통일하는 편이 더 낫다고 생각해요.
주석이나 사용자 출력은 한글이어도 괜찮지만,
코드 이름까지 한글이 들어가면 검색하거나, 테스트를 쓰거나, 직접 타이핑하면서 읽을 때 조금씩 불편해질 수 있거든요.

특히 CardShape는 Card, DTO, 테스트 곳곳에서 계속 쓰이는 이름이라서,
한글로 두었을 때 얻는 장점보다 영어로 통일했을 때 읽기 쉽고 맞춰 가기 쉬운 장점이 더 커 보여요.

Git diff 경고 방지를 위해 파일 끝 빈줄을 추가함

Yeji-Kim-Erica added 30 commits March 4, 2026 17:44

docs(README): add feature list

4d992f1

feat: add name input feature

37074a5

feat: add hit or stand input feature

070e5ba

feat: add game instruction output feature

0e85d53

docs : add domains features

f121afe

딜러와 플레이어를 추가하였고, 그들의 공통 조상인 참가자를 추가함. 이후 카드와 카드들을 관리하는 덱의 정의를 추가함.

test : add card contents test

e2d44c2

feat : add card and enum class for card

8582f6d

test : add deck creation test

11fb3ea

feat : add deck creation feature

644c62b

docs : check what I implemented

b80246c

test : add deck test

3a01775

- 신규 덱 제공 기능 테스트 - 카드 뽑기 기능 테스트 추가(정상, 실패)

feat : add DRAW_CARD_OUT_OF_RANGE

ab9bdbc

feat : add new deck features

8571797

- 새로운 덱 제공 기능 - 카드 선택 기능 을 추가하였습니다.

test: add participant deck creation and cards draw

b8d0a79

feat: add participant deck creation feature

6c65b8c

docs: check what I implemented

fac0ae3

refactor: seperate card creation responsibility

4772f2a

refactor: change ace default card score

debd9c0

feat: add card sum calculation excluding aces

5598c39

Ace 값 판정과 전체 카드 점수 합 기능은 상호 의존성을 띄기 때문에 Ace는 제외한 카드 점수 합을 계산하는 기능을 추가함.

feat: add ace score discrimination feature

12c235e

feat: add card score related feature

430f617

- add card score total sum feature - add bust discrimination feature

feat: add card addition feature

80d3469

feat: add conditional card drawing feature for dealer

200ce6c

refactor: change dealer constructor parameter name

b79ef33

딜러 생성 시 필요한 파라미터 Deck의 인스턴스 종류를 명시함

test: add dealer constructor test

160cc41

refactor : separate common logic between Dealer and Player

7721bca

공통 로직을 제거하기 위해 participant 추가

fix : fix typo

f6ed131

refactor: delete '\n'

638445c

feat: add Player class

30ef159

Yeji-Kim-Erica added 23 commits March 6, 2026 17:30

docs: check what is implemented

61377fc

refactor : change variable name to totalDeck

3790ad7

기존 변수 deck의 모호성을 제거하기 위해 변경

fix : integrate adding card feature

ee65136

딜러와 플레이어의 카드 추가 메서드를 단일화하여 차후 Participant 로 사용이 가능하도록 변경

feat : add createParticipants feature

08f1a5e

fix: refactor participant list to a first-class collection

a78de9b

- 클래스 내부에서 필드 멤버로 List 사용하는 것을 줄이기 위해 - 추후 참가자들의 전체 정보를 알아야만 계산할 수 있는 내용들을 다룰 클래스가 필요해서

feat: add game creation feature

627bee8

feat : add constraint to Participants number

9e65f06

build : add mockito for test logic

00e8662

테스트 로직 작성의 용이성을 위해 mockito 추가

feat: add initial card share detail printing feature

ec4784b

feat: add name validation feature

44e10cf

feat: add create result feature

223b55e

refactor: divide card creation method

ce29cb5

가독성을 위해 메서드 분리를 진행함

refactor: introduce DTO

9196820

feat: bring in Delegate method

aa38ca7

feat: add card info and game result printing feature

60d6dfb

feat: add card info and game result printing feature

2fb6f4b

Revert "feat: add card info and game result printing feature"

9b63e36

This reverts commit 2fb6f4b.

Revert "feat: add card info and game result printing feature"

4283373

This reverts commit 2fb6f4b.

feat: add flow control logic and game progression feature

d4c97f6

feat: assemble components for running

c8818cd

docs: update README

3e4bd49

- 사용자의 이해를 돕기 위해 기능 목록 위주로 체크 리스트 변경. - 클래스 다이어그램 추가.

pkeugine requested changes Mar 9, 2026

View reviewed changes

style: 파일 끝 개행 추가

4732c83

Git diff 경고 방지를 위해 파일 끝 빈줄을 추가함

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

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

[🚀 사이클1 - 미션 (블랙잭 게임 실행)] 테리 미션 제출합니다.#1020
Yeji-Kim-Erica wants to merge 54 commits intowoowacourse:yeji-kim-ericafrom
Yeji-Kim-Erica:step1

Yeji-Kim-Erica commented Mar 8, 2026 •

edited

Loading

Uh oh!

pkeugine left a comment •

edited

Loading

Uh oh!

pkeugine Mar 9, 2026

Uh oh!

pkeugine Mar 9, 2026

Uh oh!

Yeji-Kim-Erica Mar 10, 2026

Uh oh!

pkeugine Mar 9, 2026

Uh oh!

pkeugine Mar 9, 2026

Uh oh!

pkeugine Mar 9, 2026

Uh oh!

pkeugine Mar 9, 2026

Uh oh!

pkeugine Mar 9, 2026

Uh oh!

pkeugine Mar 9, 2026

Uh oh!

pkeugine Mar 9, 2026

Uh oh!

pkeugine Mar 9, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Conversation

Yeji-Kim-Erica commented Mar 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

들어가며..

체크 리스트

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

고민했던 부분

Uh oh!

pkeugine left a comment • 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!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Yeji-Kim-Erica commented Mar 8, 2026 •

edited

Loading

pkeugine left a comment •

edited

Loading