oh-my-oop 0.2.0

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

@@ -0,0 +1,213 @@
+# PR #42 — [글로] 2단계 블랙잭
+
+- **Reviewee:** [@ippnsj](https://github.com/ippnsj) (글로)
+- **PR:** https://github.com/woowacourse/kotlin-blackjack/pull/42
+- **단계:** 2단계
+- **리뷰어:** [@galcyurio](https://github.com/galcyurio)
+- **라인 코멘트:** 13 스레드 — *학생 자가 답변 + PR 본문 *컨트롤러 테스트 의도* 자가 질문 + Controller = presentation logic 4-layer 분류 어휘 정점 + 콜백 명명 도메인 입장 (block → onDealerHit) + Player vs BettingPlayer 어색 학생 자가 의문 → BettingPlayers (복수) 객체 + Domain→Presentation 매퍼 패턴 + PlayerInfo 분리 안티패턴 + assertj SoftAssertion*
+- **ippnsj 양 단계 완성** (1단계 #30).
+
+## 잘한 점 (설계 관점)
+
+### 1. PR 본문 — 컨트롤러 테스트 자가 의문
+
+PR 본문:
+
+> *"다른 크루들로부터 리뷰어님이 컨트롤러 테스트가 필요하다고 생각하신다는 것을 들었습니다. 그래서 제 나름 컨트롤러 테스트가 왜 필요할까 생각해 보았을 때, **컨트롤러가 실행해야 하는 로직을 실행하지 않는 것을 잡기 위해서 필요할 수 있다고 생각**했고, 이것을 테스트하는 것을 중심으로 컨트롤러 테스트 코드를 짜보았습니다! 🤗"*
+
+→ **학생 자가 컨트롤러 테스트 가치 자가 도달** ⭐⭐⭐ 학습 모범.
+
+### 2. interface로 플랫폼 의존성 제거 (Thread 1)
+
+reviewer: *"interface를 통해 Controller에서 플랫폼 의존성 제거 👍"*
+
+→ 1단계 `interface-for-randomness-test-injection` 결 합류.
+
+### 3. 불변 + 상태 패턴 칭찬 (Thread 11)
+
+reviewer: *"불변 + 상태 패턴으로 모두 리팩터링하셨군요 👍"*
+
+→ PR #154 (tobae-time 상태 패턴) 결 합류.
+
+## 못한 점 (설계 관점)
+
+### 1. Controller = presentation logic — 4-layer 분류 어휘 (Thread 0) — 정점
+
+reviewer (학생 PR 본문 자가 의문 답):
+
+> *"저는 모든 layer에 대해 테스트 코드를 작성할 수 있어야 한다고 생각해요. 비단 Controller 뿐만이 아니라 View가 속하는 UI layer 또한 마찬가지입니다. 다만, 미션 요구사항에서는 UI layer에 대한 테스트는 제외했기 때문에 따로 피드백은 드리지 않고 있습니다."*
+
+reviewer 4-layer 분류 어휘:
+
+> *"제 기준에서 로직은 크게 2개로 나눌 수 있습니다.*
+> *- ui logic*
+> *- business logic*
+>
+> *여기서 business logic은 세부적으로 아래와 같이 나눌 수 있습니다.*
+> *- **presentation logic: Controller, Presenter, ViewModel***
+> *- **domain logic: blackjack과 같이 해당 도메인과 밀접한 로직***
+> *- **data logic: API를 요청하거나 로컬 저장소에 접근하는 로직***
+>
+> *Controller에는 presentation logic이 존재합니다. MVC 패턴으로 이야기하자면 Model을 호출하고 View에 전달하는 로직입니다. 이 로직이 잘못되는 경우 프로그램도 잘못 동작하게 되므로 마찬가지로 테스트되어야 합니다.*
+>
+> *안드로이드에서는 특히나 presentation logic을 domain logic보다 많이 작성하게 되므로 더 중요합니다."*
+
+→ **MCP 룰 `controller-presentation-logic-must-test`** ⭐⭐⭐ **신규 정점** — *Controller = presentation logic = 테스트 대상*. PR #48 (`controller-to-domain-test-enablement`)·PR #47 (sujin9 컨트롤러 브릿지)·PR #72 (`controller-classification-criteria`) 결 합류 누적 4 PR → ***Controller 테스트 가치 어휘*** ⭐⭐⭐ 정점.
+
+→ **MCP 룰 `business-logic-4-layer-classification`** ⭐⭐⭐ 신규 — *ui logic / presentation logic / domain logic / data logic 4-layer*. PR #100·#106 (`android-onx-vs-domain-callback-confusion`) 결 합류 — *layer 어휘 정점*.
+
+### 2. 콜백 명명 도메인 입장 (Thread 3) — 핵심
+
+```kotlin
+fun play(block: (Card) -> Unit) { ... }
+```
+
+reviewer:
+
+> *"`block` 이라는 이름을 통해 어떤 역할인지를 알 수가 없습니다. 콜백함수 또한 분명한 역할이 있어야 합니다.*
+>
+> ***domain layer 에서는 ui layer에 대해서 알지 못해야 하므로 철저하게 domain의 입장에서 외부에 드러내기 위한 콜백함수를 선언해주세요. 예를 들면 `onDealerHit()`과 같습니다.***"*
+
+→ **MCP 룰 `callback-name-from-domain-perspective`** ⭐⭐⭐ **신규 정점** — *콜백 명명 = domain 입장 어휘 (View 동사 X)*. PR #80 (`callback-naming-view-coupling` printX/showX = View 동사)·PR #15 (`on` 전치사 콜백 어휘)·PR #137 (`onXX` 콜백) 결 누적 4 PR → ***콜백 명명 어휘 정점*** ⭐⭐⭐.
+
+### 3. Player vs BettingPlayer — 학생 자가 의문 + 자가 발견 (Thread 5)
+
+```kotlin
+data class BettingPlayer(val player: Player, val betting: Int)
+```
+
+reviewer: *"Player와 BettingPlayer가 나누어진 이유는 무엇인가요? **객체지향적으로 생각했을 때, player가 player를 가지고 있다는게 조금 어색하게 느껴져요.**"*
+
+학생 자가 답변:
+
+> *"게임에 참여하지 않은 유저와 게임에 참여한 유저로 나누고 싶었는데 Player라고 하면 좀 이상할 것 같네요! 플레이어 대신 유저로 바꾸면 괜찮을까요?"*
+
+학생 자가 추가 의문:
+
+> *"근데 이렇게 되면 유저가 Participant를 상속하는게 이상해지겠네욤ㅠㅠ"*
+
+reviewer:
+
+> *"그렇다면 **BettingPlayers라는 객체를 만들고 게임에 참여한 Player들만 가지도록** 만들어보면 어떨까요?"*
+
+학생: *"좋아용~!😄"*
+
+→ **MCP 룰 `actor-with-actor-self-reference-awkward`** ⭐⭐ 신규 — *Player가 Player를 가짐 = 객체지향적으로 어색 어휘*. PR #154 (`getter-setter-naming-as-missed-object` 어색 명명 신호) 결 합류 — *어색함 시그널* 다른 축.
+
+→ **MCP 룰 `collection-as-game-participant-filter`** ⭐⭐ — *BettingPlayers (복수) 객체 = 게임 참여자만 + 일급 컬렉션*. PR #15 결.
+
+### 4. Domain → Presentation 매퍼 패턴 (Thread 6·12)
+
+```kotlin
+// 같은 파일 (CardNumberModel.kt)
+enum class CardNumberModel(val text: String) {
+    ACE("A"), TWO("2"), ..., KING("K")
+}
+
+fun CardNumber.toPresentation(): CardNumberModel = when (this) {
+    CardNumber.ACE -> CardNumberModel.ACE
+    ...
+}
+```
+
+reviewer:
+
+> *"아래와 같이 별도의 클래스로 분리할 수도 있습니다. `number.toPresentation().text`"*
+
+→ **MCP 룰 `domain-to-presentation-mapper-pattern`** ⭐⭐⭐ **신규** — *Domain enum + Presentation enum + `toPresentation()` 매퍼*. PR #1단계 #30 (DTO 안티패턴) 결의 *DTO vs 매퍼* 다른 축 — *Presentation Model 어휘 정점*.
+
+→ **`mapper-top-level-declaration`** ⭐⭐ (Thread 8) — *mapper 함수 = 해당 클래스 선언된 곳 top-level*. *"조금만 큰 프로젝트를 진행해도 여러 곳에서 접근할 필요"*.
+
+### 5. PlayerInfo 분리 안티패턴 (Thread 9)
+
+```kotlin
+data class PlayerInfo(val name: String, val betting: Int)
+```
+
+reviewer:
+
+> *"Player라는 객체가 해당 정보를 가지고 있어야 합니다. **PlayerInfo를 선언하는 대신 Player에서 해당 필드들을 가지도록** 해보세요."*
+
+→ **MCP 룰 `info-suffix-as-misplaced-data`** ⭐⭐⭐ **신규** — *`XInfo` 분리 = 데이터 잘못된 위치 시그널*. PR #15 *`UserInfo` 만능 명사*·PR #155 결 합류 — *Info 접미사 안티패턴 강화*.
+
+### 6. expression body 한 줄 너무 김 (Thread 2)
+
+reviewer: *"한 줄이 너무 길어지는 경우에는 expression body 대신에 지역변수로 선언하는걸 추천드려요."*
+
+→ **`expression-body-too-long-as-local-var`** ⭐ — Kotlin 가독성. 누적 다수.
+
+### 7. assertj SoftAssertion (Thread 7)
+
+reviewer:
+
+> *"junit5의 soft assertion 기능을 쓸 때, 너무 길어지는 경우 assertj의 soft assertion 기능을 사용해보세요."*
+
+```kotlin
+val soft = SoftAssertions()
+soft.assertThat(...).isEqualTo(...)
+```
+
+→ **`assertj-soft-assertion-for-long-tests`** ⭐⭐ 신규 — *긴 테스트 시 assertj soft assertion 어휘*. PR #22 (`test-3-properties-clarity-completeness-conciseness`) 결 합류.
+
+### 8. List read-only = `_` 불필요 (Thread 10)
+
+```kotlin
+class BettingPlayers(players: List<Player>, ...) {
+    val players: List<Player> = players.toList()
+}
+```
+
+reviewer: *"List 자체는 읽기만 하고 변경하지 않기 때문에 `_` 없이 아래와 같이 작성하실 수 있습니다."*
+
+→ **`underscore-prefix-backing-property-only`** ⭐⭐⭐ — PR #12·#47·#42 누적 3 PR 강화.
+
+### 9. 불필요 콜백 호출 (Thread 4)
+
+reviewer: *"호출하는 곳을 보니 if문으로 분기하고 있어서 마지막 콜백 함수 호출은 불필요해보입니다."*
+
+→ **`unreachable-callback-call`** ⭐ — PR #144 (`unreachable-state-branch`) 결.
+
+## 대표 인용
+
+> [galcyurio Thread 0]
+> *"Controller에는 presentation logic이 존재합니다. MVC 패턴으로 이야기하자면 Model을 호출하고 View에 전달하는 로직입니다. 이 로직이 잘못되는 경우 프로그램도 잘못 동작하게 되므로 마찬가지로 테스트되어야 합니다."*
+
+→ **Controller = presentation logic 테스트 어휘 정점**.
+
+> [galcyurio Thread 0]
+> *"제 기준에서 로직은 크게 2개로 나눌 수 있습니다. - ui logic - business logic. (...) presentation logic / domain logic / data logic"*
+
+→ **4-layer logic 분류 어휘**.
+
+> [galcyurio Thread 3]
+> *"domain layer 에서는 ui layer에 대해서 알지 못해야 하므로 철저하게 domain의 입장에서 외부에 드러내기 위한 콜백함수를 선언해주세요. 예를 들면 `onDealerHit()`과 같습니다."*
+
+→ **콜백 도메인 입장 명명 어휘 정점**.
+
+> [galcyurio Thread 5]
+> *"객체지향적으로 생각했을 때, player가 player를 가지고 있다는게 조금 어색하게 느껴져요."*
+
+→ **객체 자기 참조 어색 어휘**.
+
+> [galcyurio Thread 9]
+> *"Player라는 객체가 해당 정보를 가지고 있어야 합니다. PlayerInfo를 선언하는 대신 Player에서 해당 필드들을 가지도록 해보세요."*
+
+→ **Info 접미사 = 데이터 잘못된 위치 어휘**.
+
+## 얻은 교훈 (보편)
+
+1. **Controller = presentation logic 테스트 대상** — **MCP 룰 `controller-presentation-logic-must-test` 후보** ⭐⭐⭐ 정점. PR #48·#47·#72 결 누적 4 PR.
+2. **business logic 4-layer 분류 (presentation / domain / data)** — **MCP 룰 `business-logic-4-layer-classification` 후보** ⭐⭐⭐.
+3. **콜백 명명 = domain 입장 (block → onDealerHit)** — **MCP 룰 `callback-name-from-domain-perspective` 후보** ⭐⭐⭐ 정점. PR #80·#15·#137 결 누적 4 PR.
+4. **Domain → Presentation 매퍼 패턴** — **MCP 룰 `domain-to-presentation-mapper-pattern` 후보** ⭐⭐⭐.
+5. **Info 접미사 = 데이터 잘못된 위치** — **MCP 룰 `info-suffix-as-misplaced-data` 후보** ⭐⭐⭐.
+6. **객체 자기 참조 어색 (player가 player 가짐)** — **MCP 룰 `actor-with-actor-self-reference-awkward` 후보** ⭐⭐.
+7. **`_` backing property 누적 3 PR + List read-only 강화** = MCP 룰 강화.
+8. **assertj SoftAssertion 긴 테스트 어휘** — **MCP 룰 `assertj-soft-assertion-for-long-tests` 후보** ⭐⭐.
+
+## 메타 노트
+
+- **ippnsj 양 단계 완성 (1단계 #30 → 2단계 #42)** — 1단계 PR 본문 자가 질문 2개 → 2단계 PR 본문 *컨트롤러 테스트 가치 자가 도달* → reviewer 깊은 4-layer 어휘 답변. **학생 자가 의문 → 추상 가치 도달** 학습 메타.
+- **galcyurio reviewer 어휘 정점** — *"개인적인 컨벤션으로는"* + *"제 기준에서"* — MCP `oh-my-oop` 핵심 가치 (단일 답 X) 어휘 양 PR 일관.
+- **Controller 테스트 가치 어휘 누적 4 PR** — Controller 분류 어휘 정점 (PR #48·#47·#72·#42).
+- **콜백 명명 어휘 누적 4 PR** — PR #15·#80·#137·#42 — 콜백 어휘 정점.

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

@@ -0,0 +1,247 @@
+# PR #73 — [블랙잭 1단계] 레오 미션
+
+- **Reviewee:** [@jaeyeongjo](https://github.com/jaeyeongjo)
+- **PR:** https://github.com/woowacourse/kotlin-blackjack/pull/73
+- **단계:** 1단계
+- **리뷰어:** @ghojeong (파이로)
+- **라인 코멘트:** 17 스레드 — *PR 본문 자가 의문 2개 (점 연산자 + private getter) + State 패턴 = 조건문 제거 핵심 + sealed class vs enum 매우 긴 토론 + 안드로이드 서버 통신 State 비유*
+- **신규 reviewee** (2024 코호트). PR #72 와 동일 reviewer.
+
+## 잘한 점 (설계 관점)
+
+- **PR 본문 자가 의문 2개**:
+  1. *"Participant의 state로부터 cards를 접근하는 과정에서 점(.) 연산자의 사용을 최소화하기 위해 Participant의 class에 아래와 같은 함수를 추가했습니다. (...) 이 함수가 실제로 불필요하게 느껴질 수도 있는지, 혹은 이러한 상황을 개선할 수 있는 더 나은 방법이 있는지 궁금합니다."*
+  2. *"저는 변수를 캡슐화하기 위해 private 접근 지정자를 사용하는 것이 좋은지, 아니면 private 없이 직접 변수에 접근하는 것이 나은지에 대해서도 궁금합니다."*
+  
+  **PR 본문 자가 의문 2개 모범**. PR #76·#82·#107·#46·#91·#11·#13·#80·#106·#14·#18 결.
+- **카드 미리 생성 + 카드덱에서 뽑기 칭찬** — ghojeong: *"Card 를 최초에 전부 생성하고, 카드덱에서 카드를 뽑는 다는 아이디어 참신해서 좋습니다. 👍"*. PR #74·#108·#133·#46·#23·#26 결.
+- **sealed class Participant 칭찬** — ghojeong: *"sealed class 문법을 활용해, Dealer 와 Player 외에는 Participant 를 상속하는 일이 없도록 방지해주신 점 무척 좋습니다. 👍"*. PR #98·#91·#43 결.
+- **`State` 디자인 패턴 사용 의도 확인** — ghojeong: *"객체명을 State 라고 지은 것은 [State 디자인 패턴](https://refactoring.guru/ko/design-patterns/state) 을 활용하였기 때문인가요? 그렇다면 State 를 가지고 있는 Participant 가 State 디자인패턴의 Context 가 되겠군요."* — **외부 자료 (refactoring.guru) + Context 어휘 명시**. PR #91 결.
+- **Hand 객체 분리 칭찬** — ghojeong: *"참고로 Participant 와 Hand 객체의 분리는 무척 잘해주셨다고 생각합니다. 👍"*.
+
+## 못한 점 (설계 관점)
+
+### 1. `Set` vs `List` (removeLast 어려움)
+
+ghojeong: *"List 가 아닌 Set 자료구조를 활용하는 것에 대해서는 어떻게 생각하시나요?"*
+
+학생: *"Set으로 할 경우, removeLast()를 구현하기가 복잡해져서 List로 구현했습니다..!"*
+
+→ **`Set` 메서드 어휘 한계 자가 인정**. *Set 은 *순서 X* + *removeLast X***. PR #23·#26·#11 결의 *Set vs List* 결.
+
+### 2. `랜덤 추상화` 권유
+
+ghojeong: *"자동차 게임과 로또에서 shuffled 와 같은 랜덤 요소를 추상화하는 법에 대해서 학습을 했으리라 생각이 듭니다. 랜덤 요소를 추상화하여, 테스트할 때는 랜덤한 카드 댁이 아니라 정해진 시나리오의 카드덱을 통해, 예측 가능한 게임 결과를 테스트하는 테스트 코드를 작성해주시기 바랍니다."*
+
+→ **이전 미션 학습 자가 연결 권유**. PR #91·#95·#23·#46·#22·#82 결.
+
+### 3. `Hand 분리 기준` 학생 자가 의문
+
+ghojeong: *"Hand 는 현재 Participant 의 손해 들려있는 카드라 이해했습니다. 각 Participant 는 본인의 이름과 State 를 가지고, 그 State 의 핵심은 손에 들려있는 카드인 Hand 이군요. (...) State 로부터 Hand 를 분리하셨을때 어떤 기준과 어떤 의도로 분리를 하셨는지 궁금합니다. (...) totalSum 을 계산하는게 Hand 의 핵심 역할인가요?"*
+
+학생 자가 후회: *"전체적인 구조가, 제가 봐도 난해한것같아요.. 전반적으로 구조를 개선하고 다시 푸쉬하겠습니다!"*
+
+→ **PR #145 (junseo511 *Hand 책임* 7 단계 토론) + PR #99·#77·#46·#43 결**. *Hand 책임 위치 토론 시리즈*.
+
+### 4. `THRESHOLD 상수 위치`
+
+ghojeong: *"static 상수의 위치는 여기가 적절한지 한번 다시 고민해보시면 좋을 것 같습니다. THRESHOLD_BUST 는 현재 Hit 에서만 사용되고 있고, THRESHOLD_HIT_FOR_DEALER 는 Participant 에서만 사용 되고 있는 듯 합니다. THRESOHOLD 상수를 State 에 전부 모은 이유가 따로 있으신가요?"*
+
+학생: *"State와 관련된 상수라고 생각하여, state에 모았는데, 다시 생각해보고 푸쉬하겠습니다!"*
+
+→ **상수 위치 = 의미 응집 + 사용처 근접**. PR #76·#11·#16·#9·#43·#137·#148·#18 결.
+
+### 5. `is 연산자 지양 = 다형성` — 핵심 메타 어휘
+
+ghojeong: *"is 연산자는 최대한 사용하지 않도록 해주시기 바랍니다. is 연산자를 사용하게 된다면, polymorphism 으로 해결할 수 있는 문제를 절차지향적인 조건문 분기로 해결하도록 설계했다고 생각해주시면 됩니다. 절차지향적인 설계를 의도하신 거라면 괜찮지만, 저희 과정에서는 객체지향과 함수형을 다루고 있기 때문에 is 연산자를 사용하지 말아달라고 피드백 드립니다."*
+
+→ **`is` 연산자 = 절차지향 시그널 = 다형성 회피**. **MCP 룰 후보 `is-operator-polymorphism-avoidance`**. PR #98·#39·#43·#152·#93·#136·#90·#66·#137·#148·#80·#82·#100 결.
+
+### 6. `State 디자인 패턴 = 조건문 제거 핵심`
+
+ghojeong: *"디자인 패턴을 사용했다면, 그 디자인 패턴이 해결하려고 한 문제가 해결되었어야 합니다. State 디자인 패턴이 해결하려고 한 핵심은 유한 상태 기계를 객체로 흉내냄으로써, 절차지형적인 조건문 분기를 없애는데 그 목적이 있습니다. 만약 State 디자인 패턴을 도입해서 조건문 분기가 늘어난다면, 저는 상태 디자인 패턴을 도입할 이유가 없다고 생각합니다."*
+
+→ **3 가지 학습**:
+
+#### 6.1. *디자인 패턴 도입 = 해결 문제 해결되어야 함*
+
+- *학생: State 패턴 도입 후 조건문 분기 잔존* = *패턴 효과 X*.
+- *MCP 룰 후보 `design-pattern-without-effect`* = *패턴 도입 후 의도 효과 X 시그널*. PR #98 (chaehyuns *상태 패턴 효과 자가 의문*) 결.
+
+#### 6.2. *State 패턴 핵심 = 절차지향 조건문 제거*
+
+- *유한 상태 기계 객체화 = 분기를 객체 다형성으로 위임*.
+- PR #93·#136·#152·#43 결.
+
+#### 6.3. *반복된 reviewer 의도 명시*
+
+ghojeong 의 *"제가 State 에 집착하는 것은"* (아래 §8 안드로이드 비유) — *동일 메타 어휘 반복 강조*.
+
+### 7. `Map<Participant, WinningState> 불필요` (State 패턴 정공)
+
+ghojeong: *"또한 지금 `Map<Participant, WinningState>` 형태로 결과를 가져오고 있는데, 만약 State 패턴이 제대로 구현되었다면, Participant 가 이미 state 를 멤버로 가지고 있으므로, 게임이 끝났을 때 participant 만으로 최종적인 state 를 알 수 있어야 합니다. `Map<Participant, WinningState>` 가 불필요하게끔, State 디자인 패턴에서 Context 의 역할을 다시 공부해주시면 좋을 것 같습니다."*
+
+→ **State 패턴 Context = State 보유**. PR #91·#98·#39·#43 결.
+
+### 8. `안드로이드 서버 통신 State 비유` — reviewer 의도 메타
+
+ghojeong: *"참고로 제가 State 에 집착하는 것은, 안드로이드 개발자로써 서버와 API 통신하는 것과 매우 밀접한 관련이 있는 부분이라 그렇습니다. 가령 지금은 WIN 과 LOSE 이지만, 서버 통신과 비교하면 서버 통신 SUCCESS 혹은 FAIL State 가 될 수도 있습니다. 통신을 하기 전의 NORMAL State가, 서버와 통신을 시작하면 LOADING State 가 될 수도 있고요. 결국 비동기까지 고려해서 굉장히 빈번히 State 가 바뀌게 되는데, 그때마다 전부 if 조건문으로 예외처리를 하기 시작하다보면, 어느 순간 숨이 턱 막히는 상태가 될 수 있습니다. 😭 안드로이드 앱이 한 화면을 그리기 위해서 호출하는..."*
+
+→ **3 가지 학습**:
+
+#### 8.1. *reviewer 가 *자신의 강조 이유* 메타 명시*
+
+- *학생이 *왜 State 에 집착하는가?* 의문할 수 있음 → reviewer 가 *안드로이드 실무 경험* 명시*.
+
+**MCP 룰 후보 `reviewer-emphasis-rationale-meta`** = *reviewer 가 자신의 강조 이유 명시 = 학생이 이해 깊어짐*.
+
+#### 8.2. *현실 도메인 (안드로이드 서버 통신) → 학습 도메인 (블랙잭 게임)*
+
+- *NORMAL → LOADING → SUCCESS / FAIL State* = *학습 가치*.
+- *블랙잭 도메인 = 작은 학습 → 실무 시나리오로 확장*.
+
+PR #100·#80·#82·#91 (안드로이드 경험 인용) 결.
+
+#### 8.3. *학생 자가 결정: 다형성 활용*
+
+학생: *"다형성을 이용해서 계산 로직을 간단화 해보겠습니다!"*
+
+### 9. `assertj is 연산자 vs 다형성 테스트`
+
+ghojeong: *"테스트를 할 때도 is 연산자 대신, assertj 문법을 더 적극적으로 활용해주시면 좋을 것 같습니다."*
+
+```kotlin
+assertThat(state).isInstanceOf(Hit::class.java)
+```
+
+→ **assertj API 어휘 활용**. PR #91·#46 결.
+
+### 10. `State enum vs sealed class` — 학생 자가 결정 변경 + 외부 글
+
+ghojeong (학생 enum 변환 후): *"State 를 전부 enum 으로 변경해주셨군요!"*
+
+학생: *"추후에 상황을 다시 평가해서 sealed class로 변경할 필요가 있을 수도 있지만, 현재로서는 enum을 사용한 구현이 제가 느끼기에는 더 적절해 보입니다!"*
+
+ghojeong (자신 경험 공유 + 외부 글):
+
+> *"넵 저도 enum 을 더 좋아하는 편입니다!*
+>
+> *참고로 저 또한 처음에 State 를 sealed class 로 시도했지만 (심지어 구글 공식 문서에서 권장했던 방식이었습니다.) 나중에 [enum 으로 리팩토링을 했던 경험](https://dvlv.tistory.com/158)이 있습니다.*
+>
+> *저는 다형성(Polymorphism) 이라는 키워드를 말씀드렸지만, 제 피드백에 휘둘리지 마시고, '객체 지향 생활 체조 원칙' 에 집중하시면 좋을 것 같습니다."*
+
+학생 자가 결정 변경: *"바로 밑의 피드백을 본 후에 다형성(Polymorphism)을 고민해보니,, State를 enum보다는 sealed class로 구현하는게 더 좋아보입니다! 이제서야 왜 State를 enum이 아닌 sealed class로 구현하는지 알겠네요!"*
+
+→ **5 가지 학습**:
+
+#### 10.1. *reviewer 자신 경험 + 외부 글 (블로그) 공유*
+
+PR #91·#82·#46·#22·#13 결.
+
+#### 10.2. *"제 피드백에 휘둘리지 마시고" 메타 어휘*
+
+**MCP 룰 후보 `reviewer-don't-be-swayed`** — *학생 자가 결정 존중*. PR #145 (lee-ji-hoon *"의견을 너무 어필 시"*) / PR #72·#22·#23·#26·#46·#43·#95·#91·#107 결.
+
+#### 10.3. *학생 자가 결정 변경 (enum → sealed class)*
+
+*"바로 밑의 피드백을 본 후에 다형성을 고민해보니"* — **학생 자가 reviewer 권고 후 자가 결정 변경**. PR #46·#76·#100·#107·#145 결.
+
+#### 10.4. *"이제서야 왜 ... 알겠네요"* — 학생 자가 깨달음 명시*
+
+*깨달음 = 학습 완료 시그널*.
+
+#### 10.5. *enum vs sealed class 양가성*
+
+- *enum* = *닫힌 집합 + 단순*.
+- *sealed class* = *닫힌 집합 + 멤버별 데이터 + 다형성 메서드*.
+
+PR #91·#43·#137·#90·#146 결.
+
+### 11. `else 예약어 + 연속 if 분기` 객체지향 생활 체조
+
+ghojeong: *"객체지향 생활 원칙 중 `else 예약어를 쓰지 않는다.` 가 있는데, 연속된 if 문 또한 이 원칙을 위반한다고 생각해주시면 좋을 것 같습니다. 제가 드리고 싶었던 피드백도 State 패턴을 쓰지 말라가 아니라, State 패턴을 제대로 썼다면 연속된 조건문이 사라져야 하는데, 그대로 남아있어서 State 패턴을 쓸 목적이 사라진 것 같다가 핵심이었습니다. 한 함수 내에서 if 문은 1개만 사용될 수 있도록 리팩토링 부탁드립니다."*
+
+→ **`else 예약어 + 연속 if = 객체지향 생활 체조 위반`**. **MCP 룰 후보 `consecutive-if-as-else-violation`**. PR #16·#23·#9 결.
+
+### 12. `Hand.calculateState 위치` 자가 학습
+
+ghojeong: *"calculateState 를 Participant 가 아니라 Hand 에 위치시킨 이유는, THRESHOLD 상수와, calculateCardsSum 때문이라고 생각해도 될까요? Hand 에 있는 메서드들은 Participant 에서만 활용되고 있는 듯한데, Participant 에서 Hand 객체를 분리할 때의 기준 같은게 있으셨는지 궁금해서 여쭤봅니다."*
+
+학생: *"그렇네요.. hand의 calculateState메쏘드는 Participant에서만 사용하고 있으니까 굳이 hand에서 calculateState을 정의할 필요가없겠네요!! 제가 생각하기에도 Participant에 정의하는게 맞다고 느껴집니다."*
+
+→ **함수 위치 = 사용처 응집**. PR #76·#13·#11·#16 결.
+
+### 13. `private 접근제어자` 명확화
+
+ghojeong suggestion:
+
+```kotlin
+private fun getState() = hand.calculateState()
+private fun isGameFinished() = getState() == State.Blackjack || getState() == State.Bust
+```
+
+학생: *"나름대로 접근제어자를 관리한다고 했는데, 애매한 부분이 많았네요. 좀 더 명확하게 접근제어자를 설정해서 다시 푸시해보겠습니다!"*
+
+→ **접근제어자 일관성**. PR #99·#43·#11·#82·#100 결.
+
+### 14. `THRESHOLD_BUST + THRESHOLD_BLACKJACK private const` suggestion
+
+ghojeong suggestion:
+
+```kotlin
+companion object {
+    private const val THRESHOLD_BUST = 21
+    private const val THRESHOLD_BLACKJACK = 21
+```
+
+→ **`private const` 접근제어자 + companion object 응집**. PR #43·#82·#9 결.
+
+## 리뷰어 의견 요지 (ghojeong / 파이로)
+
+17 코멘트 특징 (PR #72 와 동일 reviewer):
+
+- **`is 연산자 = 절차지향` 강한 메타 어휘** — **MCP 룰 후보 `is-operator-polymorphism-avoidance`**.
+- **`State 패턴 = 조건문 제거 핵심`** 반복 강조.
+- **안드로이드 서버 통신 비유** — *학생이 *왜 State 에 집착?* 의문 → reviewer 자가 *실무 경험* 명시*. **MCP 룰 후보 `reviewer-emphasis-rationale-meta`**.
+- **`제 피드백에 휘둘리지 마시고` 메타 어휘** — **MCP `oh-my-oop` 핵심 가치 (학생 결정 존중)**.
+- **외부 자료 (refactoring.guru, dvlv 블로그)** — PR #91·#82·#22·#13 결.
+- **suggestion 블록 다수** — `private const`, `private fun`, `assertj`.
+- **`객체지향 생활 체조 원칙` 명시** — PR #16·#23 결.
+
+## 대표 인용
+
+> *"is 연산자는 최대한 사용하지 않도록 해주시기 바랍니다. is 연산자를 사용하게 된다면, polymorphism 으로 해결할 수 있는 문제를 절차지향적인 조건문 분기로 해결하도록 설계했다고 생각해주시면 됩니다."* — ghojeong (is 연산자 = 다형성 회피 메타)
+
+> *"디자인 패턴을 사용했다면, 그 디자인 패턴이 해결하려고 한 문제가 해결되었어야 합니다. State 디자인 패턴이 해결하려고 한 핵심은 유한 상태 기계를 객체로 흉내냄으로써, 절차지형적인 조건문 분기를 없애는데 그 목적이 있습니다."* — ghojeong (디자인 패턴 도입 = 해결 효과 필요)
+
+> *"참고로 제가 State 에 집착하는 것은, 안드로이드 개발자로써 서버와 API 통신하는 것과 매우 밀접한 관련이 있는 부분이라 그렇습니다."* — ghojeong (reviewer 자가 강조 이유 메타)
+
+> *"저는 다형성(Polymorphism) 이라는 키워드를 말씀드렸지만, 제 피드백에 휘둘리지 마시고, '객체 지향 생활 체조 원칙' 에 집중하시면 좋을 것 같습니다."* — ghojeong (학생 자가 결정 존중)
+
+> *"바로 밑의 피드백을 본 후에 다형성(Polymorphism)을 고민해보니,, State를 enum보다는 sealed class로 구현하는게 더 좋아보입니다! 이제서야 왜 State를 enum이 아닌 sealed class로 구현하는지 알겠네요!"* — jaeyeongjo (학생 자가 깨달음 + 결정 변경)
+
+## 얻은 교훈
+
+1. **`is 연산자 = 절차지향 시그널 = 다형성 회피`** — **MCP 룰 후보 `is-operator-polymorphism-avoidance`**. PR 다수 결.
+
+2. **`디자인 패턴 도입 = 의도 효과 검증`** — *State 패턴 도입 후 조건문 잔존 = 패턴 효과 X*. **MCP 룰 후보 `design-pattern-without-effect`**. PR #98 (chaehyuns) 결.
+
+3. **`State 패턴 핵심 = 조건문 제거 + Context 가 State 보유`** — *Map<Participant, State> 불필요 = State 패턴 정공 X*. PR #91·#98·#39·#43 결.
+
+4. **`안드로이드 서버 통신 State 비유`** — *NORMAL → LOADING → SUCCESS / FAIL = 실무 학습 가치*. **MCP 룰 후보 `reviewer-emphasis-rationale-meta`**.
+
+5. **`reviewer "휘둘리지 마시고" 메타 어휘`** — **MCP 룰 후보 `reviewer-don't-be-swayed`**. PR #145·#72·#22·#23·#26·#46·#43·#95·#91·#107 결.
+
+6. **`학생 자가 깨달음 명시`** — *"이제서야 왜 ... 알겠네요"* = 학습 완료 시그널. PR #82·#100·#80·#107·#145·#46 결.
+
+7. **`else 예약어 + 연속 if = 객체지향 생활 체조 위반`** — **MCP 룰 후보 `consecutive-if-as-else-violation`**. PR #16·#23·#9 결.
+
+8. **`enum vs sealed class` 양가성 + 학생 자가 결정 변경** — PR #91·#43·#137·#90·#146 결.
+
+9. **`Set 자료구조 한계 (removeLast X)`** — PR #23·#26·#11 결.
+
+10. **`Hand 책임 위치` 토론 시리즈** — PR #145·#99·#77·#46·#43·#72 결.
+
+11. **`assertj isInstanceOf` Kotlin 어휘** — `is` 대신 *isInstanceOf*.
+
+12. **`private const + companion object 응집`** — PR #43·#82·#9 결.