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

yeo-li · 2026-03-16T07:22:14Z

체크 리스트

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

기능 요구 사항에 없어 스스로 정한 내용

1. 베팅 금액과 관련된 내용

베팅 금액의 최소 단위는 10원이다.
베팅 금액은 10원 이상 100000000원 이하여야 한다.

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

1. 커밋 단위는 어떻게 하시나요?

기능을 개발할 때는 한 파일이 아니라 여러 파일 단위로 수정이 되기도 합니다. 파일이나 메서드 단위로 커밋을 하기도 하지만, 저는 개인적으로 작업 단위로 커밋하는게 더 자연스러운 것 같아요. 작업이 끝나기 전에 커밋을 하면서 개발하면, 이미 커밋한 파일을 수정해야 하는 경우 다시 또 커밋을 해야하기 때문이에요. 이렇게 작업 단위로 커밋을 했을 때, 위험한 점이 있는지 혹은 적절한 방법인건지 궁금해요!

2. 테스트 먼저 작성해야할까요? 아니면 개발 먼저 해야할까요?

이번 미션1에서는 TDD를 지키기 위해 노력해보았습니다. TDD를 하면서 좋았던 부분은 모든 메서드에 대해 테스트를 작성할 수 있었지만, 개발 속도는 많이 더뎌졌습니다. 이유는 하나의 기능을 개발할 때 추가로 구현해야하는 도메인이나 메서드가 있는데, 이들에 대해 먼저 테스트를 작성하고 기능을 개발하고 마지막으로 구현하로 했던 기능을 구현해야했기 때문입니다. 이처럼 재귀적으로 테스트 작성이 들어갔기 때문에, 중간에 작업 흐름을 놓치기도 했습니다. 그래서 저는 TDD가 현업에서도 유효한 개발 방식인지 궁금하고, 유효하다면 TDD의 현실적인 방법과 어떤점이 유효한지도 궁금합니다!

3. 좋은 설계에 대해 궁금해요!

콘솔 프로그램에서는 객체간 협력이 중요하게 작용하는 것 같아요. 저는 처음엔 무조건 MVC 패턴을 적용하면서 개발을 했었는데, 무조건 정답인 디자인 패턴은 없다는 것을 알게되었어요🫢 콘솔 프로그램, 웹 서버 처럼 구현 장소가 다른 곳에서도 좋은 설계를 하기 위해선 어떤 태도나 방법을 적용하는게 좋을까요? 그리고 설계에 대해 공부하고싶은데, 공부하기 좋은 책도 추천해주시면 정말 감사드리겠습니다.☺️

리뷰어에게

안녕하세요 주디!
사이클1에서 소중한 피드백 해주셔서 감사해요☺️
사이클2에서는 사이클1의 피드백을 모두 적용하여 기능을 완성해보았습니다!
사이클2에서 배우고 싶은 것은 좋은 설계, 개발를 하기 위한 지식과 태도입니다.
사실 아직 위에 대해 갈피를 못잡고 있어요🥺 절대적인 정답이 없다면 정답이 없는 곳에서 정답을 도출하는 방법은 무엇일까요?
그리고 이번에는 세세한 부분보단, 개발의 거시적인 관점에서 궁금한 부분이 있었어요!
물론 코드에서 부족한 부분들에 대해서도 언제든지 피드백 해주시며 감사하겠습니다!
이번 주도 좋은 일만 있길 바라겠습니다🍀

jurlring · 2026-03-16T13:58:04Z

커밋 단위는 어떻게 하시나요?
기능을 개발할 때는 한 파일이 아니라 여러 파일 단위로 수정이 되기도 합니다. 파일이나 메서드 단위로 커밋을 하기도 하지만, 저는 개인적으로 작업 단위로 커밋하는게 더 자연스러운 것 같아요. 작업이 끝나기 전에 커밋을 하면서 개발하면, 이미 커밋한 파일을 수정해야 하는 경우 다시 또 커밋을 해야하기 때문이에요. 이렇게 작업 단위로 커밋을 했을 때, 위험한 점이 있는지 혹은 적절한 방법인건지 궁금해요!

