[2단계 - 웹 기반 로또 게임] 코브 미션 제출합니다.

[TH-97]

학습 목표

이번 미션을 통해 다음과 같은 학습 경험들을 쌓는 것을 목표로 합니다.

• UI와 도메인 영역을 분리할 수 있는 설계를 고민해보고, 목적에 맞게 객체와 함수를 활용
• TDD 방식으로 개발하며, 단위 테스트 기반으로 점진적인 리팩터링

제출 전 체크 리스트

• 기능 요구 사항을 모두 구현했고, 정상적으로 동작하는지 확인했나요?
• 기본적인 프로그래밍 요구 사항을 준수하고 있는지 확인했나요?
• 테스트 코드는 모두 정상적으로 실행되나요?
• (해당하는 경우) 배포한 데모 페이지에 정상적으로 접근할 수 있나요?
  • 배포한 링크 기입:

리뷰 요청 & 논의하고 싶은 내용

1) 이번 단계에서 가장 많이 고민했던 문제와 해결 과정에서 배운 점

처음에는 컨트롤러를 두 개로 나눠서 구현할까 고민했습니다. 하지만 그렇게 하면 구현 자체는 쉬워지겠지만, 도메인과 UI를 제대로 분리했다면 하나의 컨트롤러로도 충분히 가능해야 한다는 생각이 들었습니다. 그래서 컨트롤러 하나로 가보자는 결정을 내리고 진행했습니다.
막상 작업을 시작하니 기존에 작성했던 코드들이 생각보다 발목을 많이 잡았습니다. 도메인 로직에서 데이터를 복사본으로 내보내는 구조라 값을 가져오는 건 괜찮았는데, 콘솔 환경에 맞춰진 로직들이 섞여 있어 코드가 금방 복잡해지더라고요. 구현을 하면 할수록 처음 설계 단계에서 웹 환경까지 충분히 고려했다면 훨씬 매끄러웠을 거라는 아쉬움이 남았습니다. 이번 기회를 통해 초기 설계의 중요성을 정말 깊이 체감했습니다. 기본적인 요구사항을 지키지 못한것에 후회가 됩니다.

UI 쪽에서는 HTML 태그의 용도를 고민하며 구조를 잡는 데 시간을 많이 썼습니다. 특히 레이아웃을 잡을 때 flex: 1 속성을 이번에 처음 사용해 보았습니다. 이전에는 요소의 크기를 일일이 계산해서 맞추느라 고생했는데, flex: 1을 활용해 보니 남은 공간을 알아서 유연하게 채워주어 레이아웃 구성이 훨씬 수월해졌습니다. 한 번 직접 써보면서 익힌 덕분에 앞으로 화면을 구성할 때 큰 도움이 될 것 같습니다

2) 이번 리뷰를 통해 논의하고 싶은 부분

평소 저는 div에 id나 class를 부여하고 네이밍으로 구조를 관리하는 방식을 주로 사용해 왔습니다. 하지만 이번에 UI를 직접 구현하며 HTML 태그 자체의 역할에 대해 많은 의문이 생겼습니다. 특히
, (혹은 일반 텍스트), 등 기본적인 텍스트 요소를 구성할 때 어떤 것을 선택해야 할지 기준을 잡기가 어려웠습니다. 리뷰어님은 태그를 선택하실 때 어떤 기준을 가지고 계시는지 궁금합니다.

설계에 대한 판단 기준도 여쭤보고 싶습니다. 만약 초기에 작성한 코드가 나중에 확장하기 매우 불편한 구조라는 것을 알게 된다면, 리뷰어님은 컨트롤러를 분리하여 상황에 맞게 각각 구현하는 쪽을 택하시나요, 아니면 기존 코드를 갈아엎고 구조를 다시 잡는 쪽을 택하시나요? 저는 이번에 설계의 불편함을 직접 경험해 보고자 일부러 컨트롤러 하나만을 유지하며 구현해 보았습니다.
마지막으로, 초반에는 아래와 같이 JavaScript만을 이용해 HTML 구조를 생성하는 방식을 고민했었습니다.

