oh-my-oop 0.2.0

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

@@ -0,0 +1,289 @@
+# PR #34 — [블랙잭 2단계] 아크 미션
+
+- **Reviewee:** [@re4rk](https://github.com/re4rk)
+- **PR:** https://github.com/woowacourse/kotlin-blackjack/pull/34
+- **단계:** 2단계 (베팅 + 수익률 + State 패턴 도입)
+- **리뷰어:** @woowajames (제임스)
+- **라인 코멘트:** 30 (리뷰어 24 / 리뷰이 6)
+- **참고:** 같은 학생의 1단계 = PR #8
+
+## 잘한 점 (설계 관점)
+
+- **State 패턴 도입 — `State` sealed + `inTurn/Hit`, `endTurn/Bust`/`Stay`/`BlackJack`** — 상태 전이를 *타입*으로 표현. PR #78 패턴.
+- **`Money @JvmInline value class` 원시값 포장** + 범위 invariant.
+- **`Outcome` enum + `rate: Double`** — *WIN_WITH_BLACKJACK(0.5)* / *WIN(1.0)* / *LOSE(-1.0)* 수익률 직접 보유.
+- **`blackJack { ... }` DSL** — `cardDeck`, `participants` 빌더로 게임 구성.
+- **`BlackJackResult(participants)` 결과 객체 분리** + `BlackJackResultUser(name, rateOfReturn)` 사용자 단위 결과.
+- **테스트 함수에 fixture (`CLOVER_KING`, `CLOVER_NINE` 등) 도입** — 테스트 가독성.
+- **후속 반영 — score를 *상태 분리* + Score 클래스 단일화 + Outcome.rate 적용 + CardViewUtil → toString 토론 결정**.
+
+## 못한 점 (설계 관점)
+
+### 1. `BlackJackGame.getCommand: lateinit var` — 함수 참조 미주입 시 런타임 에러
+
+```kotlin
+class BlackJackGame {
+    lateinit var getCommand: (String) -> Boolean
+    // setUp에서 미주입 시 isInitialized false → 런타임 NPE
+}
+```
+
+리뷰어: "*해당 함수를 넘겨주지 않아도 컴파일 에러는 없지만 런타임 에러가 발생하게 됩니다. 이 경우를 대비할 수 있는 방법을 고민*해보면 어떨까요?" — *lateinit var callback*. *생성자 인자*가 자연 (`BlackJackGame(getCommand: (String) -> Boolean)`). PR #92·#29·#114·#33과 같은 결.
+
+또: "*해당 라인이 누락되는 경우 런타임 에러는 해결된 듯 보이지만 논리적 에러가 발생합니다. 당장의 문제를 해결하는 것도 좋지만 회귀 테스트 관점으로 충분히 고민*해보시는 것도 좋겠네요." — *방어 코드*가 *런타임 통과*하면 *논리 오류 은폐*.
+
+### 2. `User.score()`, `isBlackJack()`, `isBust()`, `draw()` 모두 함수 — *상태와 행동 혼동*
+
+```kotlin
+abstract class User(name: String) {
+    fun score(): Int = cards.result.score()         // 계산
+    fun isBlackJack(): Boolean = score() == BLACKJACK_NUMBER   // 질의
+    fun isBust(): Boolean = score() > BLACKJACK_NUMBER         // 질의
+    fun draw(card: Card) { cards += card }          // 변경
+}
+```
+
+리뷰어: "*score(), isBlackJack(), isBust(), draw() 모두 함수로 만드셨네요. 어떤 기준으로 만드신걸까요?* *행동은 상태를 변경시킵니다.* *상태와 행동을 구분하면 좋겠습니다.*" — **Kotlin val/fun 컨벤션**: *상태(질의)*는 `val` + custom getter / `data class` 프로퍼티, *행동(변경)*은 `fun`. *score*는 *카드의 합 = 파생 상태* → `val score: Int`, *draw*는 *상태 변경* → `fun`. PR #135·#10·#33과 같은 결.
+
+### 3. `Card.isACE()` 함수명 대문자 — 카멜 케이스 위반
+
+```kotlin
+data class Card(val mark: CardMark, val value: CardValue) {
+    fun isACE(): Boolean = value == CardValue.ACE
+}
+```
+
+리뷰어: "*외부의 요청에 응답하기 위한 함수(=행동)네요. 다만 상태를 변경하는 역할을 하지는 않네요. 그리고 코틀린 코딩 컨벤션에 따른 함수명은 카멜 케이스로 작성하기*입니다." — `isAce()` 카멜 케이스. *상수처럼 보이는 약자도 카멜*. + *질의는 `val`이 더 자연* (위 §2와 같은 맥락).
+
+### 4. `Score` 클래스에 *`BLACKJACK_NUMBER` 상수가 여러 곳에서 참조*
+
+```kotlin
+class Score(cards: Cards) {
+    companion object {
+        const val BLACKJACK_NUMBER = 21       // ⚠ 외부 import (Score.Companion)
+    }
+}
+```
+
+리뷰어: "*여러 곳에서 참조하고 있네요. 그렇다는 것은 여러 곳에서 블랙잭인지 확인 하는 작업을 한다는 의미입니다.* *그런 작업을 하는 클래스가 존재하면 해당 상수를 그 클래스에서만 사용하는 것으로 변경 할 수 있습니다.*" — **상수의 *외부 노출*은 *기능이 분산*된 신호**. `isBlackJack()` / `isBust()` 같은 *Score 내부 질의*만 노출하면 *상수 비공개*가능. PR #128·#92와 같은 결.
+
+### 5. `Money.toInt()` — 외부 노출 함수
+
+```kotlin
+@JvmInline
+value class Money(private val money: Int) {
+    fun toInt(): Int = money
+}
+```
+
+리뷰어: "*val 타입으로 외부에 노출해도 문제가 없을 것 같아요. 그러면 toInt() 함수도 제거할 수 있을 것 같은데 특별히 이렇게 한 이유가 있을까요?*" — `value class Money(val value: Int)`로 *프로퍼티 노출*이 자연. `toInt()` 같은 *Java 어휘 변환자*는 불필요. 학생 후속: `val value: Int` 채택.
+
+### 6. `Money` 범위 검증 — 예외 vs 재입력
+
+```kotlin
+@JvmInline
+value class Money(val value: Int) {
+    init { require(value in MIN_MONEY..MAX_MONEY) { ERROR_MONEY_RANGE } }
+}
+```
+
+리뷰어: "*범위를 벗어난 값을 입력했을 때 다시 입력 받을 수 있도록 처리해보면 어떨까요?*" — *invariant 검증 = require → throw*. *재입력 루프*는 *Controller* 책임. *도메인 invariant 보호*와 *UI 재입력*은 다른 레이어. PR #146 (lotto)와 같은 결.
+
+### 7. `CardViewUtil` 유틸 클래스 — 토론 후 학생 유지 결정
+
+```kotlin
+// blackjack/view/CardViewUtil.kt
+fun Card.toText(): String = "${value.pattern()}${mark.name()}"
+private fun CardMark.name(): String = when (this) { ... }
+private fun CardValue.pattern(): String = when (this) { ... }
+```
+
+리뷰어: "*Util형 클래스를 두면 해당 클래스에 결합도가 높아지게 됩니다. CardMark, CardValue 각 클래스에 toString()을 오버라이딩 해보면 어떨까요?*"
+
+학생 자가 토론: "*해당 기능은 리뷰어님들께서도 많이 의견이 갈리시는 방향이라 고민을 많이 해보았습니다.* *View의 영역에 있어야 한다는 리뷰어님들께서는 toString()를 오버라이딩을 한다면 domain에서 맡을 역할이 아니라고 조언*해주셨습니다. 다음으로 *domain의 영역에 있어야 하신 리뷰어님들 께서는 제임스와 같이 결합도가 높아진다고 조언*을 주셨습니다. 그래서 저의 선택은 앞에서 리뷰해주신 *when문을 exhaustive하게 작성*하시라고 하셔서 *이를 적용한다면 해당 구조가 괜찮지 않을까 생각*합니다."
+
+리뷰어: "*정답이 없는 문제이기 때문에 사람마다 다르게 생각할 수 있다고 봐요.* 모든 리뷰에 대해 *수정할 필요도 없고 아크 생각에 이게 낫다고 판단되면 그대로 두셔도 됩니다!* *지금처럼 아크만의 생각을 정립하는 게 이러한 리뷰 시간에서 얻어가는 것*이라고 생각합니다."
+
+→ **트레이드오프 명확히 인식 + 학생 결정 존중**. *toString = 도메인 + 결합도*, *유틸 = View + 결합도*. 학생의 *exhaustive when*은 *추가 변경 발견 가능*하지만 *수정 회피 수단은 아님* (리뷰어 추가 코멘트).
+
+### 8. CardMark/CardValue *when 표현 + 한국어 UI*
+
+```kotlin
+private fun CardMark.name(): String = when (this) {
+    CardMark.CLOVER -> "클로버"
+    CardMark.DIA -> "다이아몬드"
+    CardMark.HEART -> "하트"
+    CardMark.SPADE -> "스페이드"
+}
+```
+
+리뷰어: "*when 문은 exhaustive 한 것이 좋습니다.* 만약 *새로운 값이 추가 되었을 때 이 부분에 추가하는 것을 놓치면 논리적 오류가 발생할 가능성이 높겠죠?*" — **else 분기 없이 모든 case 명시 = exhaustive**. 새 enum 값 추가 시 *컴파일 에러*가 *추가 누락 방지*. PR #34만의 특이점.
+
+### 9. `CardDeck.size: Int` — 함수명이 *변수명 형태*
+
+```kotlin
+class CardDeck(cards: List<Card>) {
+    val size: Int                          // 좋음 (속성)
+    fun nextCard(): Card                   // 좋음 (동작)
+}
+
+// 별도 함수: 함수명이 변수명 형태 (지목된 위치 모름)
+```
+
+리뷰어: "*함수명이 변수명의 형태 같아요. 좀 더 어울리는 네이밍이 없을까요?*" — `size`/`nextCard` 같은 *상태 vs 동작* 명명 차이.
+
+### 10. `Guest.isContinue` — *영문 형용사 vs 명사 동사 혼동*
+
+```kotlin
+abstract class User(name: String) {
+    abstract val isContinue: Boolean
+}
+```
+
+리뷰어: "*isContinuable 이란 변수명이면 더 자연스러울 것 같아요.*" — `isContinue`는 *동사 continue를 형용사처럼*. `isContinuable` 형용사 형태. *영문법 정확성*. 학생 후속 반영.
+
+### 11. `Participants.all()` — 함수 vs 프로퍼티
+
+리뷰어: "*이건 상태일까요 행동일까요?* 🤔" — *all*은 *컬렉션 노출 = 상태*. `val all: List<User>` (custom getter). 학생 후속: `all`로 변경.
+
+### 12. `Outcome enum`에 *블랙잭 승*이 enum 값으로
+
+```kotlin
+enum class Outcome(val rate: Double) {
+    WIN_WITH_BLACKJACK(0.5),
+    WIN(1.0),
+    DRAW(0.0),
+    LOSE(-1.0),
+}
+```
+
+리뷰어: "*정리하면 좀 더 보기 좋을 것 같아요.*" — *Outcome*에 *블랙잭으로 승*까지 enum 값. *결과 + 수익률* 결합. *결과 = 승/무/패* 만 두고 *블랙잭 보너스*는 *별도 계산*이 분리. (학생 후속에 `rate` 속성 추가.)
+
+### 13. `Stay.matchWith(otherState)`에서 *Hit 케이스 누락*
+
+```kotlin
+class Stay(cards: Cards) : EndTurn(cards) {
+    override fun matchWith(otherState: State): Outcome {
+        return when (otherState) {
+            is Bust -> WIN
+            is BlackJack -> compareBlackJack()
+            is Stay -> compareScore(otherState.score)
+            else -> throw IllegalStateException(ERROR_INVALID_STATE)   // ⚠ Hit 케이스
+        }
+    }
+}
+```
+
+리뷰어: "*현재 구조에서 Hit에서도 Stay의 matchWith()를 타고 들어오는데요.* 이 경우엔 *무조건 else 문으로 처리되어 프로그램이 정상적인 동작을 할 수 없습니다*. 간단하게는 *Stay와 동일하게 Hit를 처리*하면 되겠네요. 혹은 *Hit에서 Stay로 가는 로직을 추가*하면 되구요." — **State 패턴의 *상태 전이 빠짐*** = *런타임 에러*. *Hit → 종료 전이*가 누락. 학생 자가 인정. 후속 반영.
+
+### 14. `HitTest`에서 *Hit → BlackJack 누락*
+
+리뷰어: "*히트에서 블랙잭으로 가는 경우입니다.* 예를 들어 *16(히트)에서 스테이로 갈 수 있는 상황에 대한 로직 추가 및 테스트도 필요*할 것 같아요." — *상태 전이 그래프*의 *모든 경로*를 *테스트로 검증*해야 *State 패턴 완전*. 학생 후속: *Hit → Stay* 테스트 추가.
+
+### 15. `Cards`가 *Score 관련 기능 보유*
+
+```kotlin
+class Cards(private val cards: Set<Card> = setOf()) {
+    val result = Score(this)
+    val size: Int = cards.size
+    val isContainsAce: Boolean
+    val hardScore: Score
+    val softScore: Score
+}
+```
+
+리뷰어: "*이 프로퍼티를 포함하여 스코어 관련 기능은 스코어 클래스로 이동해보면 어떨까요?*" — `Cards`가 *카드 컬렉션 + 점수 계산* 둘. `Score(cards)`가 *점수 단일 책임*. *Cards = 카드 보유*, *Score = 합산 + 보정* 분리. 학생 후속 반영.
+
+### 16. `DealerTest`가 *ACE 11 검사도 포함*
+
+```kotlin
+@Test fun `ACE를 11로 둘 때 17이상이면 뽑을 수 없다`() {
+    val dealer = Dealer()
+    dealer.draw(Card(CardMark.CLOVER, CardValue.ACE))
+    dealer.draw(Card(CardMark.CLOVER, CardValue.SIX))
+    assertThat(dealer.isContinue).isFalse
+}
+```
+
+리뷰어: "*17이상일 때에 대한 테스트이기 때문에 물론 지금도 좋지만 ACE가 11인지에 대한 것은 Dealer 테스트가 굳이 알 필요는 없는 것 같아요.*" — *Dealer.isContinue 책임 = 17 이상 안 뽑기*. *ACE 보정 책임 = Cards/Score*. *DealerTest*에 *ACE 룰까지* 검증하면 *복합 책임 테스트*. PR #28·#116과 같은 결.
+
+또: 함수명 *오타*: "*점수가 17이상이면 카드를 뽑을 수 없다*가 자연스러운 문장이겠네요" — *카드를* 누락.
+
+### 17. `GuestTest` *오타*: `'아지 않고'` / `'아니면'`
+
+```kotlin
+@Test fun `버스트가 아지 않고 블랙잭이아니면 카드를 뽑을 수 있다`() { ... }
+```
+
+리뷰어: "*사546한 오타가 있습니다.* 😵‍💫" — *테스트 이름 = 사양서*. 오타가 *사양 신뢰도* ↓.
+
+### 18. `OutputView`가 `print()` 여러 번 호출
+
+리뷰어: "*[print() 호출]보다는 [StringBuilder]를 사용하면 성능에 도움이 됩니다.* 여기서는 *많은 데이터를 다루지 않아 큰차이가 없겠지만 한 번 개선해보는 것은 어떨까요?* 💪" — *Kotlin: `buildString { ... }` 또는 `joinToString`*. PR #24와 같은 결.
+
+### 19. `outputResult` "최종 승패" 오타 (2단계는 "최종 수익")
+
+리뷰어: "*사소한 오타 : '최종 승패'가 아닌 '최종 수익'입니다.*" — 1단계 표현이 2단계로 *그대로 남음*. *요구사항 차이*가 *코드 반영 누락*. PR #146 (lotto) *기존 요구사항 누락*과 같은 결.
+
+### 20. `Cards.containsACE()` 함수 (UI 표시) vs `isContainsACE` 프로퍼티
+
+```kotlin
+class Cards { fun containsACE(): Boolean = ... }
+// 후속
+class Cards { val isContainsAce: Boolean = ... }
+```
+
+리뷰어: "*if else 구문은 한 줄 작성보다는 괄호를 추가해주는 게 좋을거 같아요.*" — 가독성 권고. 또 함수명 카멜 케이스 (`containsACE → isContainsAce`).
+
+## 리뷰어 의견 요지
+
+- ***`lateinit var` callback = 런타임 에러 위험*** — 생성자 주입.
+- ***`val 상태 / fun 행동` 명확히 구분*** — score는 val.
+- ***함수명 카멜 케이스*** (`isACE → isAce`).
+- ***상수 외부 노출 = 기능 분산 신호*** — 단일 클래스 내부로.
+- ***`Money.toInt()`보다 `val value: Int` 직접 노출***.
+- ***require 검증 + Controller 재입력 = 레이어 분리***.
+- ***Util 클래스 vs toString = 트레이드오프, 학생 결정 존중***.
+- ***exhaustive when = 새 case 추가 누락 방지***.
+- ***`size: val` / `nextCard: fun` 명명 차이 = 상태 vs 동작***.
+- ***`isContinue` 영문 형용사 → `isContinuable`***.
+- ***Outcome에 rate 결합 = 결과 + 수익률 결합***.
+- ***State.matchWith의 상태 전이 누락 = 런타임 에러*** — 모든 전이 테스트.
+- ***Cards → Score 책임 분리***.
+- ***`DealerTest`에 ACE 룰 검증 = 복합 책임 테스트***.
+- ***테스트 이름 오타 = 사양 신뢰도 ↓***.
+- ***`print` 여러 번 < `buildString`***.
+- ***1단계 표현 잔존 = 요구사항 변화 반영 누락***.
+
+## 대표 인용
+
+> *해당 함수를 넘겨주지 않아도 컴파일 에러는 없지만 런타임 에러가 발생*하게 됩니다. 이 경우를 대비할 수 있는 방법을 고민해보면 어떨까요?
+> — @woowajames on `BlackJackGame.kt`
+
+> score(), isBlackJack(), isBust(), draw() 모두 함수로 만드셨네요. *어떤 기준으로 만드신걸까요?* *행동은 상태를 변경시킵니다.* *상태와 행동을 구분*하면 좋겠습니다.
+> — @woowajames on `User.kt`
+
+> 정답이 없는 문제이기 때문에 *사람마다 다르게 생각할 수 있다고 봐요.* 모든 리뷰에 대해 *수정할 필요도 없고 아크 생각에 이게 낫다고 판단되면 그대로 두셔도 됩니다!* 지금처럼 *아크만의 생각을 정립하는 게 이러한 리뷰 시간에서 얻어가는 것*이라고 생각합니다.
+> — @woowajames on `CardViewUtil.kt`
+
+> 현재 구조에서 *Hit에서도 Stay의 matchWith()를 타고 들어오는데요*. 이 경우엔 *무조건 else 문으로 처리되어 프로그램이 정상적인 동작을 할 수 없습니다*.
+> — @woowajames on `Stay.kt`
+
+## 얻은 교훈
+
+- ***`lateinit var callback` = 런타임 에러 잠재*** — 생성자 인자 주입이 자연. PR #92·#29·#114·#33과 같은 결.
+- ***`val 상태 / fun 행동` Kotlin 컨벤션*** — score는 *카드 합 = 파생 상태* → `val score: Int`. *draw는 변경 → fun*. PR #135·#10·#33과 같은 결.
+- ***함수명 카멜 케이스 (`isACE → isAce`)***.
+- ***상수 외부 노출 = 기능 분산 신호*** — *단일 클래스 내부 사용*이 자연.
+- ***`value class`에 `val 노출`이 자연*** — `toInt()` 같은 Java 어휘 변환자 불필요.
+- ***require 도메인 invariant + Controller 재입력 = 레이어 분리*** — 도메인은 *예외 throw만*, 재입력 루프는 *Controller*.
+- ***Util 클래스 vs toString 오버라이딩 = 정답 없는 트레이드오프*** — *유틸 결합도 vs 도메인 결합도*. 학생 *판단 정립이 학습 목적*.
+- ***exhaustive when = 새 enum 값 추가 시 컴파일 에러 = 누락 방지*** — *else 분기*는 *방어*지만 *추가 알림 기능*은 없음.
+- ***`size: val` / `nextCard: fun` 명명 차이 = 상태 vs 동작 시그널***.
+- ***`isContinue` 영문 형용사 부재*** — `isContinuable`이 자연.
+- ***Outcome enum에 rate 결합 = 결과 + 수익률 의미 혼합*** — *결과만 enum, 수익률은 별도 계산*도 옵션.
+- ***State.matchWith의 상태 전이 누락 = 런타임 에러*** — *모든 상태 전이 그래프*를 *테스트로 검증*. State 패턴 도입 시 *전이 누락이 가장 흔한 버그*.
+- ***Cards → Score 책임 분리*** — *Cards = 카드 보유*, *Score = 합산 + 보정*. PR #92와 같은 결.
+- ***`DealerTest`에 ACE 룰 검증 = 복합 책임*** — *대상 클래스의 책임만* 테스트.
+- ***테스트 이름 오타 = 사양 신뢰도 ↓*** — *테스트 = 사양서* 원칙.
+- ***1단계 표현 (`최종 승패`)이 2단계 (`최종 수익`)에 잔존 = 요구사항 변화 반영 누락*** — *체크리스트 또는 grep 도구*로 변경 누락 점검.

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

@@ -0,0 +1,297 @@
+# PR #8 — [블랙잭 1단계] 아크 미션
+
+- **Reviewee:** [@re4rk](https://github.com/re4rk)
+- **PR:** https://github.com/woowacourse/kotlin-blackjack/pull/8
+- **단계:** 1단계 (DSL Builder 시도)
+- **리뷰어:** @woowajames (제임스)
+- **라인 코멘트:** 30 (리뷰어 22 / 리뷰이 8)
+- **참고:** 같은 학생의 2단계 = [PR #34](./34-2단계-블랙잭.md)
+
+## 잘한 점 (설계 관점)
+
+- **`BlackJackBuilder + cardDeck + participants` DSL** + `BlackJack data class` 구성.
+- **`abstract User` + `Dealer`/`Guest`** + `isContinue` 추상.
+- **`Score(cards: Cards)` 점수 계산 객체** + `minScore`/`maxScore` (Ace 보정).
+- **`Cards` 일급 컬렉션 + `operator fun plus` immutable 패턴**.
+- **`Name` value class 원시값 포장**.
+- **DSL 학습 적용 — `study/PersonBuilder` + `SkillsBuilder` + `LanguagesBuilder`**.
+- **후속 반영 — `CardValueTest` ParameterizedTest + CsvSource 적용**.
+
+## 못한 점 (설계 관점)
+
+### 1. `study/Test.kt` 학생 코드에 페어 닉네임 (`로피`) — 본인 닉네임 (`아크`) 미사용
+
+리뷰어: "*정말 사소한 것이지만 페어가 아닌 본인 닉네임을 사용하면 좋았을 것 같아요.*" — *페어 코드를 그대로 가져옴* 신호. *학생 자신의 흔적*이 *학습 과정 가시화*.
+
+### 2. `LanguagesBuilder` *Korean/English 하드코딩*
+
+```kotlin
+class LanguagesBuilder {
+    var korean = 0; var english = 0
+    infix fun String.level(grade: Int) {
+        when (this) {
+            "Korean" -> korean = grade
+            "English" -> english = grade
+        }
+    }
+}
+data class Languages(val korean: Int, val english: Int)
+```
+
+리뷰어: "*Korean, English 외 언어에 관한 입력은 처리가 불가능한 형태입니다. Skills를 참고하여 변경*해보면 좋겠네요." — **확장성 부재**. *Skills처럼 `Map<String, Int>`* 또는 *List<Language>*로. *enum 또는 값 객체*로 *언어 추가 가능*.
+
+### 3. `Test`가 *오류 케이스 검증 X*
+
+리뷰어: "*hard 스킬에 kotlin을 넣으려고 의도했지만 오류로 결과적으로 java라는 값이 들어갈 수도 있다면 이 테스트 코드가 그걸 검증해 줄 수 있나요?* *개인적으로는 심리적 안정감에 도움이 되지 않는 테스트 코드라고 생각합니다.*" — **테스트가 *의도와 다른 동작*을 못 잡으면 *안전감 X***. *정상 입력*만 검증하면 *오류 경로*는 무방비. *입력 검증 + 의도 위반 케이스*가 *진짜 테스트*.
+
+### 4. `BlackJackBuilder` + `lateinit` + DSL — 학생의 *DSL 적용 욕구*
+
+```kotlin
+private fun setBlackJack(): BlackJack = BlackJackBuilder.init {
+    cardDeck(Card.all().shuffled())
+    participants {
+        dealer("딜러")
+        guests(inputView.inputParticipants())
+    }
+    draw()
+}
+```
+
+→ **PR #29 (tmdgh1592) Builder + DSL과 같은 패턴**. *수업에서 배운 기능 적용 욕구*가 *과잉 적용*을 만드는 점. (다만 PR #34에서는 학생이 *DSL을 유지*하고 *Builder 자체*는 *수업 학습 결과로 인정*받음.)
+
+### 5. `BlackJackGame`의 *멤버 확장 함수 + `lateinit var input`*
+
+```kotlin
+class BlackJackGame {
+    private lateinit var input: (String) -> String
+    fun input(func: (String) -> String) { input = func }
+
+    fun BlackJack.guestsTurn(output: (User) -> Unit) =
+        guests.forEach { guest -> guestTurn(guest, output) }
+
+    fun BlackJack.dealerTurn(output: () -> Unit) { ... }
+    private fun BlackJack.guestTurn(guest: Guest, output: (User) -> Unit) { ... }
+    private fun Guest.getCommand() = input(this.name.toString())
+}
+```
+
+리뷰어: "*멤버 확장 함수의 사용은 지양하는 것이 좋습니다. 현재 꼭 필요한지 모르겠고 개인적으로는 코드의 가독성이 매우 떨어진다고 생각*됩니다." — **`class BlackJackGame { fun BlackJack.foo() }` 멤버 확장 함수**는 *BlackJack의 메서드인 듯 보이지만 실제로는 BlackJackGame 안에서만 호출 가능*. *수신자 + 컨텍스트* 두 가지가 호출 사이트에서 *모호*. Kotlin 권고: *최상위 확장 함수* 또는 *일반 메서드*.
+
+또: `lateinit var input` + `fun input(func)` setter 패턴 = PR #34와 동일 안티패턴.
+
+### 6. `BlackJack`이 *3개 이상의 인스턴스 변수* — 요구사항 위반
+
+```kotlin
+data class BlackJack(val cardDeck: CardDeck, val participants: Participants, ...)
+```
+
+리뷰어: "*3개 이상의 인스턴스 변수를 가진 클래스를 쓰지 않는다.* 위 요구 사항을 지켜보면 어떨까요?" — **요구사항 (3변수 제한)** PR #92·#135와 같은 결. 학생이 *3변수 위반*. *형식 규칙은 강제*. 단 *PR #92·#135처럼 인공 객체 만들지 않게*도 주의.
+
+### 7. `Score`도 *3개 이상의 인스턴스 변수* 위반
+
+```kotlin
+class Score(val cards: Cards) {
+    val score: Int; val isNotBust: Boolean; val checkDealerScore: Boolean
+    private val minScore: Int; private val maxScore: Int
+    private val validateAceCondition: Boolean; private val isMaxScoreInRange: Boolean
+}
+```
+
+리뷰어: 동일 코멘트 반복. — *Score 안에 여러 파생 프로퍼티*. *get() 함수*로 계산하면 *멤버 변수 아님*. 그러나 *backing val*로 보유하면 *멤버 카운트*. **`get()` vs `val` 선택의 *요구사항 충족 여부* 영향**.
+
+### 8. `Score`가 *외부 상수 참조* (`BlackJackGame.BLACKJACK_NUMBER`)
+
+```kotlin
+class Score(val cards: Cards) {
+    val isNotBust: Boolean get() = minScore <= BlackJackGame.BLACKJACK_NUMBER
+    val checkDealerScore: Boolean get() = maxScore < DEALER_MIN_NUMBER
+    private val validateAceCondition: Boolean get() = minScore + ACE_OTHER_NUMBER_DIFF <= BlackJackGame.BLACKJACK_NUMBER
+}
+```
+
+리뷰어: "*BlackJackGame에 있는 상수를 직접 참조하지 않는 방향을 고민해보세요.* 그리고 *Score라는 클래스에 버스트 상태 확인하는 것이 적절한지 모르겠*습니다." / 후속: "*변수명에도 DEALER라고 명확히 적혀있다는 것은 딜러가 가져야할 역할과 관련*되어 있다는 의미가 아닐까요?" / "*`BLACKJACK_NUMBER = 21` 같은 상수가 여러 곳에서 사용중*입니다. 만약 *해당 값에 변경이 발생한다면 모두 찾아서 변경*해줘야 하며 *실수로 빠뜨리면 버그가 발생*할 수 있습니다. *하나의 상수로 해결 할 수 있는 구조에 대해 고민*해보세요." — **상수의 단일 정의**. `Score` 외부에서 *BLACKJACK_NUMBER* 참조 = *Score가 BlackJackGame의 상수 알아야 함* = *역방향 의존*. *DEALER_MIN_NUMBER*는 *Dealer의 룰*인데 *Score에 있음* = *책임 누수*.
+
+### 9. `Score.checkDealerScore` — 변수명 vs Boolean 컨벤션
+
+```kotlin
+val checkDealerScore: Boolean get() = maxScore < DEALER_MIN_NUMBER
+```
+
+리뷰어: "*보통 Boolean 타입은 is로 시작*하죠. 네이밍에 일관성을 맞추면 더 좋겠어요." — Kotlin/Java 컨벤션: `is`/`has`/`can` 접두사. `checkDealerScore`는 *명사 동사형 X*. `isDealerScoreInsufficient` 또는 `canDealerDraw`.
+
+### 10. `Guest`에 *불필요한 주석* + dealer 오타
+
+```kotlin
+class Guest(name: String) : User(name) {
+    override val isContinue: Boolean // dealer    // ⚠ Guest인데 dealer 주석
+}
+```
+
+리뷰어: "*불필요한 주석인 것 같고 dealer가 아니라 guest네요.*" — **복사-붙여넣기 흔적**. 학생이 *Dealer 코드를 베이스로 Guest 작성*. *주석이 코드의 진실보다 늦게 갱신* = *주석 ≠ 코드 룰*. *주석 자체를 지우는 게 더 안전*.
+
+### 11. `OutcomeTest` 함수명 모호 — *누가 지는가*
+
+```kotlin
+@Test fun `딜러와 유저의 점수가 둘 다 21점 이상이면 비긴다`() { ... }
+```
+
+리뷰어: "*누가 지는건가요? 단순히 테스트명이 문제가 아니라 Outcome의 of 함수부터 애매모호*합니다." — **`Outcome.of(dealer, guest)` 자체가 주어 부재**. *누구의 결과인가*. `Outcome.of(player, opponent)` 또는 `player.match(opponent)`. PR #28·#10·#125·#63·#34와 같은 결.
+
+### 12. `CardDeckTest` *애매한 함수명* "잘 있는지"
+
+```kotlin
+@Test fun `카드덱 잘 있는지 확인`() { ... }
+```
+
+리뷰어: "*잘 있는게 뭔가요? 어떤 상태가 잘 있는거죠? 무엇을 테스트하는 것인지 좀 더 상세하고 명확하게 작성*해주세요.(이하 동일)" — **테스트 함수명 = 사양서**. "잘 있는"은 *입력/결과 명시 부재*. *카드덱이 52장이다*, *중복 카드가 없다* 같은 *구체 시나리오*.
+
+### 13. `Outcome.of(dealer, guest)` — 정적 비교자
+
+```kotlin
+enum class Outcome { WIN, DRAW, LOSE; companion object { fun of(dealer: Dealer, guest: Guest): Outcome { ... } } }
+```
+
+→ `dealer.match(guest)`가 자연. PR #28·#63·#125·#10·#33·#24·#116·#29·#17·#81·#119 권고와 동일.
+
+### 14. `Cards.containsACE()` vs `isContainsAce()` 명명
+
+```kotlin
+fun containsACE(): Boolean = ...
+```
+
+리뷰어: "*isContainsAce()라는 네이밍이 좀 더 어울리지 않을까요?*" — *동사 contains*가 *함수명에 적합*하나 *Kotlin Boolean 관례는 `is*` 접두*. 또 `ACE` 대문자가 *카멜 위반*(PR #34 후속과 같은 결).
+
+### 15. `Score.kt`에 *Score 테스트 부재*
+
+리뷰어: "*Score에 대한 테스트 코드도 작성해보시죠!*" — *블랙잭의 핵심 = 점수 계산*. *Ace 보정 + Bust + 비교*가 모두 Score 안. *테스트 부재 = 룰 검증 부재*.
+
+### 16. `CardDeck` Kotlin 컨벤션 순서
+
+```kotlin
+class CardDeck(cards: List<Card>) {
+    private val cards: MutableList<Card> = cards.toMutableList()
+    init { ... }
+    val size: Int get() = cards.size   // ⚠ init 후 val 선언
+}
+```
+
+리뷰어: "*[코틀린 컨벤션]에 따라 위치를 조정하면 좋을 것 같아요.* 1. *Property declarations and initializer blocks* 2. *Secondary constructors* 3. *Method declarations* 4. *Companion object*" — Kotlin Class Layout 권고: *property → init → constructor → method → companion*. *`val size`는 property*인데 *init 후*에 위치 = 순서 위반.
+
+### 17. `InputView` *(예는 y, 아니오는 n) 안내 누락*
+
+리뷰어: "*(예는 y, 아니오는 n) 에 대한 안내가 없습니다.*" — **사용자에게 입력 가이드 제공 = UI 책임**.
+
+### 18. `InputView.inputParticipants` 빈 이름 처리 — 원시값 포장 미적용
+
+```kotlin
+fun inputParticipants(): List<String> {
+    println(...)
+    return readln().split(",").map { it.trim() }   // ⚠ 빈 이름 무방비
+}
+```
+
+리뷰어: "*모든 원시 값과 문자열을 포장한다* *이름을 공백으로 여러명을 넣어도 동작*을 하네요. *원시 값 포장을 통해서 예외 처리*를 하면 어떨까요?" — *Name value class*에서 `init { require(value.isNotBlank()) }`. PR #28·#24·#10과 같은 결.
+
+### 19. `Controller`가 `Card.all().shuffled()`를 *직접 호출* — Deck이 자체 셔플 X
+
+```kotlin
+private fun setBlackJack(): BlackJack = BlackJackBuilder.init {
+    cardDeck(Card.all().shuffled())    // ⚠ Controller가 셔플 후 전달
+    ...
+}
+```
+
+리뷰어: "*현재 Card 클래스는 단순히 Card를 넘어서 Cards의 역할까지 하는 것 같습니다*. *CardDeck에 Cards를 주입하는 것은 좋습니다!* 그런데 *Card와 CardDeck의 차이는 뭘까요?* CardDeck 내부에도 cards 프로퍼티가 있는데 *외부에서 셔플을 해서 넘겨주기 보다 내부에서 그 역할을 할 수 있는 방법*을 고민해보면 어떨까요?" — **`Card.all() + shuffled()`이 Controller에 = Deck의 자체 책임 누수**. *Deck = 52장 + 셔플 + 뽑기*가 단일 책임. PR #111의 *Controller에서 미리 셔플*은 *테스터빌리티 이유*였으나 여기는 *그냥 외부 호출*.
+
+### 20. `BlackJackController`가 *y에만 응답 처리* — 그 외는 No
+
+```kotlin
+// y만 처리, 그 외는 카드 안 받음 (n이 아니어도)
+```
+
+리뷰어: "*y에 대한 처리만 있고 그 외에는 n이 아니더라도 아무 값을 입력하면 카드를 받지 않는 것으로 되어 있네요.*" — **입력 검증 부재**. *yY/nN* 외 입력 시 *명확한 안내*가 *UI 책임*.
+
+### 21. `Dealer.default value`
+
+```kotlin
+class BlackJackController(... 딜러 inject ...) { ... }
+```
+
+리뷰어: "*딜러는 변경될 가능성이 적으니 굳이 현재 시점에서 주입 받기보다 default value를 사용*해보는 것은 어떨까요?" — **DI 과잉**. *변경 가능성 낮은 의존*은 *기본값으로 단순화*. *테스트에서 교체 필요*하면 *기본값 + 명시 주입* 둘 다 가능.
+
+### 22. `OutputView` *,로 구분*
+
+리뷰어: "*미션 실행 결과에는 ,로 구분되는데 적용해보면 어떨까요?*" — **요구사항 미충족** (출력 형식). PR #146 (lotto)와 같은 *요구사항 충실*.
+
+### 23. `OutputView` private 메서드
+
+리뷰어: "*private으로 해도 되겠네요.*" — *내부 사용 메서드*는 *최소 가시성*.
+
+### 24. `docs/README.md` 기능 요구사항 미충족
+
+리뷰어: "*다음 사항에 관한 구현 여부를 확인해보세요. 기본적인 기능 요구 사항을 만족하지 않고 있습니다.* - *딜러는 처음에 받은 2장의 합계가 16이하이면 반드시 1장의 카드를 추가로 받아야 하고, 17점 이상이면 추가로 받을 수 없다.* - *플레이어는 21을 넘지 않을 경우 원한다면 얼마든지 카드를 계속 뽑을 수 있다.* (현재 *플레이어 카드가 K, ACE 일 때도 카드를 더 받을 것인지 묻고* 있습니다. *Ace를 언제 1 또는 11로 계산할지 좀 더 고민*이 필요해보여요.)" — **블랙잭 룰 누락 + Ace 처리 미흡**. PR #10·#92·#116·#119와 같은 결.
+
+## 리뷰어 의견 요지
+
+- ***페어 닉네임 그대로 사용 = 학습 흔적 없음***.
+- ***DSL이 *Korean/English 하드코딩* = 확장성 부재***.
+- ***정상 입력만 테스트 = 오류 경로 무방비***.
+- ***멤버 확장 함수 = 호출 사이트 모호***.
+- ***`lateinit var input + fun input(func) setter` 패턴***.
+- ***3변수 제한 요구사항 충족 vs 인공 객체*** — 트레이드오프.
+- ***외부 상수(`BlackJackGame.BLACKJACK_NUMBER`) 참조 = 역방향 의존***.
+- ***`Score.checkDealerScore`가 Score 안 = 책임 누수***.
+- ***Boolean 함수명 `is*` 접두사***.
+- ***불필요 주석 + 잘못된 주석 (`// dealer`)***.
+- ***테스트 함수명 *누가 지는가* 명시 부재***.
+- ***Cards.containsACE 카멜 + Boolean 접두사***.
+- ***Score 테스트 부재 = 핵심 룰 검증 부재***.
+- ***Kotlin Class Layout 순서***.
+- ***`(예는 y, 아니오는 n)` 안내 누락***.
+- ***Name 원시값 포장 + 빈 이름 검증***.
+- ***Deck 외부 셔플 = Deck 책임 누수***.
+- ***y만 처리 + 그 외 No = 입력 검증 부재***.
+- ***Dealer 기본값 vs DI = 변경 가능성에 따라***.
+- ***출력 형식 *,로 구분* 요구사항 미충족***.
+- ***딜러 16 이하 추가 + ACE 1/11 결정 룰 누락***.
+
+## 대표 인용
+
+> hard 스킬에 kotlin을 넣으려고 의도했지만 *오류로 결과적으로 java라는 값이 들어갈 수도 있다면 이 테스트 코드가 그걸 검증해 줄 수 있나요?* 개인적으로는 *심리적 안정감에 도움이 되지 않는 테스트 코드*라고 생각합니다.
+> — @woowajames on `Test.kt`
+
+> 멤버 확장 함수의 사용은 *지양*하는 것이 좋습니다. 현재 꼭 필요한지 모르겠고 *개인적으로는 코드의 가독성이 매우 떨어진다*고 생각됩니다.
+> — @woowajames on `BlackJackGame.kt`
+
+> `BLACKJACK_NUMBER = 21` 같은 상수가 *여러 곳에서 사용중*입니다. 만약 *해당 값에 변경이 발생한다면 모두 찾아서 변경*해줘야 하며 *실수로 빠뜨리면 버그가 발생*할 수 있습니다.
+> — @woowajames on `Score.kt`
+
+> 현재 Card 클래스는 *단순히 Card를 넘어서 Cards의 역할*까지 하는 것 같습니다. [...] *외부에서 셔플을 해서 넘겨주기 보다 내부에서 그 역할을 할 수 있는 방법*을 고민해보면 어떨까요?
+> — @woowajames on `BlackJackController.kt`
+
+> 다음 사항에 관한 구현 여부를 확인해보세요. *기본적인 기능 요구 사항을 만족하지 않고 있습니다.*
+> — @woowajames on `docs/README.md`
+
+## 얻은 교훈
+
+- ***페어 닉네임 그대로 사용 = 학습 흔적 부재*** — 본인 닉네임으로 자기 사고 명시.
+- ***DSL Builder의 하드코딩은 확장성 부재*** — *enum 또는 Map*으로 *추가 가능*.
+- ***정상 입력만 테스트 = 의도와 다른 동작 못 잡음*** — *오류 경로*도 *심리적 안정감*의 일부.
+- ***멤버 확장 함수 `class Foo { fun Bar.baz() }` = 호출 사이트 모호*** — *수신자 + 컨텍스트* 두 가지가 호출 시 *명시 X*. Kotlin 권고: *최상위 확장* 또는 *일반 메서드*.
+- ***`lateinit var callback + fun setter` = PR #34와 동일 패턴*** — 생성자 주입.
+- ***3변수 제한 = 요구사항 충실 vs 인공 객체 = 트레이드오프*** — PR #92·#135와 같은 결.
+- ***외부 클래스 상수 참조 = 역방향 의존*** — *Score가 BlackJackGame.BLACKJACK_NUMBER*를 알면 *Score → BlackJackGame 의존*. 상수 단일 정의 + 의존 방향 정리.
+- ***`Score.checkDealerScore` = 책임 누수*** — *DEALER 룰*은 *Dealer*. *Score는 점수만*. *변수명에 DEALER가 박혀있으면 책임 잘못 배치 신호*.
+- ***Boolean 함수명 `is`/`has`/`can` 접두사*** — `checkDealerScore`처럼 *동사 명사형*은 *Boolean의 의미*를 흐림.
+- ***주석은 코드보다 늦게 갱신 = 거짓말 위험*** — `// dealer` 같은 *잘못 남은 주석*. *주석 제거가 안전*.
+- ***`Outcome.of(dealer, guest)` 정적 비교자 = 주어 부재*** — *누구의 결과인가*가 *함수 시그니처에서 명시*되지 않음. `player.match(opponent)`. 14개+ PR 연속 권고.
+- ***테스트 함수명 "잘 있는지" 같은 모호 표현 = 사양서로 거짓*** — *입력 + 결과* 명시.
+- ***Score 테스트 부재 = 핵심 룰 검증 부재*** — *블랙잭 = 점수 계산*이 가장 중요한 도메인 룰.
+- ***Kotlin Class Layout 순서*** — property → init → constructor → method → companion.
+- ***`(예는 y, 아니오는 n)` 안내 = UI 책임*** — *사용자 가이드 표시*.
+- ***Name value class에 `require(isNotBlank())` invariant*** — *원시값 포장 + 검증*. PR #28·#24·#10과 같은 결.
+- ***Deck 외부 셔플 = Deck 책임 누수*** — *52장 + 셔플 + 뽑기*가 단일 책임.
+- ***`y만 처리` 입력 검증 부재 = 사용자 경험 ↓*** — *yY/nN 외 입력 시 명시 안내*.
+- ***Dealer 기본값 vs DI*** — *변경 가능성 낮은 의존*은 *기본값*, *테스트 교체 필요*하면 *기본값 + 명시 주입*. **변경 가능성에 따른 DI 결정**.
+- ***출력 `,로 구분` 같은 형식 요구사항 충실*** — *요구사항 = 도메인의 일부*.
+- ***딜러 16 이하 추가 + ACE 1/11 결정 룰 누락 = 블랙잭 룰 미반영*** — 14개+ PR 연속 *블랙잭 룰 정확 이해* 권고.