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

JunHyung1206 · 2026-03-14T04:19:02Z

체크 리스트

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

사이클 1 피드백 반영

딜러에서 뷰 로직에 가까운 name을 분리하였습니다.
매직넘버를 상수화하였습니다.
점수 계산 로직을 player가 아닌 외부에서 하도록 하였습니다.
Dto 네이밍을 google java style guide에 맞게 변경하였습니다.

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

상태 패턴의 적용

사실 빠르게 구현하고 피드백 받는 것이 구현원칙이었지만, 미션 부분에 상태 패턴의 적용에 대해서 좀 더 학습을 해보고 싶었습니다.
이전까지 객체 지향을 한다고 해도, 책임정도만 고민을 했었지, 다형성을 잘 활용하는 방법을 잘 모른다고 생각을 했었습니다.
이번에 상태 패턴을 적용해보면서 제가 느낀 점은 다음과 같습니다.
장점
- 다형성을 활용했기 때문에, 조건문 분기가 매우 축소된다.
- 컨트롤러가 가벼워진다.
- 다른 곳에서 이용할 때, 그 상태가 무엇인지 꼭 알아야할 필요가 없다. (다형성의 제일 큰 장점이라고 생각합니다.)
단점
- 디버깅 할 때 계속 파고들며 봐야하기 때문에 꽤 피곤하다.
- 새로운 조건이 생성될 때 클래스를 새로 만들어야한다,
- 상태를 계속 판별해야하는 로직에 대해서 (이번 미션의 경우 딜러의 히트, 블랙잭 판별 등)에서 계속 확인을 해야했기 때문에 굳이라는 생각이 많이 들었습니다.
- 상태를 한번 감쌌기 때문에, 위임해서 getter로 계속 들고 오는 경우가 많이 발생했었습니다.
이런 이유로 if문에 비해서 더 효용성이 있는가는 아직 의문입니다.

테스트 코드의 작성

단위 테스트는 도메인이 하고자 하는 바가 분명하기 때문에, 작성하기가 쉬웠습니다.
하지만 흐름을 판별하는 테스트는 어떻게 작성할지가 고민이었습니다.
가령 딜러가 블랙잭이라면, 플레이어의 행동은 멈추고 바로 점수 계산로직을 실행해야하는데, 이 부분을 어떤 식으로 테스트를 할 수 있는지 궁금합니다.

pkeugine

안녕하세요 녀녕,
미션 잘 진행해주셨네요.

이번 미션에서 제가 남긴 코멘트들의 큰 흐름은 다음과 같습니다 :

프로젝트의 전체적인 관리에 대하여 (커밋, 컨벤션, 이전 PR 에서 나눴던 얘기들 등)
도입해보신 state 와 객체간 역할에 대하여
테스트 관련하여 녀녕이 남겨주신 질문과 제가 상각하는 다음으로 해야할 일

프로젝트가 가독성 면에서 읽는데 부담이 없었고,
이 부분은 계속 유지해보면 정말 좋을 듯 싶어요!

질문이나 의견이 있다면 언제든 편하게 DM 또는 코멘트 남겨주세요.
이제 해당 미션 완료까지 얼마 남지 않았으니 조금만 더 화이팅해봅시다.
해피해킹하세요!! 🕺 🕺 🕺

pkeugine · 2026-03-14T07:28:25Z

.github/pull_request_template.md