음 커밋은 나중에 커밋로그를 보고 어떤 변경이 있었는지 확인하기 위함이라고 생각되어서요. 저도 작업 단위로 커밋하는게 맞다고 생각합니다. 다만 위와 같은 사유로 커밋 단위가 너무 커지면 확인이 어렵겠지요..! 그래서 작업 단위로 커밋하실거라면 작게 작업을 잡는게 중요할 것 같아요 :)

jurlring · 2026-03-16T14:06:32Z

테스트 먼저 작성해야할까요? 아니면 개발 먼저 해야할까요?
이번 미션1에서는 TDD를 지키기 위해 노력해보았습니다. TDD를 하면서 좋았던 부분은 모든 메서드에 대해 테스트를 작성할 수 있었지만, 개발 속도는 많이 더뎌졌습니다. 이유는 하나의 기능을 개발할 때 추가로 구현해야하는 도메인이나 메서드가 있는데, 이들에 대해 먼저 테스트를 작성하고 기능을 개발하고 마지막으로 구현하로 했던 기능을 구현해야했기 때문입니다. 이처럼 재귀적으로 테스트 작성이 들어갔기 때문에, 중간에 작업 흐름을 놓치기도 했습니다. 그래서 저는 TDD가 현업에서도 유효한 개발 방식인지 궁금하고, 유효하다면 TDD의 현실적인 방법과 어떤점이 유효한지도 궁금합니다!

TDD는 개발 방법론이고 널리 알려진 것과 같이 유효하지 않은 것은 아니에요. 무조건 사용한다고는 말씀드리긴 어렵긴해요.
개발속도가 더뎌진 것은 TDD에 익숙하지 않아서라고 생각되고요! 처음 하다보면 당연하다고 생각되고, 연습하셔야하는 부분이라고 생각해요 :)
작업 흐름을 놓치신 부분은 제가 잘 이해한건지 모르겠지만, 큰 흐름을(서비스 느낌) TDD로 개발하시다가 필요한 도메인에 대한 개발을 하다보니 흐름을 놓치신걸까요?!
요건 오히려 해야할 작업이 바로 보여서 장점이 아닌가 싶은데,, 제가 잘못이해한 것일 수 있어요..! 🔮

jurlring · 2026-03-16T14:12:12Z

좋은 설계에 대해 궁금해요!
콘솔 프로그램에서는 객체간 협력이 중요하게 작용하는 것 같아요. 저는 처음엔 무조건 MVC 패턴을 적용하면서 개발을 했었는데, 무조건 정답인 디자인 패턴은 없다는 것을 알게되었어요🫢 콘솔 프로그램, 웹 서버 처럼 구현 장소가 다른 곳에서도 좋은 설계를 하기 위해선 어떤 태도나 방법을 적용하는게 좋을까요? 그리고 설계에 대해 공부하고싶은데, 공부하기 좋은 책도 추천해주시면 정말 감사드리겠습니다.☺️

태도는 모두가 맞다고 해도 의심해보기 & 열린 마음이 중요할 것 같고요~
사실 디자인 패턴은 개발자들이 많은 요구사항을 해결하다보니 이런 요구사항을 해결할 때에는 이렇게 개발할 수도 있다~ 라는 생각으로 나온거라서 모든 요구사항에 적용할 수 있는 것도 아니고 정답도 아니에요.
책은 지금 레벨에서 읽을만한건 https://product.kyobobook.co.kr/detail/S000001062523 요거 추천드립니다!

jurlring · 2026-03-16T14:24:05Z

리뷰어에게
안녕하세요 주디!
사이클1에서 소중한 피드백 해주셔서 감사해요☺️
사이클2에서는 사이클1의 피드백을 모두 적용하여 기능을 완성해보았습니다!
사이클2에서 배우고 싶은 것은 좋은 설계, 개발를 하기 위한 지식과 태도입니다.
사실 아직 위에 대해 갈피를 못잡고 있어요🥺 절대적인 정답이 없다면 정답이 없는 곳에서 정답을 도출하는 방법은 무엇일까요?
그리고 이번에는 세세한 부분보단, 개발의 거시적인 관점에서 궁금한 부분이 있었어요!
물론 코드에서 부족한 부분들에 대해서도 언제든지 피드백 해주시며 감사하겠습니다!
이번 주도 좋은 일만 있길 바라겠습니다🍀