export const Component = {
  Header() {
    return "<header>🎱 행운의 로또</header>";
  },
  Main() {
    return `<main>
      <div id="main">
        <header>🎱 내 번호 당첨 확인</header>
        <div>
          <p>구입할 금액을 입력해주세요</p>
          <div>
            <input></input>
            <button class="button-purchase">구입</button>
          </div>
          <div id="lotto"></div>
        </div>
      </div>
    </main>`;
  },
}

이 방식은 HTML 파일에서 직접 작업하는 것과 달리 태그의 오류나 버그를 직관적으로 확인하기 어려워 결국 폐기했습니다. 하지만 이런 식으로 JS 중심의 컴포넌트 구조를 짜는 것에 대해 리뷰어님은 어떻게 생각하시는지 의견을 듣고 싶습니다.

---

✅ 리뷰어 체크 포인트

1단계

• TDD를 활용해 기능을 구현하는 과정에서 적절한 테스트 우선 접근 방식을 적용했는가? 단위 테스트의 커버리지는 충분한가?
• 도메인과 UI의 관심사를 분리하여 적절한 모듈화가 이루어졌는가? 하나의 객체나 모듈이 너무 많은 책임을 가지고 있지는 않은가?
• 객체의 프로퍼티를 직접 조작하기보다 메시지를 던지고 있는가?
• 불필요한 클래스를 사용하지 않고, 함수를 적극적으로 활용하여 JavaScript다운 방식으로 로직을 구현했는가?

2단계

• 도메인 로직에 불필요한 영향을 주지 않고 UI 변경에 대응했는가?
• DOM 조작과 이벤트 활용을 JavaScript의 개념에 맞게 이해하고 적절하게 적용했는가?
• 웹 표준을 준수하는 마크업을 활용하며, 스타일 작성에 일관성이 있는가?

[eastroots92]

안녕하세요! 코드 재미있게 잘 읽었어요.

이번 미션에서 의도했던 경험을 제대로 고민하고 경험하셨다고 생각되네요!
고민했던 문제와 배운 점에 적으신 것 처럼 도메인(또는 비즈니스 로직)과 입출력을 잘 나누었다면 이전 1단계에 이야기 한 것 처럼 도메인(비즈니스 로직)은 최소한의 변경 또는 건들지 않고 만들 수 있었을 거에요! (input, output 부분만 Params로 넘기고 input, output만 수정하는 방식)

이런 부분에서 어떻게 설계하면 서로의 의존성을 줄일 수 있을지 고민하는 계기였다고 생각해요.
이 부분은 직접 부딪혀 보지 않으면 이해하기 어려운 부분이고, 이번 경험을 통해 앞으로 고민해보시면 좋겠어요. (다만 지금 하고 있는 고민들이 쌓여야 기초가 단단한 엔지니어가 되는 것이기에 그렇게 하지 못했다고 낙담하지 않으셨으면 좋겠어요.)

이번 리뷰를 통해 논의하고 싶은 부분

• 리뷰어님은 태그를 선택하실 때 어떤 기준을 가지고 계시는지 궁금합니다.
  저는 큰 관점에서 시멘틱 웹을 잘 지키려고 하고 있어요.
  className 등으로 우리는 역할을 구분 할 수도 있지만, SEO 측면에서 로직을 파악할 때 className의 의도까지 파악하진 않으니까요.
  추가로 시멘틱 웹은 SEO 측면 뿐 아니라 접근성 측면에서도 중요한 부분이기 때문에 시멘틱 웹을 살펴보시고 최대한 개발 할 때 지켜보시면 좋겠어요.

다만, 최대한 지키려 한다 이지 잘 지켜지지 않는 상황들도 있어요. 예를 들어 React로 개발하다보면 form 태그 대신 div에 state로 form 역할을 대체하게 된다던지, 디자인 시스템의 layout 구조를 적극 활용하다보면 시멘틱 웹 구조가 의도대로 안잡히기도 해요.

그럼에도 시멘틱 웹을 지킨다면 코드 가독성 측면 뿐 아니라 사용자 측면에서도 도움이 되니 최대한 이 부분을 고려해보시면 좋겠슴다!

• JS 중심의 컴포넌트 구조를 짜는 것에 대해 리뷰어님은 어떻게 생각하시는지
  아주 좋은 고민이라고 생각해요. 나중에 React는 어떻게 만들어졌을까? 왜 이렇게 동작할까? 를 고민하면서 간단한 React를 직접 만들어보거나, 바닐라 스크립트로 SPA 페이지를 만들어보면 어느정도 답변이 될 것이라고 생각해요.