- [ ] [프롤로그](https://prolog.techcourse.co.kr)에 셀프 체크를 작성했나요?
-  - <!-- 작성한 셀프 체크의 링크를 남겨주세요. -->
-
-
-## 객체지향 생활체조 요구사항을 얼마나 잘 충족했다고 생각하시나요?
-
-### 1~5점 중에서 선택해주세요.
-
- [ ] 1 (전혀 충족하지 못함)
- [ ] 2
- [ ] 3 (보통)
- [ ] 4
- [ ] 5 (완벽하게 충족)
-
-### 선택한 점수의 이유를 적어주세요.
-
-<!-- 이유 작성 -->
-


해당 내용을 제거한 이유가 궁금해요.
몇몇 다른 크루들도 제거하는 듯 하던데, 이제는 사용하지 않는 템플릿 내용인가요?

우테코 깃허브 쪽에서 일괄적으로 제거한 것 같습니다.

pkeugine · 2026-03-14T07:28:28Z

src/main/java/controller/GameController.java

@@ -1,10 +1,14 @@
 package controller;


이번 PR은 기능 추가 규모에 비해 commit 수가 굉장히 많은 편이네요.
그리고 커밋 흐름이 조금 복잡하게 얽혀있어요.

학습해보면서, 또는 이것 저것 도전해보며 다양한 시도를 해보는 것은 좋아요.
하지만 작업을 repository에 반영 할 때는, commit 을 정리하거나 꼭 필요한 것들만 남기면 좋겠어요.

이렇게 생각하는 이유는 다음과 같습니다 :

리뷰어가 commit 단위로 무언가를 확인하려고 할 때, 너무나도 많은 시간을 투자해야 해요.

squash merge 가 아니라면, 최종 코드베이스의 git history에 이 많은 커밋들이 그대로 적용돼요.

나중에 롤백을 하거나, 기능 단위로 배포 할 것들을 결정할 때 앞서 말한 시간 투자를 똑같이 해야하는 일이 발생해요. 커밋을 누락해서 문제가 발생할 가능성도 굉장히 높아지고요.

객체지향, 테스트와 마찬가지로 git 커밋 관리도 굉장히 중요한 역량 중 하나예요.

물론 어떤 프로젝트인지에 따라, 또는 팀 컨벤션에 따라 커밋 관리를 그리 중요하게 생각하지 않을 때도 있어요. 하지만 이 참에 git 이 제공하는 기능에 대해 알아보고, 꼭 필요한 것들만 담아서 커밋 기록을 잘 쌓아보는 경험을 해보면 좋을 것 같네요 :)

추가로, e8f7aa8 의 메시지는 betting -> batting 오탈자 수정이라고 적혀 있는데,
실제 변경은 오히려 batting을 betting으로 되돌리는 쪽에 더 가깝네요.
(그리고 밑에서도 얘기하겠지만, git 흐름이 복잡하게 꼬이면서 해당 커밋이 반영되지 않았어요.)

그리고 fix: final로 수정 같은 메시지는 지금 당장은 쓰기 편하지만,
나중에 히스토리를 다시 볼 때는 '어디 final 을 어떻게 수정했다는거지?' 라는 생각이 들어서 거의 정보를 주지 못하더라구요.

커밋 메시지를 의도에 맞게 잘 작성해보죠 :)

팁을 드리자면,

이런 히스토리 정리는 git 기능을 조금만 익혀도 체감이 확 달라져요.

지금 단계에서는 git rebase -i 정도만 알아도 commit 순서 변경, squash, 메시지 수정이 가능하고,
git cherry-pick은 필요한 commit만 다른 브랜치로 가져올 때 유용해요.

우선 이 두 가지부터 가볍게 학습해보면 다음 PR이 훨씬 깔끔해질 거예요. 특히 rebase 를 활용한 git 관리 연습을 조금씩 해보시면 좋을 듯 하네요. :)

처음에 조금만 변경해도 커밋을 하라고 해워서 습관적으로 했었습니다. 리뷰하는 입장에서는 이 과정이 매우 피곤할 수 있겠다라는 생각이 듭니다. 그리고 revert를 사용을 했다면, 이러한 과정이 좀 더 정리가 되었을 것 같습니다.
좀 더 기능 단위로 묶어서 진행을 하고 커밋 메시지도 좀 더 자세히 적는 것을 목표로 해야겠습니다.

그리고 오탈자 수정 같은 경우 푸시를 한 후 뒤늦게 발견을 해서 고치는 것이 힘들었습니다. 앞으로, 커밋 할 때도 메시지를 꼼꼼히 확인하고, 사실 본문 내용도 같이 적어야하는데, 그냥 제목만 짓고 넘겨버리자, 했던 부분이 반성하게 됩니다. 리뷰받았던 순간부터 고쳐보도록 하겠습니다.

rebase는 기능을 알고는 있는데, 3-way merge를 할 때, 충돌을 해결을 잘 못하면 어떡하지, 이전으로 돌아가기 힘들 것 같은데? 라는 생각을 가지게 되어서, 일반 merge로 습관을 들였었습니다. 좀 더 깊게 공부를 해야할 것 같습니다.
다음 주 테코톡 주제로 기초 깃명령어로 선정을 하긴 했지만, appendix 느낌으로 추가할 예정입니다.
자세히 공부할 명령어 : rebase, cherry-pick, revert

pkeugine · 2026-03-14T07:51:53Z

src/main/java/domain/status/Finished.java

+    @Override
+    public Status stay() {
+        throw new IllegalStateException("이미 턴이 끝난 상태입니다.");
+    }