개발을 하다 보면 고민하게 되는 대부분의 문제들이 사실 정답이 정해져 있지 않은 경우가 많다고 생각해요. 그래서 어떤 선택을 했을 때 중요한 것은 이게 맞다 라는 절대적인 답이라기보다는, 왜 이런 선택을 했는지에 대한 기준과 이유를 가지고 있는 것이라고 생각합니다. 그 기준이 충분히 납득 가능하다면 팀원들을 설득할 수 있을 정도가 되면 좋을 것 같아요!!!

다만 지금은 여러 가지를 배워가는 과정이기 때문에 너무 빨리 정답을 찾으려고 하기보다는, 다양한 선택지를 직접 경험해보는 것도 중요하다고 생각해요. 말씀해주신 것처럼 정답이 없는 문제라도 항상 여러 선택지는 존재하잖아요~ 그 선택지들을 직접 적용해보고, 어떤 방식이 더 이해하기 쉽고 유지보수하기 좋은지 경험을 통해 깨닫는 과정이 큰 도움이 될 것 같습니다!

그리고 개발의 거시적인 관점에서 궁금하다고 말씀해주셨는데, 구체적으로 어떤 부분이 궁금하신지 조금 더 알 수 있을까요? 혹은 PR에 작성해주신 부분일까요?

jurlring

서여 안녕하세요~
게임이 요구사항대로 동작하지 않는 부분이랑 코멘트 몇가지 남겼습니다!
시간 괜찮으실 때 확인해주세요~! 🐰

jurlring · 2026-03-16T13:35:20Z

src/main/java/constant/PolicyConstant.java

+    public static int MONEY_MIN_VALUE = 10;
+    public static int MONEY_MAX_VALUE = 100_000_000;
+    public static int MONEY_UNIT = 10;


final이 빠진 것 같아요.
제 개인적인 팁인데, PR 제출하고 changes로 코드를 확인하면 내가 리뷰하는 시선에서 내 코드를 볼 수 있어요! :)

헉 그러네요.. 다음엔 changes도 확인하겠습니다! 피드백 감사합니다😊

jurlring · 2026-03-16T13:37:35Z

src/main/java/constant/PlayerAction.java

        return action;
    }

    public boolean isHit() {


미사용하는 것으로 보여요 😿

미쳐 확인 못했네요..! 바로 지우겠습니다!

jurlring · 2026-03-16T13:41:09Z

src/main/java/constant/PlayerAction.java

    private static void validate(String input) {
+        validateYesNoActionInput(input);
+    }
+
+    private static void validateYesNoActionInput(String input) {
        String normalized = input.strip();
        if (!normalized.equals(PlayerAction.HIT.getAction()) && !normalized
            .equals(PlayerAction.STAND.getAction())) {
            throw new IllegalArgumentException(ErrorMessage.INVALID_YES_NO_INPUT.getMessage());
        }
    }


validate에서 validateYesNoActionInput만 호출하는게 불필요한 분리 같아보여요..! 이유가 있을까요?

또한 validateYesNoActionInput 메서드는 변경에 취약한 것 같습니다.
예를 들어 HIT, STAND외에 다른 enum이 늘어난다면 코드에 변경이 생겨야할 것 같아요~

validate로 감싼 이유는, 또 다른 예외사항이 추가될 수 있어 확장성을 염두해두고 분리해보았어요! 혹시 이런 관점에서도 validate로 감싸는건 불필요한 분리인지도 궁금해요:)

HIT, STAND 외에 확장성을 고려하기 위해서 values()를 사용해 모든 값을 순회하면서, getAction()을 이용해 입력값과 같을때 해당 enum을 반환하도록 했습니다. 그리고 모든 값과 일치하지 않을 때, 예외를 발생시키도록 리팩토링 했습니다!

혹시 이보다 더 좋은 방향성이 있다면 언제든지 편하게 제시해주시면 감사하겠습니다🍀

jurlring · 2026-03-16T13:44:00Z

