oh-my-oop 0.2.0

package/lessons/woowacourse-kotlin-blackjack/pingu244/20-1/353/213/250/352/263/204-/353/270/224/353/236/231/354/236/255.md

@@ -0,0 +1,258 @@
+# PR #20 — [블랙잭 1단계] 핑구 미션
+
+- **Reviewee:** [@pingu244](https://github.com/pingu244)
+- **PR:** https://github.com/woowacourse/kotlin-blackjack/pull/20
+- **단계:** 1단계
+- **리뷰어:** @namjackson
+- **라인 코멘트:** 30 (리뷰어 22 / 리뷰이 8)
+
+## 잘한 점 (설계 관점)
+
+- **`Deck(deck: List<Card>)` 명시 주입** — 셔플은 외부.
+- **`abstract class ParticipantState` + `DealerState`/`PlayerState`** + 공통 추상화 시도.
+- **`Referee` 분리** + `Result` enum.
+- **`Map<String, PlayerState>` 사용 — `name` 키 매핑** (후속에 객체로 변경 권고).
+
+## 못한 점 (설계 관점)
+
+### 1. `CardMaker.makeCard()` vs `makeCards()` 함수명 — *단/복수 모호*
+
+```kotlin
+class CardMaker {
+    fun makeCards(): List<Card> { ... }
+    private fun makeCard(shape: Shape): List<Card> { ... }   // ⚠ 단수 이름인데 List 반환
+}
+```
+
+리뷰어: "*makeCard와 makeCards는 어떤 차이일까요? 함수명을 직관적으로 추상화해보면 어떨까요?* *구현부를 확인하기전에 함수명만으로도 파악할수 있으면 좋을거 같아요!*" — *단/복수* 미세 차이로 *의미 구분*은 *읽기 비용 ↑*. `makeCardsBy(shape)` 또는 *함수 이름 자체를 다르게*.
+
+### 2. `for + mutableList`보다 `flatMap`
+
+```kotlin
+fun makeCards(): List<Card> {
+    val cards = mutableListOf<Card>()
+    for (shape in Shape.values()) { cards.addAll(makeCard(shape)) }
+    return cards.toList().shuffled()
+}
+```
+
+리뷰어: "*forEach, for문을 활용하기보다, map, flatMap을 활용하면 코드가 간단해질것 같아요!*" — `Shape.entries.flatMap { shape -> CardValue.entries.map { Card(shape, it) } }.shuffled()` 한 줄. PR #17·#28과 같은 결.
+
+### 3. `Deck(deck, _deck)` 두 필드 중복
+
+```kotlin
+class Deck(private val deck: List<Card>) {
+    private val _deck = deck.toMutableList()
+}
+```
+
+리뷰어: "*deck과 _deck 두가지가 중복되어 가지고 있네요!* *Backing Properties를 활용하실 목적이였을까요?*" — **Backing property 오용**. *생성자 인자 deck*과 *내부 _deck* 둘 다 보관 = *중복 + 동기화 위험*. `class Deck(initialCards: List<Card>) { private val _cards = initialCards.toMutableList() }` 또는 `private val cards: MutableList<Card>` 직접.
+
+### 4. `ParticipantState` 추상이 *abstract` 사용 이유 불명
+
+리뷰어: "*abstract로 선언한 이유는 무엇일까요?* *딜러의 checkAvailableForPick와 플레이어의 checkBurst는 어떤 차이고, 무엇을 추상화할 수 있을까* 고민해보면 어떨까요?" — *추상 클래스 도입했으나 추상화 활용 부재*. *공통 행위 = canDraw()* 같은 *단일 추상 메서드*가 자연. 학생 후속: `checkOverCondition` 추상 함수 도입.
+
+### 5. `~State` 명명이 *카드 보유자*를 의미
+
+리뷰어: "*~State라는 네이밍을 지었지만, 사실 상태에 대한 정보보단, 단순한 보유한 카드뭉치를 의미하는것 같아요* *어떤 목적으로 어떤 책임을 가진 객체를 설계하셨는지 고민해보셔도 좋을거같아요*" — **클래스명 vs 실제 책임 불일치**. *DealerState/PlayerState*는 *상태 정보*를 연상시키지만 *실제는 카드 보유 + 점수 계산*. `Dealer/Player` 또는 `DealerHand/PlayerHand`가 자연. **이름이 의미를 거짓말**.
+
+### 6. `Controller`가 `names`와 `blackjackGame`을 *모두 보유*
+
+```kotlin
+fun startGame() {
+    val names = InputView.inputPlayerNames()
+    val blackjackGame = BlackjackGame(names)
+    requestPickCard(names, blackjackGame)
+    ...
+}
+```
+
+리뷰어: "*names은 blackjackGames내에서 관리되어야하는 부분이 아닐까요?*" — *names를 BlackjackGame 생성자에 넘긴 후 Controller가 다시 names를 인자로* = *데이터 중복 보유*. `blackjackGame.players` 메시지로 충분.
+
+### 7. `Controller.validatePickAnswer(name)`가 *문자열 비교*
+
+```kotlin
+private fun repeatPickCard(blackjackGame: BlackjackGame, name: String) {
+    while (!blackjackGame.checkBurst(name)) {
+        val answer = validatePickAnswer(name)
+        if (answer == YES_ANSWER) blackjackGame.pickPlayerCard(name)
+        if (answer == NO_ANSWER) return
+    }
+}
+```
+
+리뷰어: "*컨트롤러에서는 카드를 받을것인지 말것인지에 대한 Boolean값이 관심사인것 같아요!* *어떤 문자열로 받는지는 View의 책임*은 아닐까요? *y였던 문자열이 o, yes 등으로 변경된다면, View뿐 아니라 ,Controller에도 영향이 있을것 같아요!*" — **Controller가 문자열 인식 = UI 형식 누수**. *InputView.askPickCard(): Boolean*가 자연. PR #25·#28·#33과 같은 결.
+
+### 8. `Map<String, PlayerState>` — 객체화 필요
+
+```kotlin
+val playersStates = mutableMapOf<String, PlayerState>()
+```
+
+리뷰어: "*String, PlayerState은 무엇을 의미할까요?* *Map이 아니라 객체로 관리되면 어떨까요?*" — **Map 그대로 노출 = 키 의미 불명**. `Players` 일급 컬렉션 + *내부에 `Map<Name, PlayerState>`*가 자연. *외부 호출자*는 *Players.find(name)* 메시지만. PR #25·#81·#125와 같은 결.
+
+### 9. `BlackjackGame.lateinit var dealerState`
+
+```kotlin
+class BlackjackGame(private val names: List<String>) {
+    private val deck: Deck = Deck(CardMaker().makeCards())
+    lateinit var dealerState: DealerState
+    val playersStates = mutableMapOf<String, PlayerState>()
+}
+```
+
+리뷰어: "*lateinit은 초기화를 지연시켜주지만, 가변변수로 선언됩니다.* *외부에 노출되는 가변 변수는 외부에서 변경되어 의도치않은 동작을 할것 같아요!* *init함수내에서 초기화*를 하면 *초기화지연을 할필요가 없어요!*" — **lateinit var + 외부 공개**는 *외부에서 dealerState = ...* 가능. `private val dealerState = DealerState()` + `init` 또는 `val dealerState = DealerState()` 직접. PR #92·#29·#114·#33·#34·#25와 같은 결.
+
+### 10. `ParticipantState`의 *Ace 보정 순서 의존*
+
+리뷰어: "*이러한 구조라면, cardList내의 Ace의 순서에 따라 다른동작을 할것 같아요* *관련 테스트들을 작성*해보면 어떨까요?" / 후속: "*카드가 ACE,ACE,JACK이라면, 12가 되어야하지만, 22로 계산이되네요!* *간단하게, sum을 먼저 구하고, Ace유무와 sum의 크기에 따라 +10을 더해주는 방법*으로 로직을 간단하게 작성할수 있어요!" — PR #33·#10·#79·#114와 같은 *Ace 순서 의존 알고리즘 실패*.
+
+### 11. `Card.value.toString() == "ACE"` 문자열 비교
+
+리뷰어: "*Card가 Ace인지 여부는 Card가 가져야할 책임이 아닐까요?* *문자열이 아닌 enum을 활용해서 비교*해보아요" — **`it.value.toString() == "ACE"`** 같은 *문자열 비교*는 *enum 어휘 회피*. `Card.isAce()` 또는 `it.value == CardValue.ACE`. **Java 어휘 잔재**.
+
+### 12. `if/else 두 줄 이상은 중괄호`
+
+리뷰어: "*if, else 가 두줄 이상이라면 중괄호를 작성해주세요*, https://kotlinlang.org/docs/coding-conventions.html#control-flow-statements *컨벤션을 지키면 어떤점이 좋을까요?*" — Kotlin 컨벤션. *블록 표현*이 *읽기 명확*.
+
+### 13. `Referee` 중첩 조건문
+
+```kotlin
+fun judge(dealerSum: Int, playerSum: Int): Result {
+    return when {
+        // 여러 중첩 조건문
+    }
+}
+```
+
+리뷰어: "*여러 조건문이 중첩되어있어 복잡한거 같아요!* *조건을 중첩시키기보다, 조건별 순서대로 나눠보면 어떨까요?* *플레이어 21초과 - 패배 딜러 21초과 - 승리 플레이어 > 딜러 - 승리 등등 ..*" — *우선순위 명시 when*. 또: 학생 후속 도착 *블랙잭 룰* (`Ace+10 두 장만 진짜 블랙잭`) 미반영. 리뷰어가 *2단계에서 참고하라고 명시*.
+
+### 14. `ParticipantState`의 리턴 타입 생략
+
+```kotlin
+fun isAceValue() = value == CardValue.ACE   // ⚠ 리턴 타입 추론
+```
+
+리뷰어: "*함수의 리턴타입가 생략되었네요, 생략이 가능하지만, 생략한 경우는 어떤 단점이 있을까요?*"
+
+학생 자가 답변: "*이름에서부터 명시적으로 Value를 반환한다고 말하고 있기에 생략*했습니다! *생략한 경우, 코드를 읽는 사람의 입장에서 반환값을 일일이 파악해야 한다는 단점*이 있는 것 같습니다." — PR #10 (s9hn)과 같은 *Effective Kotlin Item 4*. 공개 API는 명시.
+
+### 15. `Controller`가 *blackjackGame.players + 반복문* — Tell-Don't-Ask 위반
+
+리뷰어 (반복): "*blackJackGame에서 names를 받아와서, 다시 blackJackGame의 checkBurst, pickPlayerCard, findPlayer 등에 사용*하고 있네요, *blackJackGame게임에 메시지를 던져서, 동작하는 역할을 부여*해보면 어떨까요?" / "*blackjackGame.players를 반복문을 돌려서, blackjackGame.repeatPickCard를 카드를 돌리기보단*, *blackjackGame에게 "players에게 반복문을 돌려서 repeatPickCard을 실행하라"는 메세지를 전달*해보면 어떨까요? `blackjackGame.playsTurn(wantPickCard: (Player) ->...`" — *Manager.data → loop → Manager.method* 안티패턴. PR #25·#33·#92와 같은 결.
+
+### 16. `BlackjackGame`의 *public 메서드 순서 의존*
+
+리뷰어: "*외부에서 이런 동작이 공개되면, 순서에 따라 실행되지 않는다면, 예상하지 못한 동작을 할것 같아요!* *players가 순서에 따라 각자의 턴이 BlackJackGame내부에서 동작하게 책임을 부여*해보면 어떨까요?" — **외부에서 호출 순서 invariant 보호 부재**. *진행 메서드 1개 (`play()`)*로 묶기.
+
+### 17. `DealerCards(cards: List<Card>) : ParticipantCards(_cards)` — *중복 cards 프로퍼티*
+
+```kotlin
+class DealerCards(cards: List<Card>) : ParticipantCards(cards.toMutableList()) {
+    val cards: List<Card> = ...   // ⚠ 중복
+}
+```
+
+리뷰어: "*불필요하게 중복된 cards 프로퍼티는 제거해주셔도 좋아요!*" — *상속 + 동일 이름 프로퍼티 재선언*은 *그림자(shadowing)* + 혼동.
+
+### 18. `Controller`가 *Domain에 callback 함수 전달*
+
+학생 자가 의문: "*Input이나 Output의 함수를 도메인에게 인자로 넘기는 것이 MVC패턴에 위배되지 않을까요?*" — 학생이 *callback 전달 + 도메인의 View 의존*에 자가 의문. 답: *예, 도메인 → View 의존 위반*. PR #25 (whk06061)의 학생 자가 도달과 같은 결.
+
+### 19. `Referee.judgePlayers`의 `forEach`보다 `map`
+
+리뷰어: "*map과 forEach의 차이는 무엇일까요?* *map을 활용*해보아요!" — `forEach` = *사이드 이펙트만*, `map` = *변환된 List 반환*. *결과를 모음*이면 `map`.
+
+### 20. *함수 선언 순서가 호출 순서와 불일치* (Stepdown rule)
+
+리뷰어: "*함수 순서에 대한 이야기*입니다! *개발자들은 보통 코드를 작성하는 시간보다 작성을 위해 코드를 읽는 시간이 훨씬 많다고해요!* *코드를 읽는 사람의 가독성을 위해, 호출순서에 따라 위에서 아래로 흐름이 흐르도록 순서를*..." — PR #79와 같은 *Stepdown rule*.
+
+### 21. `BlackjackGame` *매직넘버 2*
+
+```kotlin
+repeat(2) { ... }   // 초기 분배 2장
+```
+
+리뷰어: "*2는 무엇일까요? 매직넘버보단, 상수로 관리되면, 가독성도 좋아질것 같아요!*" — `INITIAL_CARD_COUNT = 2`. PR #128·#119와 같은 결.
+
+### 22. `BlackjackGame`이 *`names` 보유 — Players와 중복*
+
+```kotlin
+class BlackjackGame(private val names: List<String>) {
+    ...
+    val playersStates = mutableMapOf<String, PlayerState>()
+}
+```
+
+리뷰어: "*names는 Players는 중복된 값을 가지고 있는것 같아요!* *names는 초기화 이후에는 가지고있지 않으도 좋을거같아요!*" — *생성자에서만 사용*하는 *names를 멤버화* = 메모리 + 상태 중복.
+
+### 23. `Referee`에 *블랙잭 룰 (Ace+10 두 장)* 미반영
+
+리뷰어 (2단계 미리 참고): "*이부분은 참고하시고, 2단계 미션하면서 참고해주세요!* *ACE와 10(Jack,Queen,King) 단 두장의 카드로만 21이 된것을 블랙잭이라고합니다.* *룰상 딜러와 플레이어가 모두 블랙잭이거나, 서로 모두 21인 경우는 무승부입니다.* *블랙잭* ..." — **블랙잭 룰 정확 이해 = 16개+ PR 연속 권고**.
+
+또: 리뷰어 *코드 제안* (`suggestion`)으로 *우선순위 명시 when* 제안.
+
+## 리뷰어 의견 요지
+
+- ***함수명 단/복수 (`makeCard`/`makeCards`) 모호*** — *명확한 이름*.
+- ***`for + mutableList` < `flatMap`*** Kotlin 컬렉션 함수.
+- ***Backing property 오용 (`deck`/`_deck` 둘 다)*** — 한 가지 표현.
+- ***`abstract` 도입했으나 활용 부재*** — 공통 추상 메서드.
+- ***`~State` 명명이 카드 보유자 의미*** = 이름이 거짓말.
+- ***Controller가 names + game 중복 보유***.
+- ***UI 형식 (`y`/`n`) Controller에 누수***.
+- ***`Map<String, PlayerState>` 그대로 노출 = 키 의미 불명***.
+- ***`lateinit var dealerState` + 외부 공개***.
+- ***Ace 보정 순서 의존 = ACE,ACE,JACK 케이스 22 오답***.
+- ***`it.value.toString() == "ACE"` 문자열 비교 < enum 활용***.
+- ***`if/else 두 줄 = 중괄호` Kotlin 컨벤션***.
+- ***Referee 중첩 조건 < 우선순위 when***.
+- ***공개 API 리턴 타입 명시*** (학생 자가 도달).
+- ***Controller → game.data + loop = manager.method 메시지***.
+- ***외부 메서드 순서 invariant 부재 = play() 단일 진입점***.
+- ***상속 + 중복 프로퍼티 = shadowing***.
+- ***`forEach` vs `map`*** — 변환은 map.
+- ***Stepdown rule***.
+- ***매직넘버 2 = INITIAL_CARD_COUNT***.
+- ***BlackjackGame에 names 멤버화 = 중복***.
+- ***블랙잭 룰 (Ace+10 두 장만 블랙잭)*** — 2단계 미리 참고.
+
+## 대표 인용
+
+> ~State라는 네이밍을 지었지만, *사실 상태에 대한 정보보단, 단순한 보유한 카드뭉치를 의미*하는것 같아요. *어떤 목적으로 어떤 책임을 가진 객체를 설계*하셨는지 고민해보셔도 좋을거같아요
+> — @namjackson on `ParticipantState.kt`
+
+> 이러한 구조라면, *cardList내의 Ace의 순서에 따라 다른동작을 할것 같아요*. *카드가 ACE,ACE,JACK이라면, 12가 되어야하지만, 22로 계산이되네요!*
+> — @namjackson on `ParticipantState.kt`
+
+> blackjackGame.players를 반복문을 돌려서, blackjackGame.repeatPickCard를 카드를 돌리기보단, *blackjackGame에게 "players에게 반복문을 돌려서 repeatPickCard을 실행하라"는 메세지를 전달*해보면 어떨까요?
+> — @namjackson on `BlackjackController.kt`
+
+> Input이나 Output의 함수를 *도메인에게 인자로 넘기는 것이 MVC패턴에 위배되지 않을까요?*
+> — @pingu244 (학생 자가 의문) on `BlackjackGame.kt`
+
+## 얻은 교훈
+
+- ***함수명 단/복수 미세 차이 = 의미 구분 모호*** — 명확하게 다른 이름.
+- ***`for + mutableList`는 Java 어휘, Kotlin은 `flatMap`*** — 함수형 컬렉션.
+- ***Backing property 오용 (`deck` + `_deck` 둘 다 보유) = 동기화 위험*** — 한 가지 표현.
+- ***`abstract` 도입했으나 추상 메서드 부재 = 추상화 활용 부재*** — *공통 행위* 추상 메서드.
+- ***`~State` 명명이 카드 보유자 의미 = 이름이 의미를 거짓말*** — *Dealer/Player* 또는 *Hand* 명명이 자연.
+- ***Controller가 names + game 중복 보유 = 데이터 흐름 분산*** — *game.players* 메시지.
+- ***UI 형식(`y`/`n`) Controller에 누수 = 16개+ PR 연속***.
+- ***`Map<String, PlayerState>` 그대로 노출 = 키 의미 불명*** — *일급 컬렉션*으로 메시지만 노출.
+- ***`lateinit var` + 외부 공개 = 외부에서 변경 가능 위험*** — `private val + init` 또는 *생성자 주입*.
+- ***Ace 보정 순서 의존 = 4번째 PR (ACE,ACE,JACK 케이스 실패)*** — *합산 후 +10 단일 룰*.
+- ***`it.value.toString() == "ACE"` 문자열 비교 = enum 어휘 회피*** — Java 잔재.
+- ***`if/else 두 줄 = 중괄호` Kotlin 컨벤션***.
+- ***Referee 중첩 조건 < 우선순위 when***.
+- ***공개 API 리턴 타입 명시 = Effective Kotlin Item 4*** (학생 자가 도달).
+- ***Controller → game.data + loop = Tell-Don't-Ask 위반*** — *manager.playTurns()* 메시지.
+- ***공개 메서드 순서 invariant 부재 = `play()` 단일 진입점*** — 호출 순서 보호.
+- ***상속 + 동일 이름 프로퍼티 = shadowing*** — *부모가 보유*하면 자식 재선언 X.
+- ***`forEach`는 사이드 이펙트, `map`은 변환 반환***.
+- ***Stepdown rule (호출 순서대로 위→아래 선언)***.
+- ***매직넘버 2 = `INITIAL_CARD_COUNT`*** — 도메인 룰 상수.
+- ***BlackjackGame에 names 멤버화 = 생성자에서만 쓰면 멤버 X***.
+- ***블랙잭 룰 (Ace+10 두 장만 진짜 블랙잭) = 16개+ PR 연속 권고*** — 룰 정확 이해.
+- ***도메인에 callback 함수 인자 = MVC 위반 (학생 자가 도달)*** — *진행 결과 반환*이 자연.

package/lessons/woowacourse-kotlin-blackjack/pingu244/41-2/353/213/250/352/263/204-/353/270/224/353/236/231/354/236/255.md

@@ -0,0 +1,171 @@
+# PR #41 — [블랙잭 2단계] 핑구 미션
+
+- **Reviewee:** [@pingu244](https://github.com/pingu244)
+- **PR:** https://github.com/woowacourse/kotlin-blackjack/pull/41
+- **단계:** 2단계 (베팅 / 수익률 / 블랙잭 1.5배)
+- **리뷰어:** @namjackson (잭슨)
+- **라인 코멘트:** 16 스레드 / 19 코멘트 — *람다 vs 반환 메시지 트레이드오프* + *3 변수 제약 자가 회의*
+
+## 잘한 점 (설계 관점)
+
+- **3 변수 제약 자가 회의 + 잭슨 동의** — 학생 자가 질문: *"Player라던가 BlackjackGame에서 생성자 인자로 받아오는 정보들이 3개가 되는데 이를 줄일 수 있는 방법이 있을까요? 제가 생각한 방법은 클래스를 만들어서 두가지 프로퍼티를 하나의 객체로 관리하는 것인데, 둘의 연관성이나 효율적인 코드를 위해서가 아닌 인자를 줄이고자 이렇게 만드는 것은 비효율적인 것 같습니다. (접근할 때 계속해서 파고 들어가야 하니까요!)"*. 잭슨 답변: *"3가지 이상의 변수를 가진 클래스를 쓰지 않는다라는 요구사항이 있지만, 좋은 설계를 위한 하나의 규칙일뿐, 불필요하다고 느낀다면 굳이 적용할필요는 없다는 생각이 들어요😄 좋은 설계방법을 고민해보시고, 불필요하다고 느끼시면 적용하지 않으셔도 좋을거 같아요!"*. **MCP 룰 후보 — `arbitrary-rule-driven-grouping`** (PR #133·#88·#132·#136 와 같은 결).
+- **`View 책임 위치 자가 토론` — 입력 검증을 view vs controller** — 학생 자가 질문 + 잭슨 답변: *"이부부은 트레이드 오프 영역일것 같아요! View의 역할을 어디까지로 지정하느냐가 중요한 지점인거 같아요... View에서 검증을 하였지만, 도메인 영역에서는 View와의 관계가 분리가 되어있기 때문에 이러한 부분 또한 신뢰할수 없기 때문에 사실 유효성 검사의 경우는 View와 컨트롤러, 도메인영역에도 모두 이루어져야 한다고 보아요"*. 학습 가시화 모범. PR #132·#88·#133 와 같은 결.
+- **`BlackjackGame` 도메인 객체 분리 시도** — 1단계 Controller god-object 진단 후속. *플레이어 턴 + 딜러 턴 흐름을 BlackjackGame 안*으로 이전 시도.
+- **`Money` 원시값 포장 권고 후속 반영** — 잭슨의 *"Money와 같은 객체로 원시값을 포장해보면 어떨까요?"* 권고. PR #133·#90·#132·#136 와 같은 결.
+- **`Result` 객체 반환 + Player 가변 상태 해소** — 잭슨 권고 *"Result또한 Player내에서 관리하는게 아닌, 새로운 Result객체로 반환해보면 어떨까요?"* 후속 반영 의도. 학생 자가 질문: *"근데 결국 외부에서 수정이 가능하긴 해야합니다..! 외부에서 계산하여 or 입력받아 정보를 저장해야하기 때문입니다.. 이렇게 가변 객체로 만들기 싫은데 바깥에서 변경할 수는 있어야 하는 상황에서는 어떻게 해야 할까요?"*. PR #85 (하디 2단계) 와 같은 결의 *불변 vs 가변* 트레이드오프 학생 자가 의문.
+
+## 못한 점 (설계 관점)
+
+### 1. `Controller` 가 *플레이어 턴 → 딜러 턴 순서 관리* — *Game 객체 책임 누수*
+
+```kotlin
+// BlackjackController (추정)
+fun run() {
+    playPlayersTurns()
+    playDealerTurn()
+}
+```
+
+잭슨 (BlackjackController.kt — 미해결): *"플레이어턴 후, 딜러 턴이 진행되는 부분은 컨트롤러에서 정하는게 아닌, blackjackGame 클래스 내에서 관리될 부분이 아닐까요?"*
+
+→ **플레이어 → 딜러 순서 = 게임 룰**. *Controller 가 순서 결정 = Game 룰 누수*. *blackjackGame.playGame()* 한 줄 호출이 *Game 자기 흐름 통제*. PR #131·#132·#136·#152 와 같은 결.
+
+### 2. `BlackjackGame.startBlackjackGame()` 가 *람다만 실행* — 함수 이름 misleading
+
+잭슨 (BlackjackGame.kt — 미해결): *"startBlackjackGame이라는 함수지만, 실제로 블랙잭 게임이 시작되는걸까요? 함수내부에는 람다만 실행되고 있네요!"*
+
+→ **`startBlackjackGame` = *블랙잭 게임을 시작한다* 의미**. *내부에 람다 호출만* = *함수 책임 부재*. *함수 이름 = 책임 명세 위반*. PR #88·#125·#114 의 *vagueName 안티패턴 변형*.
+
+### 3. `isBlackjack` / `isBurst` 가 *Player/Dealer 책임* — *Card 책임으로 이전 권고*
+
+잭슨 (Dealer.kt + Player.kt — 미해결): *"블랙잭을 확인하는 역할은 Card에게 책임을 부여해보면 어떨까요?"* + *"isBurst를 확인하는 부분도 Card에서 처리해보면 어떨까요? 승패시에 플레이뿐 아니라 딜러도, Burst여부를 확인하지 않을까요?"*
+
+→ **상태 판정 = Card/Hand 책임**. *Tell-Don't-Ask* — *Card 가 자기 점수 + Bust/Blackjack 자기 판정*. *Player/Dealer 가 자기 카드 정보 직접 비교* = *Card 책임 누수*. PR #124·#108·#128·#135·#114·#125·#152·#133·#131·#132·#136 와 같은 결.
+
+### 4. `람다 인자 vs 반환 메시지` 트레이드오프 — 학생 자가 답변
+
+잭슨 (BlackjackController.kt — 미해결): *"람다를 이용해 결과를 받는 방식과, 결과 값을 리턴받는 방식과 어떤 장단점이 있을까요?"*
+
+학생: *"제 생각에는 람다를 이용한다면 controller에서 맡는 일이 적어지고, 결과를 리턴받는다면 람다보다 직관적으로 하는 일을 확인할 수 있는 것 같습니다."*
+
+잭슨 후속 (Controller.kt 미해결): *"BlackjackResult와 blackjackGame가 협력해보면 어떨까요? blackjackGame에서 BlackjackResult를 생성하여 리턴해도 좋을거같아요! 추가적으로 val gameResult = blackjackGame.play( .. 플레이 이후, 결과를 바로 받아오면 어떨까요? 직관적일거 같아요😄"*
+
+→ **람다 인자 = Controller 책임 ↓ + 흐름 분산** vs **반환 메시지 = Controller 직관 + 결과 응집**. *학생 자가 학습 + 잭슨 후속 권고 = 반환 메시지 선호*. PR #132·#136 의 *고차함수 vs 반환 메시지* 와 같은 결.
+
+### 5. `Result.BLACKJACK_WIN` vs `WIN` 중복 — *BLACKJACK 여부 별도 체크*
+
+잭슨 (Result.kt — 미해결): *"BLACKJACK_WIN과 WIN 과 중복된 결과가 아닐까요? BLACKJACK으로 승리하였는지를 체크하는 다른 방법은 없을까요?"*
+
+→ **`BLACKJACK_WIN` enum 멤버 별도 = 결과 + 수익률 결합**. *PR #132·#108·#136 의 `BlackjackWin / BLACKJACK earningRate`* 와 *반대 트레이드오프* — 잭슨은 *결과는 WIN 하나 + 블랙잭 별도 체크*가 *명시*라 봄. *enum 멤버 응집 vs 분리* 트레이드오프.
+
+### 6. `OutputView 가 계산 로직` — *View 책임 누수*
+
+잭슨 (OutputView.kt — 미해결, 2 코멘트): *"View에서 계산로직을 호출하지말고, 계산완료된 값만 보여주도록 해보아요!"* + *"해당 로직은 dealer의 결과를 계산하는 로직으로, View에는 어울리지 않는 로직 같아요! View에서는 아무것도 모르고 전달된 데이터만 그려주는 역할을 해보아요"*
+
+→ **View = 전달 데이터만 그림**. *계산 = 도메인 책임*. PR #132·#90·#88 와 같은 결.
+
+### 7. `Cards.check` 함수명 — *Boolean 반환 미명시*
+
+잭슨 (Cards.kt:24 — 미해결): *"check라는 함수명은 리턴을 기대하지는 않을수도 있을거같아요! 보통 Boolean을 리턴할때 is, has 와 같은 접두사를 자주 사용하곤 합니다!"*
+
+→ **`check` = *동작 수행* 어휘**. *Boolean 반환은 is*/has* 접두사*. *Kotlin 어휘 표준*. *checkXX 가 Unit 반환* 가정. PR #125·#114·#10 와 같은 결.
+
+### 8. `List<Money>` 인자 — *name 별 베팅 매핑 부재*
+
+잭슨 (BlackjackGame.kt — 미해결): *"List<Money>가 무엇인지 파악하기 힘들거같아요, name별 베팅머니는 함께 관리되거나, 람다를 활용해보면 어떨까요?"*
+
+→ **`List<Money>` = 익명 컬렉션**. *플레이어 순서 의존 = 인덱스 일치 강제*. *Map<Player, Money> 또는 데이터 클래스 (BetInfo) 응집*이 정공. PR #132 (환노 2단계) 의 *Map<X,X> 지양* 진단과 같은 결.
+
+### 9. `BlackjackGameTest` 학생 자가 질문 — *private 변수 테스트* 함정
+
+학생 자가 질문: *"BlackjackGame을 테스트하기 위해서는 BlackjackGame의 private 변수인 players와 dealer를 public으로 돌려야하는데 테스트만을 위해서 그래도 되는 것인지 궁금합니다."*
+
+잭슨: *"먼저 테스트를 위한 코드는 지양하는게 좋아요, 테스트를 위한 코드가 된다면, 좋은 방법은 아닙니다! BlackjackGame의 어떤 테스트 작성을 위해 고민하시는걸까요?"* + *"다양한 방법이 있을 것 같아요! 먼저 불변객체라면, 불변변수에 사용해서 open해주어도 좋고, 생성자로 주입받는 방식을 활용할수도 있고, 결과를 확인하기 위해서라면, 리뷰에 남겨진대로, 게임 결과값을 리턴하는 구조 로 변경할수 있을거 같아요. 또 Private fun을 테스트하고 싶다면, 클래스 분리의 신호로 볼수도 있을거 같아요!"*
+
+→ **테스트를 위한 코드 지양**. *Private 멤버 테스트 필요 → 클래스 분리 신호*. *반환 메시지 + 결과 객체 검증* 정공. *Kotlin internal* 회피.
+
+### 10. `DealerTest` 의 *given-when-then 분리* — 학생 자가 학습 권고
+
+잭슨 (DealerTest.kt — 미해결): *"when, then 영역을 분리해보면 어떨까요? when영역을 통해 무엇을 테스트하는지 명확하면 좋을거같아요!"*
+
+→ **AAA (Arrange-Act-Assert) / GWT (Given-When-Then) 테스트 구조**. *주석으로 단계 명시* = *가독성 + 의도 명료*. PR #133·#136·#90 와 같은 결.
+
+### 11. `is` 연산자 회피 + 캐스팅 — *코드 미공개*
+
+잭슨 (Participants.kt — 미해결): *"캐스팅이 꼭 필요한 작업일까요? 참가자 타입에 역할을 만들어 보는건 어려울까요? 추가로, 코드에 체이닝이 너무 길게 되어 있어 명시적으로 변수를 분리해서 가독성을 올려주세요"*
+
+→ **타입 캐스팅 = 다형성 부재 신호**. *Participant 추상 메서드*가 *분기 회피*. *체이닝 길이 = 가독성 ↓*. PR #93·#108 와 같은 결.
+
+## 리뷰어 의견 요지
+
+- **3 변수 제약 = 좋은 설계 규칙 하나일 뿐, 불필요하면 적용 X** — 학생 자가 회의 + 잭슨 동의. PR #133·#88·#132·#136 와 같은 결의 *연습 도구 인식*.
+- **View 책임 = 트레이드오프 영역** — *View 자체 검증 + 도메인도 자기 invariant 강제*. *현재 단일 프로그램에선 중복 제거 OK*.
+- **람다 vs 반환 메시지** — *람다 = Controller 책임 ↓ + 흐름 분산*. *반환 = 직관 + 결과 응집*. *반환 메시지 선호*.
+- **테스트를 위한 코드 지양 — private 테스트 필요 시 클래스 분리 신호** — *생성자 주입 / 결과 반환 / 클래스 분리* 정공.
+- **Card 책임 = 자기 점수 + Bust/Blackjack 판정** — *Player/Dealer 누수 회피*.
+- **View 계산 로직 제거 = 전달 데이터만 그림** — *Tell-Don't-Ask*.
+- **`List<X>` 의미 부재 = name 별 매핑 또는 람다** — *익명 컬렉션 회피*.
+- **`check` 메서드명 = 동작 어휘, Boolean = is/has** — *Kotlin 어휘 표준*.
+
+## 대표 인용
+
+**잭슨 (3 변수 제약 적정 적용, Player.kt:5):**
+> 두가지를 묶는다면, bettingMoney와 Cards를 묶어서 게임을 진행시키는 클래스로 분리할수 있다고 생각이 들지만,
+> 지금의 구조에선, 저도 핑구님의 생각처럼 불필요하다고 생각이들어요,
+> 3가지 이상의 변수를 가진 클래스를 쓰지 않는다라는 요구사항이 있지만,
+> 좋은 설계를 위한 하나의 규칙일뿐, 불필요하다고 느낀다면 굳이 적용할필요는 없다는 생각이 들어요😄
+
+**잭슨 (View 책임 트레이드오프, InputView.kt):**
+> 이부부은 트레이드 오프 영역일것 같아요!
+> View의 역할을 어디까지로 지정하느냐가 중요한 지점인거 같아요,
+> View에서 일어나는 입력에 대한 예외사항은 View의 책임으로 볼수도 있을거 같아요,
+>
+> View에서 검증을 하였지만, 도메인 영역에서는 View와의 관계가 분리가 되어있기 때문에 이러한 부분 또한 신뢰할수 없기 때문에
+> 사실 유효성 검사의 경우는 View와 컨트롤러, 도메인영역에도 모두 이루어져야 한다고 보아요,
+>
+> 하지만, 현재의 프로젝트 구조상 View-Controller-도메인이 하나의 프로그램으로 동작중이기때문에,
+> 불필요한 중복된 검증을 제거해도 좋을거같아요.
+
+**잭슨 (Game 흐름 = Game 책임, BlackjackController.kt):**
+> 플레이어턴 후, 딜러 턴이 진행되는 부분은
+> 컨트롤러에서 정하는게 아닌, blackjackGame 클래스 내에서 관리될 부분이 아닐까요?
+
+**잭슨 (private 테스트 = 클래스 분리 신호, BlackjackGameTest.kt:12):**
+> 먼저 테스트를 위한 코드는 지양하는게 좋아요,
+> 테스트를 위한 코드가 된다면, 좋은 방법은 아닙니다!
+> ...
+> 또 Private fun을 테스트하고 싶다면, 클래스 분리의 신호로 볼수도 있을거 같아요!
+
+**학생 자가 답변 (가변 vs 불변 트레이드오프 자가 의문, Player.kt):**
+> 현재 Player는 name, ownCards, bettingMoney, result 이렇게 4가지의 정보를 가지고 있습니다.
+> 생성자 인자에 다 넣을 수는 없으니 var로 만들었는데 이러면 외부에서 수정이 가능하게 됩니다.
+> 근데 결국 외부에서 수정이 가능하긴 해야합니다..! 외부에서 계산하여 or 입력받아 정보를 저장해야하기 때문입니다..
+> 이렇게 가변 객체로 만들기 싫은데 바깥에서 변경할 수는 있어야 하는 상황에서는 어떻게 해야 할까요?
+
+## 얻은 교훈
+
+1. ***3 변수 제약 = 좋은 설계 규칙 하나일 뿐, 불필요하면 적용 X***. 잭슨/말리빈/페로로/두루 4 reviewer 공통 진단. *학생 자가 회의 + reviewer 동의 = 학습 가시화*. PR #133·#88·#132·#136·#90 와 같은 결.
+
+2. ***View 책임 트레이드오프 = View 자체 검증 + 도메인 invariant***. *완전한 분리* = *각 layer 자기 책임*. *현재 단일 프로그램*에선 *중복 제거*. *Multi-platform 고려*에선 *각 자체 검증*. PR #132·#90·#88 와 같은 결.
+
+3. ***게임 흐름 (플레이어 턴 → 딜러 턴) = Game 객체 책임***. *Controller 가 순서 결정 = Game 룰 누수*. *`blackjackGame.play()` 한 줄 호출*이 *Game 자율*. PR #131·#132·#136·#152 와 같은 결.
+
+4. ***`startBlackjackGame()` 가 람다만 실행 = 함수 이름 misleading***. *함수 이름 = 책임 명세*. *내부 행동 ≠ 이름* 이면 *vagueName 안티패턴*. PR #88·#125·#114 와 같은 결.
+
+5. ***람다 vs 반환 메시지 — 반환 메시지 선호***. *람다 = Controller 책임 ↓ + 흐름 분산*. *반환 = 직관 + 결과 응집*. *학생 자가 답변 + 잭슨 권고 = 반환 우선*. PR #132·#136·#85 와 같은 결.
+
+6. ***Private 멤버 테스트 필요 = 클래스 분리 신호 + 결과 반환 구조***. *테스트를 위한 코드 지양*. *Kotlin internal 회피*. *생성자 주입 / 불변 객체 / 결과 반환* 정공. PR #133·#136·#90 와 같은 결.
+
+7. ***Card 책임 = 자기 점수 + Bust/Blackjack 판정 (Tell-Don't-Ask)***. *Player/Dealer 가 Card 정보 직접 비교 = 누수*. PR #124·#108·#128·#135·#114·#125·#152·#133·#131·#132·#136 와 같은 결의 *카드 자기 판단* 정공.
+
+8. ***`List<X>` 익명 컬렉션 = 의미 부재***. *Map<Player, Money>* 또는 *BetInfo 데이터 클래스* 응집이 정공. PR #132 (환노) 의 *Map<X,X> 지양* 와 같은 결.
+
+9. ***Kotlin Boolean 메서드명 = is/has 접두사***. *`check` = 동작 어휘*. *`isXX` / `hasXX` = Boolean 표준*. PR #125·#114·#10 와 같은 결.
+
+10. ***Result.BLACKJACK_WIN 별도 멤버 vs WIN + 블랙잭 분기 — 트레이드오프***. *PR #132·#108·#136 의 별도 멤버* vs *PR #41·#85·#131 의 WIN + 블랙잭 분기*. *enum 멤버 응집 vs 분리* 의 *책임 위치* 트레이드오프.
+
+11. ***View 계산 로직 = View 책임 누수***. *View = 전달 데이터만 그림*. *계산 = 도메인 책임*. *Multi-platform View 갈아끼우기* 시 *계산 로직 잃음*. PR #132·#90·#88 와 같은 결.
+
+12. ***타입 캐스팅 + 체이닝 길이 = 다형성 부재 + 가독성 ↓***. *Participant 추상 메서드* 가 *분기 회피*. *명시적 변수 분리 + 다형성*이 정공. PR #93·#108 와 같은 결.
+
+13. ***`is*()` 부울 메서드는 부수효과 X***. *check 같은 동작 어휘와 구분*. *호출자 분기 안전성*. PR #124·#125·#92 와 같은 결.