Finished에서 유효하지 않은 상태 변경을 막아주신 점 좋아요 👍

다만 지금 테스트를 보면 정상 흐름은 검증하고 있지만,
이미 종료된 상태에서 다시 draw()나 stay()를 호출했을 때 예외가 나는 경로는 직접 보호되고 있지 않네요.

상태 패턴을 도입하셨다면 이런 예외 경로도 중요한 규칙이니,
같이 테스트해보면 더 안심이 될 것 같은데, 어떻게 생각하시나요?

전체적으로 domain 관련 테스트는 탄탄하게 만드는 것을 목표로 해보면 좋을 것 같아요.

상태 패턴을 객체의 변화에만 신경을 썼는데, 상태 패턴에 대해서도 검증을 해야겠네요.
아직 적용이 익숙하지 않은 단계이지만, 적용과 검증 쪽을 더 채워나가도록 하겠습니다.

상태의 전이와 오류상황에 대해서 테스트를 진행하였습니다.

pkeugine · 2026-03-14T07:52:39Z

src/main/java/domain/status/Status.java

+
+    public abstract boolean isRunning();
+
+    public abstract double earningsRate(Status dealerStatus);


지금은 Status가 상태 전이와 정산 규칙을 같이 들고 있어서,
Start, Running처럼 아직 게임이 끝나지 않은 상태도 earningsRate()를 구현해야 하네요.

이 경우에는 Status는 상태 변화만 담당하고,
정산은 Player나 별도 계산 객체가 맡도록 분리하면 더 자연스러울 수도 있어요.
그러면 정산할 수 없는 상태가 억지로 예외를 던질 필요도 없어지거든요.

녀녕의 생각은 어떤지 궁금하네요!

이 부분도 사실 고민이었던게, 참가자가 상태를 가지는 것은 자연스럽다고 생각합니다. 그 과정에서 확인할 때 다운 캐스팅이 일어나지 않을까라는 것이 제 고민이었습니다.
결국 상속을 사용해서, 아래에 대한 클래스에 의존하지 않겠다는 것이 목표인데, 다운 캐스팅을 하면 의미가 있을까라는 고민에서, 이러한 코드가 나왔었습니다.

만약 한다면, Finished된 상태만 받아 정산하는 객체를 맡아서 분리하는 것이 좀 더 책임이 명확해질 것 같습니다. 이 방향대로 진행해보도록 하겠습니다.

Finished 상태만 받아 정산하기 보다는, 플레이어와 딜러에서 정보를 받아, BettingResult를 반환하는 Enum을 정의하여 그 안에서 처리할 수 있도록 하였습니다.

각 상태 내에서 정산 규칙까지 모두 담당하는 것보다는, 하나의 정산 객체를 만들어서 관리하는 것이 좀 더 응집도가 높은 느낌이었습니다.

pkeugine · 2026-03-14T07:52:41Z

src/main/java/domain/status/Status.java

+        return cards;
+    }
+
+}