src/main/java/constant/Result.java

        return result;
    }

    public static Result from(Dealer dealer, Player player) {


함수(또는 메서드)의 길이가 10라인을 넘어가지 않도록 구현한다.

좀 더 간결하게 바꿀 방법이 없을까요~?

저는 간결하게 바꾸기 위해, 우선 from 메서드를 비슷한 단위로 나누어 보았습니다. from의 승패 판정 로직이 크게 세 가지 기준으로 나누어졌습니다. 가장 먼저 Bust를 기준으로 판정합니다. 판정이 나지 않은 경우, Blackjack 여부로 결과를 판정하고, 마지막으로 그래도 판정이나지 않으면 점수를 비교하여 결과를 반환합니다.

// 리팩토링한 from() 메서드 public static Result from(Dealer dealer, Player player) { // Bust를 기준으로 결과 판정 if (player.isBust()) { return Result.LOSE; } if (dealer.isBust()) { return Result.WIN; } // Blackjack을 기준으로 결과 판정 Result blackjackResult = determineByBlackjack(dealer, player); if (blackjackResult != null) { return blackjackResult; } // 점수를 기준으로 결과 판정 return determineByScore(dealer, player); } private static Result determineByBlackjack(Dealer dealer, Player player) { if (dealer.isBlackjack() && !player.isBlackjack()) { return Result.LOSE; } if (dealer.isBlackjack() && player.isBlackjack()) { return Result.PUSH; } if (player.isBlackjack()) { return Result.BLACKJACK; } return null; // blackjack 여부로 결정을 할 수 없을 때, null을 발생시킵니다. } private static Result determineByScore(Dealer dealer, Player player) { if (dealer.calculateScore() == player.calculateScore()) { return Result.PUSH; } if (dealer.calculateScore() > player.calculateScore()) { return Result.LOSE; } return Result.WIN; }

위는 리팩토링한 코드입니다. determineByBlackjack()에서 blackjack으로 판단이 어려운 경우, null을 반환하도록 했어요. 그런데 저번에 첨부해주신 null 관련 자료에서 null이 아닌 기본값이 있는 경우가 더 어색한 경우에 null을 사용한다.라고 언급이 되어 있었습니다. 그래서 determineByBlackjack()가 null을 반환하는게 어색한 상황이라 생각해, 더 나은 방법을 찾아보았습니다!

찾아본 결과 Chain Of Responsibility 패턴이 있었습니다. 이를 적용하려고 했지만 null을 허용하는 것보다 더 복잡하고 직관적으로 알아보기 어려워 null을 반환하되, null의 의미를 주석으로 적어놓기로 했습니다!

메서드로 나누는 것 보다 나누지 않는게 가독성에 더 좋다고 생각해서 그냥 두었는데, 피드백 주신 방향으로 고민해보니 다양한 방법에 대해 생각할 수 있었어요! 감사합니다☺️ 그리고 혹시 이에 대한 더 나은 방법과 Chain Of Responsibility의 적절한 사용 케이스도 알려주시면 정말 감사하겠습니다:)

jurlring · 2026-03-16T13:47:25Z

src/main/java/domain/participant/Participant.java

    public boolean isBust() {
        return hand.calculateScore() > PolicyConstant.BLACKJACK_SCORE;
    }

    public int calculateScore() {
        return hand.calculateScore();
    }
+
+    public boolean isBlackjack() {
+        return hand.calculateScore() == PolicyConstant.BLACKJACK_SCORE && hand.getCardNames().size() == 2;
+    }


hand가 Blackjack인지 Bust인지 판단하면 어떨까요? 이렇게 바꾸면 어떤 장점이 있을까요?

버스트와 블랙잭의 판단을 Hand로 옮기는게 좋은 것 같아요! 우선 각 도메인에서의 역할이 더 자연스럽다는 장점이 있었어요. 그리고 수정 전 코드는 getCardNames()를 호출해 전체 카드 수를 계산하고 있는데, 이를 호출하지 않고 this.cards를 이용해 카드 수를 계산할 수 있었습니다! 그래서 불필요한 메서드를 호출하지 않아도 된다는 장점이 있었어요.

반면 hand 도메인으로 옮기지 않으면 수정을 하지 않아도 된다(?)는 장점은 있었지만, getCardNames() 메서드를 카드 수를 세기 위해 원래 메서드 목적과 맞지 않은 용도로 사용해야 한다는 단점이 있었습니다.

따라서 피드백 주신 것 처럼 Hand에서 blackjack, bust를 판단하는게 더 좋은 설계인 것 같아요! 감사합니다:) 주디의 생각도 이야기 해주면 고마울 것 같아요🍀