다만 주의하셔야 할 점은 상황에 맞게 적절한 도구를 선택하는 것도 매우 중요해요. 간단한 출력 페이지에 되려 React를 사용하거나 SPA는 오버 엔지니어링 일 수 있어요.

고생하셨습니다!

[eastroots92]

단순 질문.

대문자에서 소문자로 변경한 이유가 있을까요?

[TH-97]

Prettier로 인해 자동으로 수정된 것 같습니다

[eastroots92]

P4;

현재 줄바꿈 등 indent가 일관되지 않은 것 같은데 혹시 lint 등을 추가하신 것이 있을까요!?

[TH-97]

확인해보니 Prettier의 기본 HTML 포맷팅 규칙으로 인해 긴 줄이 자동으로 줄바꿈된 것 입니다. 별도로 lint를 추가한 것은 아닙니다.

[eastroots92]

제품관점 피드백
지금 MVP로는 충분하지만, 만약 제품적으로 개선 한다면 어떻게 하면 휴먼에러를 방지할 수 있을까? 고민도 해볼 수 있을 것 같아요.
ex)

• 1000원 10000원 단위 버튼을 추가한다. (like. 은행 앱)
• Input 자체를 제거하고 게임처럼 + 1000원, - 1000원 버튼만 만든다.

이건 당장 개선하자는 의미는 아니고 이런 고민도 해볼 수 있구나 정도로 생각해주세요!

[TH-97]

입력 방식과 선택 방식을 모두 도입하는 것이 좋을 것 같아요. 선택 방식은 잘못된 금액 입력을 막아주지만, 많은 양의 로또를 사고 싶은 사용자가 계속 스크롤을 내려야 한다면 불편함을 느낄 수 있거든요. 정확성과 편의성을 모두 잡기 위해 두 방식을 혼합하는 것이 합리적이라고 생각합니다.

[eastroots92]

P4. DOMOutput.printLottos에서 innerHTML을 사용하고 있어요

innerHTML은 XSS 취약점이 있을 수 있어요. 이번 과제에서는 사용자 입력이 아닌 숫자만 들어가니 실질적 위험은 낮지만, 좋은 습관으로 document.createElement와 textContent를 사용하는 방법을 익혀두면 좋아요.

[eastroots92]

P2; input type을 활용해보세요.

숫자만 입력받는 필드인데 type 속성이 없어서 기본값인 type="text"로 동작해요.
type="number"를 사용하면 모바일에서 숫자 키패드가 뜨고, 브라우저 기본 유효성 검사도 활용할 수 있어요.

[TH-97]

구현 단계에서 타입 체킹보다는 로직이 의도한 대로 돌아가는지 먼저 확인하고 싶었어요. 그래서 우선은 타입을 제외 하였습니다.
수정하겠습니다

[eastroots92]

질문. CSS Normalize와 CSS Reset의 차이에 대해 알고 계신가요!?

각각 어떨때 normalize, reset을 사용하면 좋을까요?

[TH-97]

CSS Reset은 모든 스타일을 0으로 초기화하여 브라우저 간의 차이를 없애는 방식이고, CSS Normalize는 특정 부분만 일관되게 통일하는 방식으로 알고 있습니다.

저는 여러 브라우저의 고유한 특징을 전부 파악하고 있지 않아서, 보다 편하게 작업하기 위해 Reset을 주로 사용합니다.

* {
  box-sizing: border-box;
  margin: 0;
  padding: 0;
  //font-size: 15px;
  //font-family: "Roboto", sans-serif;
}

다시 보니작성한 코드에서 주석 처리된 부분은 스타일을 완전히 지우기보다 특정 값을 지정한다는 점에서 Normalize의 성격에 가깝다고 생각됩니다. 루트의 생각은 어떤지 궁금합니다

[eastroots92]

reset, normalize 성격이 혼재되어있다고 생각해요!

reset의 경우 브라우저 스타일을 모두 제거하는 것 이고 normalize의 경우 브라우저간 차이를 줄이고 큰 맥락의 UX(접근성 등)은 유지하는 것이에요.

