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

[JetProc]

학습 목표

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

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

제출 전 체크 리스트

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

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

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

1. step1 로직 재사용

• step1의 Controller작성 시 웹 미션을 전혀 고려 안 하고 해서 그런지 Controller의 재작성은 불가피했던 것 같습니다. 다만 step1 때 도메인과 로직은 확실하게 Controller와 분리했어서 Controller를 재작성하더라도 기존 로직을 건들일 필요는 없었습니다.
• 따라서 공용 로직은 src 폴더에 두고 step1에서만 쓰이는 파일들은 step1 폴더로 분리했습니다.

2. 분리 관점

• MainController가 흐름만 조정하고 LottoView가 DOM 상호작용을 담당하게 나눴습니다.
• 컨트롤러는 구매, 결과 계산, 재시작 같은 조율만 하고, 뷰는 폼 바인딩, 모달 열고 닫기, 화면 초기화 같은 UI 책임만 갖게 했습니다.
• DOM을 찾는 코드는 LottoViewElement.js로, 입력 정제나 HTML 문자열 생성 같은 순수 함수는 LottoViewUtils.js 로 뺐습니다.
• 또 selector 문자열은 config.js 에 모아서 뷰 코드 안에 흩어지지 않게 했고, utils.js 의 $에는 null guard를 넣어서 selector 오타가 나면 바로 잡히게 했습니다.

3. ux 관점

• 입력할 때 에러 발생 시 alert를 띄우고 확인을 눌렀을 때 다시 해당 입력으로 focus가 가도록 하여 사용성을 높였습니다.
• 로또 번호 입력 시 “2자리 숫자, 1부터 45 범위 제한”도 기본 html로는 뭔가 한계가 있어서 js 로직으로 처리해주었습니다.
• 사소하지만 transition과 애니메이션, hover 등에 신경 써보았습니다.

4. css 관련

• css에선 피그마를 참고해서 css/base/global.css에서 전역 스타일 설정값으로서 모두 변수로 만들어 사용했습니다.

• 예전부터 순수 css 파일을 많이 다룰 때 속성 순서를 통일하는 습관이 있었습니다. 개인적으론 요소의 위치와 크기를 알 수 있는 속성들(display, position, width/height, margin/padding, 정렬)을 먼저 상단에 작성하고, 부가적인 것들을 하단에 작성하는 것이 가독성 면에서 편했던 것 같습니다. 따라서 css 속성 작성 시 아래와 같이 순서를 중요시했습니다.

  css 순서

  1. display 관련
  2. position 관련
  3. width, height 관련
  4. margin, padding 관련
  5. 정렬 관련
  6. overflow 관련
  7. border 관련
  8. background 관련
  9. font/text 관련
  10. effect 관련
  11. animation 관련
  12. 기타

5. 테스트 관련

• 이번 테스트에서는 jest.mock()을 적극적으로 사용해봤습니다.
• DOM 없는 가짜 뷰 객체를 넣고, bindPurchase, renderLottoTickets, focusPurchaseInput 같은 메서드가 호출됐는지만 확인할 수 있게 해봤습니다.
• 그리고 getLottoTickets()만 가진 가짜 객체를 반환하게 해서 mockLottoMachineGetLottoTickets로 연결하여 랜덤성 없이 항상 같은 입력으로 흐름을 검증할 수 있게 했습니다.
• 다만 테스트를 진행하면서 테스트 커버리지와 스케일을 어느정도로 잡아야 할지 너무 감이 오지 않아서 결국엔 콘솔로또 테스트와 비슷한 스케일로 했던 것 같습니다.

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

1. MainController, LottoView, LottoViewElements, LottoViewUtils로 역할을 나눈 기준이 적절한지 궁금합니다.
   특히 View 전용 보조 함수/DOM 수집 파일까지 분리한 수준이 과하지 않은지 피드백 받고 싶습니다.