jurlring · 2026-03-16T13:50:04Z

src/main/java/controller/BlackjackController.java

+    private void collectBets() {
+        for (int playerIndex = 0; playerIndex < blackjackService.getPlayerCount(); playerIndex++) {
+            String input = inputView.inputBetAmount(blackjackService.getPlayerName(playerIndex));
+            blackjackService.receivePlayerBets(playerIndex, Money.from(input));
+        }
+    }
+


index로 가져오는것보다, player의 초기화를 베팅금액까지 받고 하면 어떨까요?
플레이어는 베팅금액을 무조건 가져야하는데 Player.placeBet이 누락되면 베팅금액을 가질 수 없는 구조로 보여요!

jurlring · 2026-03-16T13:54:27Z

src/main/java/exception/ErrorMessage.java

        String.format("게임 참가자의 이름은 %d~%d글자 사이여야 합니다.", PolicyConstant.PLAYER_NAME_MIN_LENGTH,
            PolicyConstant.PLAYER_NAME_MAX_LENGTH)),
    PLAYER_NAME_BLANK("게임 참가자의 이름은 공백이 될 수 없습니다."),
+    MONEY_NOT_NUMBER("베팅 금액은 숫자여야 합니다."),


음수가 들어갔을때 위 에러가 나오는게 맞을까요..?!

jurlring · 2026-03-16T14:14:57Z

src/main/java/controller/BlackjackController.java