파일 끝에 빈 줄(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 설정을 많이 배워가게 되네요. 감사합니다.

src/main/java/util/InputBattingParser.java

src/main/java/domain/betting/Money.java

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

src/main/java/dto/GameScoreDto.java

pkeugine · 2026-03-14T08:49:25Z

src/test/java/domain/participant/PlayerTest.java

+import org.junit.jupiter.api.DisplayName;
+import org.junit.jupiter.api.Test;
+
+class PlayerTest {


Q. 흐름을 판별하는 테스트는 어떻게 작성할지가 고민이었습니다.

좋은 고민이에요.

이런 흐름 테스트가 어려운 경우에는,
보통 Controller를 직접 테스트하는 것보다
그 흐름을 담당하는 규칙을 테스트 가능한 객체로 한 단계 더 분리할 수 있는지 먼저 보게 돼요.

예를 들어
"딜러가 블랙잭이면 플레이어의 행동을 멈추고 바로 정산한다"
는 규칙이 중요하다면,
이 규칙을 Controller가 아니라 다른 객체가 맡도록 만들었을 때
훨씬 검증하기 쉬워질 수 있거든요.

물론 Controller의 흐름 자체를 확인하는 테스트도 가능해요.
테스트에는 단위 테스트만 있는 것이 아니니까요.

다만 지금 단계에서는 흐름 전체를 억지로 테스트하려 하기보다,
도메인 규칙이 충분히 잘 분리되어 있는지,
관련 테스트들이 잘 마련되어 있는지를 먼저 보는 편이 더 중요하다고 생각해요.
예외 상황들, 경계선 같은 것들을 잘 커버하는 것도 굉장히 중요하고요.

결국 흐름도 도메인 객체들의 상호작용으로 만들어지는 거라서,
도메인이 단단해질수록 흐름 테스트도 훨씬 쉬워지거든요.

위에 남긴 코멘트들, 나름 녀녕의 이 질문을 고려해서 작성해봤어요.
하나씩 정리하다 보면, 자연스럽게 지금보다 더 테스트하기 쉬운 구조로 가까워질 거예요 . :)

우선 도메인과, 서비스, 컨트롤러의 책임을 좀 더 명확히 해보는 과정이 더 중요한 것 같습니다.
도메인 쪽에서 테스트하기가 어려우면, 이게 책임이 너무 많은 단계가 아닌가 생각을 하고,
이를 처리하는 곳을 분리해야겠다고 느껴졌습니다.

또한 서비스는, 도메인을 직접 조작하기 보다는, 도메인에 맡기고, 결과만 반환할 수 있도록 하는 것이 중요하다고 생각이 들었습니다.

- List를 매개변수로 받는 생성자는 테스트 코드에서만 사용되므로 이를 삭제 - 테스트 코드에서는, makeHandCards라는 매서드를 활용하여, 의도했던 대로 동작하는 HandCards를 만들도록 구성

- 각 상태에 구현된 earningsRate 함수 삭제 - GameResult에서 이를 계산하도록 구현 - Batting에서 betting으로 오탈자 수정 - Participant에서 버스트와 블랙잭 판별하도록 수정

- Status에 isRunning, isBust, isBlackJack 매서드 추가 - Participant에서 판정은 직접 카드를 들고오지 않고 status로 직접 판단하도록 변경 - PlayerHandScoreDto에서 플레이어에서 직접 접근하도록 변경

- BettingCalculateService::getBettingResult - GameController::playerBetting - InputBettingParser::parseBettingMoney - Output::printBettingResults

- endGameImmediately는 서비스에서 처리하도록 변경 - Players에서 실질적으로, 전부 멈추도록 지시하고, Service에서는 이를 호출하는 형태로 수정 - 초기 카드 값을 배분하는 것도 Players에서 처리하도록 수정

- BettingResult로 이름 변경 - Players 패키지 participant로 변경

- 부동소숫점 방식보다, 정수로 처리한 후 100으로 나누는 것이 좀 더 정확할 것 같아서 판단 (소수점 버림 연산) - BettingResultTest에서 earningRate를 가져와서 계산하기 보다는, 그 자체의 계산에 대해서 테스트를 수행 - BettingResultTest의 중복된 객체 생성에 대해서 @beforeeach 사용 - 공백 수정

- 매개변수로 bettingResult를 사용하도록 변경 - Profit 내에서 수익을 계산하는 구조로 수정

- 카드로 String을 만드는 작업이 중복되어 processHandCards로 중복 로직 제거

- 각각 수익은 아래와 같다. - 이겼을 때 1배 - 비겼을 때 0배 - 졌을 때 -1배 - 블랙잭으로 이겼을 때 1배

- 1000원 단위로 베팅할 수 있도록 설정 - 최대 베팅 액수는 1억원으로 설정

- trim을 통해서 앞뒤의 공백을 제거 - 숫자가 아닌 다른 값이 나왔을 때, 숫자만 입력해달라고 메시지 변경 - 각 값에 대해서 테스트 추가

- 다음 테스트 전이를 어떻게 하는지에 대해 테스트 - 일어날 수 없는 행동에 대한 예외를 잘 반환하는지에 대해 테스트

- 베팅 금액 입력 받는 기능 구현 완료 반영 - 프로그래밍 요구사항 반영

- 딜러의 합이 17일 때 카드를 받지 않는 경우에 대해서 테스트 - 합이 21이더라도 카드가 세장일 때는 블랙잭으로 계산하지 않는 것에 대한 테스트

JunHyung1206 · 2026-03-15T09:45:15Z

안녕하세요 피케이

자세한 리뷰 감사합니다.
리뷰를 보면서, 어떻게 하면 좀 더 책임이 명확한 코드를 만들 수 있는지 인사이트를 많이 얻은 것 같습니다.
이번에 객체에 대해서 좀 더 책임을 어떻게 분리할 수 있는가에 대해서 많이 고민하게 되었습니다.
원래는 당연하게 했던 것도, 이걸 어디다가 작성하는게 좋을까 생각해보는 과정이 상당히 어려웠습니다.
아직은 그러한 사고과정이 좀 더 필요한 것 같습니다.
이번 고민의 흔적들을 기록해보면서, 다음 사이클에서는 좀 더 원활하고 깔끔하게 진행하도록 노력해보겠습니다.

다시한번 감사합니다.

아래는 리뷰 반영사항입니다.

리뷰 반영사항

수익률 계산 담당 객체 분리

Status의 earningRate 삭제
BettingResult가 수익률을 처리할 수 있도록 관리

Service 및 Players의 책임 분리

서비스에서는 Players에서 멈추도록 지시
실제로 stay를 하는 것은 일급 컬렉션인 Players가 담당
초기 카드를 받는 것도 Players가 하도록 수정

돈에 대한 규칙 추가

BlackJack일 때 1.5배를 하기 때문에, 이를 처리하는 방안이 필요
베팅 금액 단위를 1000원으로 설정하여 해결, (1.5배를 하더라도 정수로 나누어떨어짐)

돈 입력에 대한 처리 및 테스트 추가

trim()처리
공백이 포함된 숫자에 대해서 파싱이 되는지 테스트
숫자가 아닌 다른 문자의 입력에 대한 테스트
유효하지 않은 숫자에 대한 테스트

상태 전이에 대한 테스트 추가

각 상태가 올바르게 전이되는지 테스트
각 상태에서 동작하지 말아야할 함수가 동작했을 때 오류가 반환되는지에 대한 테스트

그외

List<Card>를 List<String>로 변환하는 유틸 클래스 추가

Jihyun3478 and others added 30 commits March 4, 2026 15:14

docs: 기능 목록 작성

46827cf

feat: 게임에 참여할 이름을 입력받는 기능 구현

fa3545b

feat: 각 플레이어의 이름을 쉼표를 기준으로 분리하는 기능 구현

0fa9d76

feat: 한 장의 카드를 추가로 받을지 여부를 입력받는 기능 구현

08a0d5f

feat: 카드 점수를 계산하는 기능 구현

e0e3e9c

feat: 초기 카드를 생성하는 기능 구현

a9b153c

feat: 카드를 섞는 기능 구현

81cf09d

feat: 버스트를 판정하는 기능 구현

f3b770a

docs: 기능 목록 업데이트

673c8b9

refactor: 이중 for문 stream으로 변환

7bf557d

feat: 예외로 Ace는 1 또는 11을 유리한대로 계산하는 기능 구현

0f6113a

feat: 플레이어 생성

1219979

feat: 카드를 한 장 뽑는 기능 구현

608e991

feat: 플레이어의 현재 보유 카드를 출력하는 기능 구현

ff51566

feat: 게임 진행 상황을 출력하는 기능 구현

1448ecf

feat: 초기에 플레이어가 카드 2장을 받는 기능 구현

5c5616e

fix: 게임 진행 상황 출력 기능 버그 수정

43cf9f3

feat: 딜러의 점수의 합이 16 이하이면, 카드를 한 장 받는 기능 구현

ffb8636

refactor: 메서드 분리

3352131

feat: 딜러는 처음에 받은 2장의 합계가 16 이하이면 1장의 카드를 받는 기능 구현

40b3539

docs: 완료된 기능 목록 수정

093cafe

fix: 버스트이면, 카드를 추가적으로 받지 않도록 수정

46f64d4

feat: 게임을 완료한 후 각 플레이어별로 승패를 출력하는 기능 구현

204b49e

branch merge

d86c65d

fix: 버스트 및 출력 로직 누락 수정

a59d954

feat: 플레이어의 점수가 버스트일 경우, 버스트로 출력하는 기능 구현

0d9c1d3

feat: 플레이어별로 승/패 판별 기능 구현

689def1

feat: 게임을 완료한 후 각 플레이어별로 승패를 출력하는 기능 구현

ce6e1d1

refactor: 도메인 테스트 -> 도메인 패키지로 이동

979a454

docs: update GitHub PR template

eec36bb

JunHyung1206 and others added 7 commits March 14, 2026 12:36

docs: 리드미 기능 시나리오 수정 및 산출물 작성

9b604f0

docs: 기능 구현 목록 수정

1aabb95

refactor: 사용하지 않는 import 및 함수 제거

c1191f2

Merge branch 'woowacourse:main' into step2

1f57816

Merge commit '1c6d2e933e3dd520657aeda74a5accb1976c5b94' into step2cherry

00f0f79

Merge branch 'step2' into step2cherry

0b60897

fix: 돈에 대해서 long으로 처리

3d671a6

pkeugine requested changes Mar 14, 2026

View reviewed changes

JunHyung1206 added 19 commits March 15, 2026 11:14

refactor: HandCards의 생성자 삭제

bb4c1b6

- List를 매개변수로 받는 생성자는 테스트 코드에서만 사용되므로 이를 삭제 - 테스트 코드에서는, makeHandCards라는 매서드를 활용하여, 의도했던 대로 동작하는 HandCards를 만들도록 구성

refactor: 수익률을 위임하는 객체 생성(GameResult)

78d9e9d

- 각 상태에 구현된 earningsRate 함수 삭제 - GameResult에서 이를 계산하도록 구현 - Batting에서 betting으로 오탈자 수정 - Participant에서 버스트와 블랙잭 판별하도록 수정

fix: batting에서 betting으로 변경

10ae24c

- BettingCalculateService::getBettingResult - GameController::playerBetting - InputBettingParser::parseBettingMoney - Output::printBettingResults

refactor: GameResult 이름을 BettingResult으로 변경

bab3934

- BettingResult로 이름 변경 - Players 패키지 participant로 변경

refactor: Profit 변수 변경

c9e8f68

- 매개변수로 bettingResult를 사용하도록 변경 - Profit 내에서 수익을 계산하는 구조로 수정

refactor: HandCardProcessor 도입

46db82b

- 카드로 String을 만드는 작업이 중복되어 processHandCards로 중복 로직 제거

test: 수익이 어떻게 처리되는지 테스트한다.

0d345d9

- 각각 수익은 아래와 같다. - 이겼을 때 1배 - 비겼을 때 0배 - 졌을 때 -1배 - 블랙잭으로 이겼을 때 1배

feat: 소수점에 대해서 반올림으로 처리할 수 있도록 한다.

f3e64ac

feat: 베팅에 대해 규칙 추가

3ee47c3

- 1000원 단위로 베팅할 수 있도록 설정 - 최대 베팅 액수는 1억원으로 설정

fix: 베팅 금액이 0이 되는 경우에 대해서 수정

58f1755

fix: InputNumberParser 수정

89341d4

- trim을 통해서 앞뒤의 공백을 제거 - 숫자가 아닌 다른 값이 나왔을 때, 숫자만 입력해달라고 메시지 변경 - 각 값에 대해서 테스트 추가

test: 상태의 전이에 대한 테스트 추가

ba9b885

- 다음 테스트 전이를 어떻게 하는지에 대해 테스트 - 일어날 수 없는 행동에 대한 예외를 잘 반환하는지에 대해 테스트

docs: 기능 목록 업데이트

3ec339e

- 베팅 금액 입력 받는 기능 구현 완료 반영 - 프로그래밍 요구사항 반영

docs: 기능 목록 업데이트

52653a9

- 베팅 금액 입력 받는 기능 구현 완료 반영 - 프로그래밍 요구사항 반영

test: 베팅 금액은 1000원 단위로 구성하기로 하였으므로, 반올림 테스트에 대해서는 삭제

0da6c59

test: 경계 값 테스트 코드 작성

ebb82b9

- 딜러의 합이 17일 때 카드를 받지 않는 경우에 대해서 테스트 - 합이 21이더라도 카드가 세장일 때는 블랙잭으로 계산하지 않는 것에 대한 테스트

JunHyung1206 added 2 commits March 15, 2026 18:57

refactor: 스트림으로 딜러의 수익을 계산하도록 수정

8ba8483

refactor: HitOption 입력시 앞뒤로 공백이 가능하도록 수정

ca9274c


		public abstract boolean isRunning();

		public abstract double earningsRate(Status dealerStatus);

Conversation

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

Uh oh!

체크 리스트

사이클 1 피드백 반영

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

상태 패턴의 적용

테스트 코드의 작성

Uh oh!

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

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

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

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

Uh oh!

리뷰 반영사항

수익률 계산 담당 객체 분리

Service 및 Players의 책임 분리

돈에 대한 규칙 추가

돈 입력에 대한 처리 및 테스트 추가

상태 전이에 대한 테스트 추가

그외

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

JunHyung1206 commented Mar 14, 2026 •

edited

Loading

JunHyung1206 Mar 15, 2026 •

edited

Loading

JunHyung1206 commented Mar 15, 2026 •

edited

Loading