2. 당첨 번호 입력값 정제 로직을 View 레벨(normalizeWinningInputValue)에서 처리한 선택이 적절한지 궁금합니다.
   입력 편의성과 도메인 검증 책임을 어디까지 분리하는 게 좋은지 의견을 듣고 싶습니다. 프로젝트가 커지면 최적화 측면에서 버벅일 수도 있겠다는 생각이 들었습니다.

3. step2 테스트를 실제 DOM/jsdom까지 가지 않고, MainController와 LottoViewUtils 중심의 Jest 테스트로 제한한 판단이 적절한지 궁금합니다.
   현재 프로젝트 규모에서 어느 정도 테스트 범위가 적정한지 피드백 받고 싶습니다.

4. 브라우저 환경 대응을 위해 랜덤 로직을 공용 유틸(pickUniqueNumbersInRange)로 분리한 방식이 적절한지 궁금합니다.
   공용 로직으로 올릴 범위와 step1/step2 전용 로직의 경계를 어떻게 잡는 게 좋은지 의견을 듣고 싶습니다.

---

✅ 리뷰어 체크 포인트

1단계

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

2단계

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

[JUDONGHYEOK]

안녕하세요 파라디!! 2단계 미션도 너무너무 수고많으셨습니다. PR만 봐도 많은 고민을 하셨던게 느껴졌네요.

Controller가 흐름을 조율하고 View가 DOM을 전달하는 간단한 구조로 구현해주셨군요. 깔끔하고 좋습니다. 이렇게 간단한 애플리케이션을 구현하기에는 충분한 구조인 것 같아요. 각각의 역할에 대한 세밀한 피드백은 코멘트로 남겨두었으니 확인 부탁드려요! 현재 미션의 목적 중 하나가 웹 표준을 준수하는 마크업이라서 해당 부분에 대한 코멘트를 조금 남겨두었는데요. 요것도 코멘트로 확인해주시면 감사하겠습니다!!

Q&A

MainController, LottoView, LottoViewElements, LottoViewUtils로 역할을 나눈 기준이 적절한지 궁금합니다.
특히 View 전용 보조 함수/DOM 수집 파일까지 분리한 수준이 과하지 않은지 피드백 받고 싶습니다.

전체적인 구조는 그렇게 과하다고 생각은 들지 않았어요. 다만 LottoViewElement와 같은 경우에는 하나의 팩토리함수인데 현재 규모에서는 LottoView로도 충분히 표현가능하지 않나 라고 생각해요. 파일이 분리되면 DOM참조를 확인하려고 항상 두 파일을 왔다갔다 해야될 것 같아요.ㅎㅎ LottoViewElements가 LottoView없이 쓰일일이 없어서 현재 규모에서는 하나로 합쳐져도 괜찮을 것 같아요!

당첨 번호 입력값 정제 로직을 View 레벨(normalizeWinningInputValue)에서 처리한 선택이 적절한지 궁금합니다.

입력값 정제 로직이 view레벨에서 처리하는 것은 사용자가 물리적으로 입력할 수 있는 값의 범위를 제한한 UX적인 측면의 개선이라 이상하지 않다고 생각했어요. 이건 도메인 검증이랑은 다른 목적을 가진 검증이죠. 성능은 replace와 slice정도의 연산은 input 이벤트가 수천개요소 이지 않는이상 지금 수준에서는 고민하지 않아도 괜찮다고 생각해요

step2 테스트를 실제 DOM/jsdom까지 가지 않고, MainController와 LottoViewUtils 중심의 Jest 테스트로 제한한 판단이 적절한지 궁금합니다.
현재 프로젝트 규모에서 어느 정도 테스트 범위가 적정한지 피드백 받고 싶습니다.