+    private boolean isStandSelected(int playerIndex) {
+        String name = blackjackService.getPlayerName(playerIndex);
+        String input = inputView.inputHitOrStand(name);
+        if (PlayerAction.from(input).isStand()) {


21점을 넘어도 사용자가 계속 카드를 받아도 되나요?

jurlring · 2026-03-16T14:17:33Z

src/main/java/dto/PlayerResultDto.java

 public record PlayerResultDto(
    String name,
-    Result result
+    double profit


금액이라는 값이 double로 나올 수 있을까요..?!

yeo-li · 2026-03-17T01:47:29Z

커밋 단위는 어떻게 하시나요?
기능을 개발할 때는 한 파일이 아니라 여러 파일 단위로 수정이 되기도 합니다. 파일이나 메서드 단위로 커밋을 하기도 하지만, 저는 개인적으로 작업 단위로 커밋하는게 더 자연스러운 것 같아요. 작업이 끝나기 전에 커밋을 하면서 개발하면, 이미 커밋한 파일을 수정해야 하는 경우 다시 또 커밋을 해야하기 때문이에요. 이렇게 작업 단위로 커밋을 했을 때, 위험한 점이 있는지 혹은 적절한 방법인건지 궁금해요!

음 커밋은 나중에 커밋로그를 보고 어떤 변경이 있었는지 확인하기 위함이라고 생각되어서요. 저도 작업 단위로 커밋하는게 맞다고 생각합니다. 다만 위와 같은 사유로 커밋 단위가 너무 커지면 확인이 어렵겠지요..! 그래서 작업 단위로 커밋하실거라면 작게 작업을 잡는게 중요할 것 같아요 :)

커밋단위에 대해 의견 이야기 해주셔서 감사해요! 작업을 작은 단위로 나누는 연습을 해보겠습니다💪🏻

yeo-li · 2026-03-17T04:33:38Z

테스트 먼저 작성해야할까요? 아니면 개발 먼저 해야할까요?
이번 미션1에서는 TDD를 지키기 위해 노력해보았습니다. TDD를 하면서 좋았던 부분은 모든 메서드에 대해 테스트를 작성할 수 있었지만, 개발 속도는 많이 더뎌졌습니다. 이유는 하나의 기능을 개발할 때 추가로 구현해야하는 도메인이나 메서드가 있는데, 이들에 대해 먼저 테스트를 작성하고 기능을 개발하고 마지막으로 구현하로 했던 기능을 구현해야했기 때문입니다. 이처럼 재귀적으로 테스트 작성이 들어갔기 때문에, 중간에 작업 흐름을 놓치기도 했습니다. 그래서 저는 TDD가 현업에서도 유효한 개발 방식인지 궁금하고, 유효하다면 TDD의 현실적인 방법과 어떤점이 유효한지도 궁금합니다!

TDD는 개발 방법론이고 널리 알려진 것과 같이 유효하지 않은 것은 아니에요. 무조건 사용한다고는 말씀드리긴 어렵긴해요. 개발속도가 더뎌진 것은 TDD에 익숙하지 않아서라고 생각되고요! 처음 하다보면 당연하다고 생각되고, 연습하셔야하는 부분이라고 생각해요 :) 작업 흐름을 놓치신 부분은 제가 잘 이해한건지 모르겠지만, 큰 흐름을(서비스 느낌) TDD로 개발하시다가 필요한 도메인에 대한 개발을 하다보니 흐름을 놓치신걸까요?! 요건 오히려 해야할 작업이 바로 보여서 장점이 아닌가 싶은데,, 제가 잘못이해한 것일 수 있어요..! 🔮

앗 제가 생각한 부분에 대해서 상황을 추가하겠습니다!

블랙잭 베팅 기능을 만든다고 했을때, 아래 메서드를 구현한다고 가정해볼게요!

public void receivePlayerBets(int playerIndex, Money money) {
    Player player = players.getPlayerByIndex(playerIndex);
    /*이하 생략*/
}

BlackjackService에 receivePlayerBets()를 만들고 테스트 코드를 작성한다.
receviePlayerBets()를 구현한다. 이때, Money VO가 필요하기 때문에 Money VO를 만들러 간다.
Money 생성자에 대한 테스트 코드를 작성한다.
Money를 구현한다.
receviePlayerBets()로 돌아와 다시 기능을 구현한다.
players.getPlayerByIndex()를 만들기 위해 Player 도메인으로 이동한다.
getPlayerByIndex() 테스트 코드를 작성한다.
getPlayerByIndex()를 구현한다.
receivePlayerBets()으로 돌아와 기능을 완성한다.

이렇게 하나의 메서드를 완성하기 위해서 추가로 기능을 만들때 테스트 코드가 들어가게 되어 시간이 소요되고, 그 과정에서 흐름을 놓치게 되는 것이었습니다! 그런데 작성을 하다보니 정리가 된 것 같아요..! 처음부터 어떤 것을 만들지 모두 정리한 다음에 getPlayerByIndex부터 TDD로 작업하면 되겠네요!

yeo-li · 2026-03-17T05:05:17Z

좋은 설계에 대해 궁금해요!
콘솔 프로그램에서는 객체간 협력이 중요하게 작용하는 것 같아요. 저는 처음엔 무조건 MVC 패턴을 적용하면서 개발을 했었는데, 무조건 정답인 디자인 패턴은 없다는 것을 알게되었어요🫢 콘솔 프로그램, 웹 서버 처럼 구현 장소가 다른 곳에서도 좋은 설계를 하기 위해선 어떤 태도나 방법을 적용하는게 좋을까요? 그리고 설계에 대해 공부하고싶은데, 공부하기 좋은 책도 추천해주시면 정말 감사드리겠습니다.☺️

태도는 모두가 맞다고 해도 의심해보기 & 열린 마음이 중요할 것 같고요~ 사실 디자인 패턴은 개발자들이 많은 요구사항을 해결하다보니 이런 요구사항을 해결할 때에는 이렇게 개발할 수도 있다~ 라는 생각으로 나온거라서 모든 요구사항에 적용할 수 있는 것도 아니고 정답도 아니에요. 책은 지금 레벨에서 읽을만한건 https://product.kyobobook.co.kr/detail/S000001062523 요거 추천드립니다!

피드백 감사합니다!! 이번주에 학교에서 책 빌려서 읽어봐야겠어요!

yeo-li · 2026-03-17T05:41:38Z

리뷰어에게
안녕하세요 주디!
사이클1에서 소중한 피드백 해주셔서 감사해요☺️
사이클2에서는 사이클1의 피드백을 모두 적용하여 기능을 완성해보았습니다!
사이클2에서 배우고 싶은 것은 좋은 설계, 개발를 하기 위한 지식과 태도입니다.
사실 아직 위에 대해 갈피를 못잡고 있어요🥺 절대적인 정답이 없다면 정답이 없는 곳에서 정답을 도출하는 방법은 무엇일까요?
그리고 이번에는 세세한 부분보단, 개발의 거시적인 관점에서 궁금한 부분이 있었어요!
물론 코드에서 부족한 부분들에 대해서도 언제든지 피드백 해주시며 감사하겠습니다!
이번 주도 좋은 일만 있길 바라겠습니다🍀

개발을 하다 보면 고민하게 되는 대부분의 문제들이 사실 정답이 정해져 있지 않은 경우가 많다고 생각해요. 그래서 어떤 선택을 했을 때 중요한 것은 이게 맞다 라는 절대적인 답이라기보다는, 왜 이런 선택을 했는지에 대한 기준과 이유를 가지고 있는 것이라고 생각합니다. 그 기준이 충분히 납득 가능하다면 팀원들을 설득할 수 있을 정도가 되면 좋을 것 같아요!!!

다만 지금은 여러 가지를 배워가는 과정이기 때문에 너무 빨리 정답을 찾으려고 하기보다는, 다양한 선택지를 직접 경험해보는 것도 중요하다고 생각해요. 말씀해주신 것처럼 정답이 없는 문제라도 항상 여러 선택지는 존재하잖아요~ 그 선택지들을 직접 적용해보고, 어떤 방식이 더 이해하기 쉽고 유지보수하기 좋은지 경험을 통해 깨닫는 과정이 큰 도움이 될 것 같습니다!

그리고 개발의 거시적인 관점에서 궁금하다고 말씀해주셨는데, 구체적으로 어떤 부분이 궁금하신지 조금 더 알 수 있을까요? 혹은 PR에 작성해주신 부분일까요?

제가 생각한 거시적인 관점은 pr에 작성한 부분과 소프트웨어 아키텍쳐적인 부분이었습니다! 주디가 이야기 해주신 것 처럼 다양한 경험을 하면서 유지보수가 어려웠던 부분, 좋았던 부분들을 정리하면 많이 성장할 것 같아요:)