이 질문을 했던 이유는 이 둘의 개념을 알고 사용하신 것인지 궁금해서 질문을 했었고, 무언가 잘하거나 못해서 남긴 코멘트는 아니였어요!

[eastroots92]

P5;
0의 경우 축약이 가능해요!

Suggested change

	padding: 0.875rem 0rem 0.875rem 8.125rem;
	padding: 0.875rem 0 0.875rem 8.125rem;

[TH-97]

질문! px와 rem의 사용 기준이 모호해서 그런지, 정확히 어떤 상황에서 rem을 써야 할지 감이 잘 안 옵니다. 루트는 어떤 경우에 rem을 주로 사용하시나요? 요즘 반응형으로 제작된 사이트에서 rem을 많이 활용하는 사례를 보긴 했지만, 저에게는 아직 그 방식이 크게 와닿지 않네요.

[eastroots92]

우선 px와 rem은 폰트 사이즈 대응에 차이가 있어요.
저도 크게 신경을 안쓰다 당근에 와서 이 차이에 체감을 많이 하는데요.
당근의 경우 전 연령이 사용하고 있고, 특히 40~60대가 더 활발히 사용하다보니 폰트사이즈 대응을 더 신경쓰게 되어요.

어르신의 경우 휴대폰 디바이스 OS에서 폰트사이즈를 키우게 되는데요. 이때 rem은 이에 상응하게 커지게 되고, px는 고정값으로 반응해요.

사실 상황마다 다르긴 한데 보통 텍스트는 무조건 rem, 좌우 간격은 보통은 px 상황에따라 rem을 사용하고 있어요.
이미지의 경우에도 특수한 상황이 아니면 px로 지정하는 경우가 많이 있구요.

폰트가 키워졌을 때에도 미려한 UX를 전달하면 좋겠지만 쉽지 않기 때문에 최소한 모든 기능을 의도대로 쓸 수 있게 하는 것에 목표를 두고 있어요.

[eastroots92]

P2;

const matchCount = new Set([...lottoNumbers]).intersection( 에서 사용되는 Set은 최근에 지원하기 시작한 브라우저 API에요!

현재는 큰 문제가 없긴 하지만 만약 오래된 브라우저도 대응해야 한다면 어떻게 할 수 있을까요!?

[TH-97]

오래된 브라우저를 대응해야 한다면 filter로 교집합을 직접 구현할 것 같습니다

[eastroots92]

filter을 사용해서 직접 구현하는 방법도 있지만 이 경우 매번 브라우저 지원 범위를 신경쓰는게 어려워요. (브라우저, OS가 모두 어디까지 지원하는지 파악하기가 어렵기 때문)

이런 경우 빌드단계에서 자동으로 최신 문법을 하위 문법으로 동작 가능하게 하는 방법이 있는데요!
바로 폴리필이에요! 지금 당장은 적용할 필요가 없지만 추후 서비스를 만들때 하위 버전, 특정 버전 이상을 대응해야 하는 경우라면 필요하니 가볍게 살펴봐 주세요!

[eastroots92]

P2. 콘솔과 웹의 차이가 무엇인지 고민해봐 주세요.

PR 내용에 적어주신 이번 단계에서 가장 많이 고민했던 문제와 해결 과정에서 배운 점과 관련된 내용이기도 해요.

콘솔과 웹은 Flow가 달라요. 콘솔은 "순차적(절차적)"으로 동작하지만, 웹은 "이벤트 기반"으로 동작해요.

현재 while 코드를 보면 입력 > 처리 > 출력이 순차적으로 일어나고 있는데 이는 웹에서는 적합하지 않아요.
콘솔에서 입력을 기다리기 위해 상황을 강제 할 수 있고 그 다음 작업을 순차적으로 진행 할 수 있지만 웹의 경우 여러 입력을 동시 다발적으로 하거나, 입출력이 동시에 되거나 하는 경우가 빈번해요.

보통 웹에서 설계를 할 때엔 상태 기반으로 구현을 하는 경우가 많이 있어요.
즉, 상태 변화에 각각의 요소들이 반응하는 구조에요.

class App {
    #state = 'PURCHASE';

    handlePurchase(amount) {
      this.#lottoMachine = new LottoMachine(amount);
      this.#output.printLottos(this.#lottoMachine.getLottos());
      this.#state = 'WINNING_INPUT';
    }

    handleWinningInput(winningLotto) {
      this.#lottoMachine.calculateMatchResult(...);
      this.#output.printResult(...);
      this.#state = 'RESULT';
    }

    handleRestart() {
      this.#state = 'PURCHASE';
      this.#output.reset();
    }
  }

간단한 POC인데 이렇게 하면 콘솔에서든 웹에서든 같은 App을 사용할 수 있고 진행 현황 등을 State로 두고 각각의 요소에서 State의 변경에 따라 관련된 이벤트를 실행하거나, 각각의 요소에서 State를 구독하고 있다가 변경되는 상황에 맞게 대응하면 좋아요.
(React에서 사용하는 전역 상태 라이브러리, 디자인 패턴 중 PubSub 패턴 등등이 이런 구조적 문제, 의존성을 낮추고 응집도를 높이기 위한 고민 속에서 나온 패턴들이에요)

위 예시 코드가 딱 베스트 프레틱스는 아니지만 저런 컨셉으로 접근하면 웹과 콘솔을 둘다 대응 할 수 있지 않을까? 정도로 참고해주시면 좋겠어요.

[TH-97]

크루원들과 비슷한 고민을 했었어요. 한 크루가 "콘솔은 순차적인데 웹에서도 그게 가능해요?"라고 물었고,
저는 되게 만들었지만 불편한 점이 많다고 느꼈거든요.

리뷰를 보고 나서 생각해보니, 제가 놓쳤던 부분이 순서를 어디서 관리하냐였던 것 같아요.
현재 코드는 while 루프가 순서를 App 내부에 하드코딩하고 있어서 콘솔 흐름이 App에 박혀버린 구조인 거고, 상태 기반으로
설계하면 state가 순서를 관리하기 때문에 콘솔/웹 어디서든 같은 App을 재사용할 수 있다는 점을 이해했습니다.

[eastroots92]

P2 LottoMachine이 너무 많은 일을 하는 것 같아요.

이는 당장 수정 할 필요는 없고, 만약 다시 만든다면 어떻게 역할을 나눠보면 좋을까? 에서 접근해보면 좋겠어요.

크게 우리는 두가지 축을 고민했어야 했어요.

1. 콘솔, 웹 -> 입출력과 로직, 도메인을 분리하여 생각하는 것
2. 로직, 도메인 속에서 역할을 잘 나누는 것

지금 여기서 이야기기 하는 내용은 2번에 가까워요.

현재 LottoMachine이 하는 역할을 나열해보면 로또 생성, 보관, 당첨 결과 계산, 수익률 계산을 모두 담당하고 있는데 실제 현실에선 로또 판매기가 당첨 확인까지 하진 않는 것 처럼 역할을 나누어 볼 수 있었을 것 같아요.

• 로또 생성/ 보관
• 당첨 결과 판정
• 수익률 계산

이런 식으로 나누어 설계 해볼 수 있지 않았을까 해요!

[TH-97]

원정대 활동을 하면서 SOLID 원칙을 배웠는데, 이번 피드백을 보고 제 LottoMachine이 SRP(단일 책임 원칙)를 위반하고 있었다는 걸 확실히 알게 되었어요.

지금은 로또 생성과 보관, 당첨 판정, 수익률 계산까지 전부 한곳에서 처리하고 있더라고요. 클래스를 변경해야 할 이유가 여러 가지라는 점이 큰 문제인 것 같아, 역할을 아래처럼 나누어 설계해 보려고 합니다.

LottoMachine: 로또 생성 및 보관

LottoJudge: 당첨 등수 판정 (조건 분기)

LottoCalculator: 수익률 계산 (수학적 연산)

판정과 계산을 분리한 이유는, 등수를 결정하는 로직과 그 결과를 이용해 수익률을 구하는 동작은 성격이 아예 다르다고 생각했기 때문입니다. 좋은 피드백 주셔서 감사합니다!

단일 책임의 원칙은 actor를 기준으로 나눈 다고 알고 있는데 이 책임의 범위는 어디까지 일까요? 너무 많이 나누게 되면 오버엔지니어링이나 파일 관리가 걱정이 됩니다. 루트는 어떤 기준을 두고 actor를 짜시나요? 그리고 책임의 범위는 어디까지 설정하시나요?