이건 사실 테스트 커버리지의 문제일 것 같아요. 해당 모듈들을 꼼꼼하게 단위테스트한다고 해도 당연히 실제 DOM과의 연결동작에서의 검증은 이뤄지지 않겠죠. 모든 케이스를 jsdom으로 테스트할 필요는 없지만 핵심 사용자 시나리오 정도는 테스트로 작성해두면 셀렉터 오타나 이벤트 바인딩 누락 같은 결합단계에서 이뤄질수 있는 오류들을 검증할 수 있는 안정망이 될 수 있을 것 같아요. 하지만 요부분은 이번단계에서 필수는 아니라고 생각해서 파라디가 생각했을 때 정말 이 애플리케이션의 안정성을 위해 추가되어야한다고 느껴지고 시간이 좀 남는다고 생각하면 추가해보는 것도 좋은 경험이 될 것 같아요

브라우저 환경 대응을 위해 랜덤 로직을 공용 유틸(pickUniqueNumbersInRange)로 분리한 방식이 적절한지 궁금합니다.
공용 로직으로 올릴 범위와 step1/step2 전용 로직의 경계를 어떻게 잡는 게 좋은지 의견을 듣고 싶습니다.

이번미션의 가장 큰 목적중 하나가 UI와 도메인의 분리라고 생각해요. 현재 이 코드를 수정할 이유가 UI 변경때문인지 비즈니스 규칙 변경 때문인지를 생각하고 분리를 하면 되지 않을까 생각합니다. 그런 관점에서 랜덤로직을 공용 유틸로 분리한 것은 합리적인 판단이라고 생각합니다!

2단계도 너무 수고많으셨습니다! 남긴 코멘트 확인해주시고 언제든지 다시 리뷰요청주세요~~

[JUDONGHYEOK]

alert는 브라우저 전용 API고 UI표현의 영역이에요 에러메세지를 보여주는 것에 대한 결정권을 Contoller가 가지면 역할을 벗어나게 됩니다!

[JetProc]

view에 showError()를 추가해서 view를 가져다 쓸 수 있도록 구조를 변경해보았습니다!

[JUDONGHYEOK]

마지막 요소가 보너스 번호라는 규칙이 DOM순서에 의해 암묵적으로 의존되는 것 같아요 만약 마크업 순서만 조금 바뀌어도 조용히 버그가 발생하게 되는데요. 보너스 번호도 별도의 selector로 가져오는 것은 어떠세요?

[JetProc]

좋은 것 같습니다!
보너스 번호에 id 부여해서 별도 selector로 명시적으로 가져오도록 바꿨습니다!

[JUDONGHYEOK]

하드코딩된 수는 상수로 분리해주시면 좋을 것 같아요!

[JUDONGHYEOK]

App의 존재이유는 무엇인가요?

[JUDONGHYEOK]

dialog를 활용해보시는 것은 어떠신가요?

[JUDONGHYEOK]

table element 대신에 grid를 사용해주신 이유가 있으실까요?

[JUDONGHYEOK]

요런 값들도 유지보수 좋게 관리하려면 어떻게 할 수 있을까요?

[JUDONGHYEOK]

소소하지만 개수가 맞는 표현이에요!

[JUDONGHYEOK]

상태 초기화도 같이 검증되면 좋을 것 같습니다!

[JetProc]

jest 사용이 미숙해서 그런 것 같은데, 혹시 상태 초기화 검증은 어떤 식으로 하면 좋을까요?
현재 수정은 mock 변수들을 초기화하고 재시작하여 몇 번 호출 됐는지 확인하는데 이 방식이 적절할까요??

[JUDONGHYEOK]

4가지 시나리오를 하나의 테스트로 검증하기 보다 test.each로 분리되면 실패시 어떤 입력에서 깨졌는지 더 명확해 질 것 같아요 경계값도 추가되면 좋을 것 같구요!

[JetProc]

의견 감사합니다! 전에도 항상 이런 여러 케이스(입출력이 정해져 있는 케이스)에 대해선 test.each를 사용했었는데 이 normalizeWinningInputValue 함수를 메인 함수가 아닌 유틸 정도의 계층으로 생각해서 크게 테스트에 신경을 안 썼던 감이 없지 않아 있네요.. jest 사용이 아직도 미숙한 것 같습니다 ㅎㅎ 수정했습니다!