yeo-li added 17 commits March 13, 2026 18:50

feat(blackjack): 베팅 입력 및 최종 수익 계산 기능 추가

368adb3

docs(readme): 베팅 및 최종 수익 요구사항 문서 업데이트

97dc6a0

test(PlayerActionTest): PlayerAction.from() 메서드 테스트 코드 작성

90fe852

test(ResultTest): Result.from() 메서드 테스트 코드 작성

8ea616d

test(BlackjackServiceTest): receivePlayerBets() 메서드 테스트 코드 작성

2c8db6c

test(BlackjackServiceTest): calculateBlackjackResult() 메서드 테스트 코드 작성

ef92212

refactor(All): 파일 경로 재배치

2fff09a

refactor(ErrorMessage): Money 도메인 에러 메세지 분리

f8fcff7

refactor(BlackjackController): inputHitOrStand() 메서드 분리

bbf2f00

refactor(All): 공백 및 미사용 dto 정리

030b475

refactor(CardMachine): 카드를 모두 뽑았을 때, null이 아닌 예외를 발생시키도록 변경

b8ce3f9

refactor(Money): 매직넘버 상수화

94120a7

refactor(Players): Players.value() class로 변경 후 생성자 private로 변경

de6f04d

refactor(ErrorMessage): Money 에러 메세지 정책 상수 적용

51b521e

refactor(Money): Money 생성자에 유효성 검증 로직 추가

73b3da2

refactor(BlackjackService): calculateScore() 메서드 제거

f11a3d2

refactor(domain): 불필요한 static 제거

5d0db00

jurlring requested changes Mar 16, 2026

View reviewed changes

Conversation

yeo-li commented Mar 16, 2026

체크 리스트

기능 요구 사항에 없어 스스로 정한 내용

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

1. 커밋 단위는 어떻게 하시나요?

2. 테스트 먼저 작성해야할까요? 아니면 개발 먼저 해야할까요?

3. 좋은 설계에 대해 궁금해요!

리뷰어에게

Uh oh!

jurlring commented Mar 16, 2026

Uh oh!

jurlring commented Mar 16, 2026

Uh oh!

jurlring commented Mar 16, 2026

Uh oh!

jurlring commented Mar 16, 2026

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!

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!

yeo-li commented Mar 17, 2026

Uh oh!

yeo-li commented Mar 17, 2026

Uh oh!

yeo-li commented Mar 17, 2026

Uh oh!

yeo-li commented Mar 17, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants