oh-my-oop 0.2.0

package/lessons/woowacourse-kotlin-lotto/RightHennessy/32-2/353/213/250/352/263/204-/353/241/234/353/230/220.md

@@ -0,0 +1,178 @@
+# PR #32 — [링링] 2단계 로또
+
+- **Reviewee:** [@RightHennessy](https://github.com/RightHennessy)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/32
+- **단계:** 2단계 (수동 로또 추가)
+- **리뷰어:** @BeokBeok
+- **라인 코멘트:** 31
+
+## 잘한 점 (설계 관점)
+
+- **`Money` 도메인 객체 분리** — 검증 + 단위 보유.
+- **`UserLotto.checkInputManualLottoCount`** — 수동 개수 검증을 도메인으로 이동.
+- **`Rank.isSame(countOfMatch, matchBonus)` enum 다형성** — `SECOND`/`MISS`만 override.
+- **InputView 단순화 (`readIntOrNull`, `readStringList`)** — 입력 함수 중복 압축.
+- **자가 분석 → 리뷰어 칭찬** — 학생이 InputView의 책임 모호함을 *먼저* 의식.
+
+## 못한 점 (설계 관점)
+
+### 1. `InputView`가 `Lotto` 변환 — 학생 자가 의문
+
+```kotlin
+fun readManualLottoNumbers(count: Int): List<Lotto> {
+    val lotto = mutableListOf<Lotto>()
+    for (i in 0 until count) {
+        val input = readln()
+        lotto.add(Lotto(input.split(",").map { LottoNumber(it.toInt()) }))
+    }
+    return lotto
+}
+```
+
+학생: "입력 받은 수동 로또를 InputView에서 Lotto로 변환하여 넘기는데, view에서 Lotto를 완성하는 것이 맞을까요, 그냥 Int 리스트만 입력 받아 도메인 로직에서 감싸 주는 게 맞는 방법일까요? 개인적으로는 inputView에서 너무 많은 일을 하고 있다고 생각하긴 합니다." 리뷰어: "잘 분석하셨네요. InputView는 '입력'에 관련된 책임을 가질 뿐, '변환'에 대한 책임을 가지지 않습니다. 그렇다면, 변환은 어디서 해야 할까요? (View와 Domain 둘 다 접근이 가능한 곳)"
+
+### 2. `Validator` 객체에 검증 집중 — 도메인 검증 우회
+
+```kotlin
+object Validator {
+    fun checkInputMoney(input: String) {. }
+    fun checkInputManualLottoCount(input: String, lottoCount: Int) {. }
+}
+```
+
+리뷰어: "InputView에서는 입력된 값만 전달해 주고, 실질적인 값에 대한 유효성 체크는 관련 domain에서 하는 것이 좋습니다. 만약 요구사항이 변경되어 domain이 변경된다고 가정해 봅시다. InputView에서 '변환'과 '검증'까지 다 하게 되는 구조라면, 요구사항 변경 시 view와 domain 둘 다 변경을 해야 합니다." 학생: "조언을 바탕으로 모든 유효성 체크는 도메인에서 하도록 변경하였습니다! 생각해 보니, view에서 그런 자세한 변환까지는 알 필요도 없다는 생각이 추가적으로 들었습니다." → `Money` 객체로 분리.
+
+### 3. `initializeLotto()` — 함수명/구현 불일치
+
+```kotlin
+private fun initializeLotto(): List<Lotto> {  // ⚠ initialize인데 List 반환
+    val lottoCount = readInputMoney() / Lotto.MONEY_UNIT
+    val manualLotto = initializeManualLotto(lottoCount)
+    val autoMaticLotto = initializeAutoMaticLotto(lottoCount - manualLotto.size)
+.
+    return manualLotto + autoMaticLotto
+}
+```
+
+리뷰어: "함수명만 봤을 때에는 '로또를 초기화한다'라는 의미로 이해가 되는데요. 실제로는 로또의 리스트를 리턴하고 있네요. 함수명과 실제 구현부의 동작이 일치하도록 코드를 개선해 보면 어떨까요?" 학생: "make~라는 함수로 변경해 주었는데 혹시 더 나은 함수명이 있을까요?" 리뷰어: "make도 좋습니다. make의 의미는 '만들다'이기 때문에, '아 로또를 만들어 주겠구나'라고 생각이 들게 되니까요."
+
+### 4. `!!` 강제 언패킹 — Null-safety 우회
+
+```kotlin
+private fun readLottoCount(): Int {
+    return (readInputMoney().value?.div(Money.MONEY_UNIT))!!  // ⚠ !!
+}
+```
+
+리뷰어: "`(readInputMoney().value?.div(Money.MONEY_UNIT))`이 null이 아님을 보장할 수 있을까요?" + "manualLottoCount가 null이 아니라는 것을 보장할 수 있을까요?" 학생: "제 머릿속에서는 보장할 수 있었기에 이렇게 작성했지만 코드를 보는 입장에서는 그렇지 않기 때문에 변경했습니다." — *나만 아는 invariant*는 *코드에 명시*되어야.
+
+### 5. `let` 남용 — *null 회피*가 아님
+
+```kotlin
+Rank.valueOf(
+    lotto.countMatchingNumbers(winningNumbers.winningLotto),
+    lotto.checkMatchingBonusNumber(winningNumbers.bonusNumber)
+)?.let {
+    ranks.add(it)
+}
+```
+
+리뷰어: "let을 잘 활용해 주셨네요. let은 mutable하면서 nullable한 경우에만 사용하는 것을 권장하며, 단순히 null을 회피하기 위해 사용하는 것은 권장하지 않습니다." — `let`은 *변환*/*scope*용, *null 가드*는 `?.also`/`if (x != null)`.
+
+### 6. `Rank.MISS`의 매직넘버 `3`, `6`
+
+```kotlin
+MISS(0, 0) {
+    override fun isSame(countOfMatch: Int, matchBonus: Boolean): Boolean {
+        return (countOfMatch < 3) or (countOfMatch > 6)  // ⚠ 매직넘버
+    }
+}
+```
+
+리뷰어: "숫자 3과 숫자 6은 각각 어떤 의미를 가질까요?" — `3`은 *최소 당첨*, `6`은 *로또 번호 개수*. 둘 다 *Lotto* 또는 *Rank* 상수로.
+
+### 7. `UserLotto` 부생성자 두 개
+
+```kotlin
+class UserLotto {
+    val count: Int
+    private val lottoNumbers: List<Lotto>
+    constructor(count: Int) {. lottoNumbers = listOf() }
+    constructor(count: Int, lottoNumbers: List<Lotto>) {. }
+}
+```
+
+리뷰어: "코틀린에서는 default value를 지원합니다. `class UserLotto(val count: Int, private val lottoNumbers: List<Lotto> = emptyList())` default value를 활용하면, 부생성자를 없앨 수 있어요." — Kotlin idiom으로 *언어 기능* 활용.
+
+### 8. `InputView` 단순 위임 함수가 *시스템 함수보다 길어짐*
+
+```kotlin
+private fun readInputNumber(): String { return readln() }
+```
+
+리뷰어: "대체로 커스텀 함수보다는 시스템 함수가 더 가독성이 좋습니다. 단순히 함수 내부에서 시스템 함수만 호출한다면, 시스템 함수를 호출하는 것을 권장합니다." — *추상화 비용*이 *추상의 가치*보다 크면 *직접 호출*.
+
+### 9. `readStringList` 명명에 자료형
+
+```kotlin
+private fun readStringList(): List<String> {. }
+```
+
+리뷰어: "함수명에는 가급적이면 자료형을 작성하지 않는 것을 권장합니다." + "`readManualLottoNumbers`, `readInputWinningLotto` 함수의 의미를 포함할 수 있도록 `readStringList` 함수명을 개선." — *반환 타입*은 시그니처가 말함, 함수명은 *의도*.
+
+### 10. `LottoGenerator` 테스트가 *반드시 통과*
+
+```kotlin
+@Test
+fun `랜덤한 숫자로 로또를 발행한다`() {
+    assertThat(
+        TestNumberGenerator(listOf(1, 2, 3, 4, 5, 6).map { LottoNumber(it) }).generate()
+    ).isEqualTo(listOf(1, 2, 3, 4, 5, 6).map { LottoNumber(it) })
+}
+```
+
+리뷰어: "랜덤한 숫자로 로또를 발행하는 테스트는 반드시 통과하는 테스트입니다. 이 테스트 코드가 어떤 것을 검증하는지 한번 고민해 보시면 좋을 것 같아요." — *Test의 가치*는 *깨질 수 있는 케이스를 잡는 것*. `TestNumberGenerator`가 자신을 검증하면 *순환 검증*.
+
+### 11. 학생 자가 의문 — `require` vs null
+
+학생: "input에 대해 오류가 예상되는 input이라고 생각했었는데요, 그럼 이 경우에는 require 문으로 검증하는 게 맞는 방법일까요? 결국에는 require 문이 exception을 던진다고 생각해서 이런 경우에도 null로 처리를 하는 게 맞을까요?" 리뷰어 답 패턴: "부생성자를 활용하거나 팩토리 메서드를 활용해 보면 어떨까요?" — *생성자 검증*에서 예외, *팩토리*에서 null/Result.
+
+## 리뷰어 의견 요지
+
+1. **InputView 책임 = 입력만**, 변환은 *View와 Domain 모두 접근 가능한 곳*(Controller, Mapper).
+2. **검증은 *도메인*에서** — Validator에 집중하면 *요구사항 변경 시 View+Domain 동시 변경*.
+3. **함수명 = 구현부 일치** — `initializeLotto`인데 `List<Lotto>` 반환은 의미 어긋남.
+4. ***내 머릿속의 invariant*는 *코드에 명시*되어야** — `!!`는 *암묵 가정*의 표현.
+5. **`let`은 *scope/변환*, *null 회피*가 아님** — 적절한 용법 학습.
+6. **매직넘버 = *도메인 상수*** — `3`은 *최소 당첨*, `6`은 *로또 크기*.
+7. **부생성자 = 언어 기능 부족 신호** — Kotlin default value로 단순화.
+8. **단순 위임 함수는 *시스템 함수 직접 호출*이 더 가독성** — 추상화 비용 > 가치면 *없애기*.
+9. **함수명에 *자료형* 노출 X** — *반환 타입*은 시그니처 책임.
+10. **반드시 통과하는 테스트 = 가치 0** — *깨질 수 있는 케이스*를 잡는 것이 테스트 가치.
+
+- **대표 인용:**
+  > InputView는 "입력"에 관련된 책임을 가질 뿐, "변환"에 대한 책임을 가지지 않습니다. 그렇다면, 변환은 어디서 해야 할까요? (View와 Domain 둘 다 접근이 가능한 곳)
+  > — @BeokBeok on `src/main/kotlin/lotto/view/InputView.kt`
+
+  > 만약 요구사항이 변경되어 domain이 변경된다고 가정해 봅시다. InputView에서 '변환'과 '검증'까지 다 하게 되는 구조라면, 요구사항 변경 시 view와 domain 둘 다 변경을 해야 합니다.
+  > — @BeokBeok on `src/main/kotlin/lotto/exception/Validator.kt`
+
+  > 함수명만 봤을 때에는 "로또를 초기화한다"라는 의미로 이해가 되는데요. 실제로는 로또의 리스트를 리턴하고 있네요.
+  > — @BeokBeok on `src/main/kotlin/lotto/controller/Controller.kt`
+
+  > 랜덤한 숫자로 로또를 발행하는 테스트는 반드시 통과하는 테스트입니다. 이 테스트 코드가 어떤 것을 검증하는지 한번 고민해 보시면 좋을 것 같아요.
+  > — @BeokBeok on `src/test/kotlin/lotto/domain/LottoGeneratorTest.kt`
+
+## 얻은 교훈
+
+- **InputView 책임 = 입력만**. 변환은 *Controller* 또는 *Mapper*. View가 도메인 객체를 만들면 *View 변경 = 도메인 변경*.
+- **검증은 *도메인에서 자기 invariant***. Validator로 집중하면 *Validator + Domain + View* 세 곳이 변경에 흔들림.
+- **함수명 = 구현부**. `initialize*` vs `make*` vs `get*`은 *부수효과 + 반환*의 신호가 달라야.
+- **`!!`는 *암묵 가정*의 표현**. 내가 아는 *invariant*를 *코드/타입*으로 명시해야 미래 동료가 안전.
+- **`let`은 scope/변환용, null 회피가 아님**. `?.also`/`if`로 의도 명시.
+- **매직넘버 = 도메인 상수로**. *3*/*6* 같은 숫자는 *Lotto의 정체성* 또는 *Rank의 분류 기준*.
+- **부생성자는 Kotlin에서 *드물게 필요*** — default value로 *대부분 대체 가능*.
+- **단순 위임 함수의 *추상 비용***  — `readInputNumber` → `readln()`에 *추가 정보 없음*이면 호출 위치에서 직접 사용.
+- **함수명에 *자료형* 노출 X** — *반환 타입*은 시그니처. `readStringList` → `readManualNumbersInput`.
+- **테스트는 *깨질 수 있는 케이스*를 잡는다** — *반드시 통과*하는 테스트는 *변경 감지력 0*.
+- **`require` vs null** — *생성자 검증*은 예외(invariant), *팩토리*는 null/Result. *주생성자*는 의도된 사용처에서만.

package/lessons/woowacourse-kotlin-lotto/RightHennessy/5-1/353/213/250/352/263/204-/353/241/234/353/230/220.md

@@ -0,0 +1,149 @@
+# PR #5 — [링링] 1단계 로또 (초창기)
+
+- **Reviewee:** [@RightHennessy](https://github.com/RightHennessy)
+- **PR:** https://github.com/woowacourse/kotlin-lotto/pull/5
+- **단계:** 1단계
+- **리뷰어:** @BeokBeok
+- **라인 코멘트:** 26 (리뷰어 14 + 학생 12)
+
+## 잘한 점 (설계 관점)
+
+- **`LottoNumber` 값 객체 시도**.
+- **방어적 복사** — 칭찬: "*방어적 복사를 활용을 잘 해 주셨네요* 👍".
+
+## 못한 점 (설계 관점)
+
+### 1. `!!` *non-null assertion* — 검증 누락 위험
+
+```kotlin
+Rank.values().find { it.countOfMatch == matchCount }!!  // ⚠ matchCount=7이면 NPE
+```
+
+리뷰어: "만약 *countOfMatch가 7 이상의 값이면 어떻게 될까요? non-null assertion(!!)은 null이 아닐 것이라 확신할 때 사용하는 것이 좋*습니다."
+
+리뷰어:
+```kotlin
+values().lastOrNull { rank -> rank.countOfMatch == countOfMatch }
+```
+"try-catch를 사용하는 것도 좋지만, *OrNull 계열의 함수를 사용하는 방법도* 있습니다. *엘비스 연산자(?:)를 활용하면 간단하게 null 대신 기본값을 리턴*할 수 있습니다."
+
+### 2. *try-catch + 재귀* — 예외 흐름
+
+```kotlin
+fun readPurchaseAmount(): Int {
+    return try {
+        val input = readLine()!!.toInt()
+        require(input >= 1000)
+        input
+    } catch (e: Exception) {
+        readPurchaseAmount()  // ⚠ 재귀
+    }
+}
+```
+
+리뷰어: "try-catch 문을 활용하여, 만약 Exception이 발생했을 경우, 함수를 재귀호출하여 유효한 값을 계속해서 입력받도록 구현해 주셨네요. *코틀린에서 예외를 처리하는 방법은 크게 두 종류가 있습니다*.
+- *오류가 예상되는 경우*
+- *오류가 예상되지 않는 경우*
+
+*오류가 예상되는 경우에는 주로 null 또는 기본값을 리턴*합니다. 반면, *오류가 예상되지 않는 경우에는 Exception을 던지고 이 Exception을 개발자에게 알려서 문제를 빠르게 파악*하도록 합니다. *Exception은 반드시 예외적인 상황에서만 사용하는 것이 좋*습니다. ref. *https://elizarov.medium.com/kotlin-and-exceptions-8062f589d07*의 input/output 쪽 보시면 도움이 될 거에요." — Elizarov 인용.
+
+### 3. *요구사항에 없는 안전 기능*
+
+리뷰어: "*프로그래밍 요구사항에서는 '유효한 값을 입력받을 때까지 프로그램을 종료하지 않는다'와 같은 항목은 없*습니다. 물론 *프로그램을 안전하게 작성하는 것은 좋지만, 요구사항을 분석하고 충실히 반영하는 것을 권장*합니다." — PR #49 잭슨과 같은 가르침: *명세서 우선*.
+
+### 4. *출력 문구 매직값*
+
+리뷰어: "만약 *일치하는 볼의 개수와 금액이 바뀌게 되면, 이 부분도 변경을 해야 합니다. 요구사항이 변경되더라도 출력되는 문구들은 변경하지 않아도 되도록 코드를 개선*해 보면 어떨까요?" — *상수 변경 → 자동 반영*.
+
+### 5. *테스트 함수명-내용 불일치*
+
+리뷰어: "*함수명에는 구입 금액이라고 명시되어 있지만, 내부 로직은 개수를 입력하도록 되어 있*네요. *테스트하고자 하는 것과 함수명을 일치*시켜 보면 어떨까요?" + "*함수명만 봤을 때에는 마치 숫자 1부터 45까지를 테스트하는 것으로 보이나, 실질적으로는 범위 외의 숫자를 입력한 결괏값을 테스트*하고 있네요.".
+
+### 6. *Rank 모든 케이스 테스트*
+
+리뷰어: "*숫자가 몇 개 일치하면 몇 등인지에 대한 모든 케이스를 테스트 코드로 작성*해 보면 어떨까요?".
+
+### 7. *Rank 매칭 위임* — Tell, Don't Ask
+
+리뷰어: "*Rank 클래스를 활용해서 매칭 여부에 해당하는 Rank를 반환하도록 개선*해 보면 어떨까요?"
+
+### 8. *도메인이 Controller 의존* — 의존 방향 역행
+
+리뷰어: "*domain에서 Controller에 접근하고 있*네요. *domain은 어떤 것과도 의존성을 가지지 않도록 코드를 개선*해 보면 어떨까요?" — *Hexagonal Architecture* 원칙: *Domain은 leaf*.
+
+### 9. *MONEY_UNIT 상수 위치*
+
+리뷰어: "*MONEY_UNIT은 로또 금액 단위를 말합니다. 즉, Lotto와 관련이 있*습니다. *관련있는 곳에서 상수값을 관리하도록 코드를 개선*해 보면 어떨까요?".
+
+### 10. *generate 테스트* — 결정적 결과 검증
+
+리뷰어: "*generate 함수는 로또를 생성하는 함수*입니다. 그렇다면 *내가 원하는 로또 번호로 여러 개의 로또가 생성되는지 확인할 수 있는 테스트 코드를 작성할 수 있도록 개선*해 보면 어떨까요?" — *Random 외부 주입*으로 *결정적 테스트* 가능.
+
+### 11. `.toList()` *불필요 호출*
+
+```kotlin
+(MIN..MAX).toList().shuffled()  // ⚠ toList 불필요
+```
+
+리뷰어:
+```kotlin
+return (LottoNumber.MINIMUM_LOTTO_NUMBER..LottoNumber.MAXIMUM_LOTTO_NUMBER).shuffled()
+```
+"*대부분의 컬렉션 관련 함수들은 원본을 수정하지 않고 복사본을 만들어서 변경하곤* 합니다. 그래서 *toList()를 호출하지 않아도 됩니다*. *shuffled() 함수의 내부 구현체*는 아래와 같습니다. (toMutableList())
+```kotlin
+public actual fun <T> Iterable<T>.shuffled(): List<T> = toMutableList().apply { shuffle() }
+```"
+
+### 12. *학생 자가 의문 1* — Bonus 검증 시 winningNumbers 호출
+
+학생: "*bonusNumber 입력 오류 시 보너스 볼만 다시 받기 위해 검증을 하는데 사용하지도 않는 WinningNumbers를 불러오는 게 맞는 행위인지 잘 모르겠*습니다."
+
+### 13. *학생 자가 의문 2* — Int 풀어 검증
+
+학생: "*로또 번호들을 각각 LottoNumber로 묶어 주었는데, 이를 검증 시 마다 map을 이용하여 Int로 풀어주는 것이 맞는 것인지 잘 모르겠*습니다." → *LottoNumber 자체에 검증*을 두면 *풀 필요 없음*.
+
+### 14. *프로그램 종료 vs 재시도 선택*
+
+리뷰어: "맞습니다! *null로 간주하고 프로그램을 종료하셔도* 됩니다. 만약 *유효한 값을 입력할 때까지 계속해서 반복하고 싶으시다면, 입력된 값이 null인 경우 함수를 다시 호출하도록 구현*할 수 있습니다." — *명세에 따른 선택*.
+
+## 리뷰어 의견 요지
+
+- **`!!` *확신 시만*** — OrNull + 엘비스로 안전.
+- **예외 = *예상되지 않는 경우*** — Elizarov 인용. 정상 흐름은 null/기본값.
+- **요구사항 *충실 반영*** — 안전 기능도 *명세서 우선*.
+- **출력 문구 *상수 자동 반영***.
+- **테스트 함수명-내용 *일치***.
+- **`Rank.from(matchCount)` *Tell, Don't Ask*** + 모든 케이스 테스트.
+- **도메인 *어떤 것에도 의존성 X*** — Hexagonal.
+- **상수 *책임 객체*에**.
+- **`generate` *Random 외부 주입*** = 결정적 테스트.
+- **`.toList()` *불필요 호출*** — *컬렉션 함수가 이미 복사본*.
+
+- **대표 인용:**
+  > non-null assertion(!!)은 *null이 아닐 것이라 확신할 때 사용*하는 것이 좋습니다.
+  > — @BeokBeok on `src/main/kotlin/lotto/domain/Rank.kt`
+
+  > 코틀린에서 예외를 처리하는 방법은 크게 두 종류가 있습니다.
+  > - 오류가 예상되는 경우
+  > - 오류가 예상되지 않는 경우
+  > — @BeokBeok on `src/main/kotlin/lotto/view/InputView.kt`
+
+  > 프로그래밍 요구사항에서는 *'유효한 값을 입력받을 때까지 프로그램을 종료하지 않는다'와 같은 항목은 없*습니다. *요구사항을 분석하고 충실히 반영하는 것을 권장*합니다.
+  > — @BeokBeok on `src/main/kotlin/lotto/view/InputView.kt`
+
+  > domain에서 Controller에 접근하고 있네요. *doomain은 어떤 것과도 의존성을 가지지 않도록 코드를 개선*해 보면 어떨까요?
+  > — @BeokBeok on `src/main/kotlin/lotto/domain/LottoTicket.kt`
+
+## 얻은 교훈
+
+- **`!!` = *false safety*** — *검증 누락 시 NPE*. *OrNull + 엘비스(`?:`)*가 안전.
+- **예외 = *예상되지 않는 경우*만** — Elizarov 글 (*PR #36, #90 공통 인용*). *정상 흐름*은 *null/기본값*.
+- **요구사항 *충실*** — *안전 기능도 명세서 우선*. *과한 안전*은 *YAGNI 위반*.
+- **출력 문구 *Rank 속성 자동 반영*** — `Rank.firstPrize`처럼.
+- **테스트 함수명 = 실제 검증** — 부분만 검증하면 *명세 부재*.
+- **`Rank.from(matchCount, matchBonus): Rank` *Tell, Don't Ask***. *모든 분기 테스트*.
+- **도메인 *leaf 의존*** — *Hexagonal Architecture*: Domain은 *외부에 의존 X*. *Controller → Domain*만.
+- **상수 *책임 객체*에** — `MONEY_UNIT`은 `Lotto`나 `Money`. *Util*에 모이면 *god-folder*.
+- **`generate` *Random 외부 주입*** — *NumberGenerator interface + Fake*.
+- **`.toList()` 불필요** — *Kotlin 컬렉션 함수*는 *기본적으로 복사본 반환*.
+- **`LottoNumber` *값 객체로 묶으면 풀 필요 없음*** — *map { it.value }`로 풀면 wrapping 의미 약화.