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

[jebiyeon02]

학습 목표

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

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

제출 전 체크 리스트

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

대략적인 레이아웃

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

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

1. BEM 네이밍

index.html 파일을 작성하면서 가장 시간을 많이 투자했던 부분입니다.
클래스명을 지을 때 일관적인 규칙을 정하고 싶어 찾아보던 중 BEM 네이밍에 대해 알게되었습니다.
CSS를 적용하지 않는 요소더라도 모든 요소애 class를 붙여주었습니다. html과 css만 작성할 때는 크게 편리한 점을 느끼지 못했었지만 Javscript로 DOM을 조작할 때 querySelector만으로 원하는 요소를 일관성있게 가져올 수 있다는 장점을 느꼈습니다.

2. DOM 조작 비용

Controller를 처음 작성할 때 여러 메서드에서 같은 요소를 반복해서 querySelector로 가져왔었습니다.
이 방식에 대해서 별다른 의심을 하지 않았지만, 공통 피드백 시간에 DOM 접근 비용이 굉장히 크다는 것을 알게 되었습니다.
DOM과 관련된 비용을 줄이기 위해 각 도메인별 View에 필요한 DOM에 1번씩만 접근할 수 있도록 코드를 작성하였습니다.

3. Controller와 View를 분리하기

UI 구현으로 넘어오면서 어떤 로직이 Controller이고 View인지 구분하기가 매우 힘들었습니다.
처음 Controller에는 직접 DOM에 접근해서 UI를 수정하는 부분이 대다수였습니다.
DOM에 접근하는 것과 특정 도메인의 UI를 수정하는 부분을 각 도메인 별 View 내부로 이동시켜서 View과 Controller의 역할을 명확하게 분리하려는 노력을 해봤습니다.

제가 가장 의외였던 부분은 Event Handler 또한 View에 존재해야 된다는 것이었습니다. 버튼을 클릭했을 때 특정 작업들을 수행하기 때문에 Controller가 온전히 책임을 갖는 것이 맞다고 생각했었습니다. 하지만 Controller에서 하게될 경우 DOM에 직접 접근할 수 밖에 없기 때문에 자연스럽게 View로 간다는 사실을 알게 되었습니다.
하지만 여전히 이벤트 발생시 작업은 Controller가 처리해야 하기 때문에 Controller에서 이벤트 발생시 함수를 구현해놓고, 이를 View의 바인딩 메서드에서 받아와 관심사 분리를 해야한다는 것을 알게 되었고, 이를 바탕으로 구현 했습니다.

3. 기존 도메인 로직을 거의 건드리지 않기

기존 테스트 코드와 도메인 로직을 전혀 수정하지 않고 UI를 붙이는 것을 목표로 했습니다.
기능을 완성하는 것에는 큰 무리가 없었지만, 수정하고 싶은 곳도 많았습니다.
가장 먼저 생각나는 것은 도메인 전용 Validator가 없어서 사용자한테 정확한 피드백을 제공하지 못하는 것이었습니다.
로또 번호의 유효범위를 벗어나게 작성해도 로또번호의 범위를 알려줄 수 없었습니다.
이는 input 태그의 기본 속성을 이용해 어느정도 보완을 하긴 했지만, 피드백을 받은 후에 도메인 로직을 조금 수정해서 정확한 피드백을 제공할 수 있도록 할 예정입니다.

(도메인 관련해서는 현재 RANK 상수에 MUST_HAVE_BONUS라는 항목만 추가했습니다)

4. Fragment 활용하기

기존 DOM 트리에 append할 때마다 화면이 다시 그려져 자원 낭비가 발생하는 것을 알게 되었습니다.
하지만 Fragment를 활용하면, 메모리에 임시 저장되기 때문에 append를 여러번 해도 화면의 레이아웃을 다시 계산(Reflow) 하거나 화면을 다시 그리지(Repaint) 않는다는 사실을 알게 되었습니다.
이를 당첨 통계 생성 부분에 적용해 봤습니다.

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

안녕하세요 호프! 이번에도 리뷰 맡아주셔서 감사합니다🙏
브랜치 문제가 있었어서 docs(readme): 2단계 기능 목록 및 TODO 작성 커밋 이전은 무시해주시면 감사하겠습니다!

1. 시맨틱 태그의 사용법

header main footer와 같은 큰 요소들에 대해서는 개인적으로 적절히 태그를 부여했다고 생각합니다.
혹시 부적절하게 사용된 시맨틱 태그가 존재하는지 궁금합니다. (특히 section의 사용에 관해)

또한 다시 제 코드를 살펴보니 span과 p를 거의 쓰지 않은 것을 알게 되었습니다.
div 대신 span이나 p를 꼭 사용해야 되는 부분이 있는지 궁금합니다.

2. 도메인별 View에 대해

DOM에 접근, UI조작, 이벤트 핸들러 바인딩 등의 코드가 도메인 별 View에 존재하는데, View가 길어져서 너무 많은 책임을 가지고 있는 것은 아닌지 의심을 하곤 했습니다. View 수정이 필요한지 궁금합니다.

또한 각 도메인별로 DOM 접근을 최소화하기 위해 멤버변수를 선언해두었는데, 멤버 변수가 너무 많아지는 것 같아 걱정입니다.
요구사항에도 멤버 변수는 최대 2개까지라고 되어 있는데, 아직 방법을 찾지 못했습니다.

3. 정적 생성과 동적 생성에 대해

ResultModalView의 renderScore 메서드 관련 질문입니다.
처음에는 정적으로 된 tr,td가 존재하고 당첨 개수 text만 바꿔주는 식으로 코드를 작성했습니다.

하지만, DOM 접근을 너무 많이 시도하는 것 같아서 동적으로 생성하는 현재의 방식으로 변경했습니다.
현재 제 생각으로는 동적으로 생성하는 부분도 문제점이 존재하는 것 같습니다.
일치 개수,당첨금같이 정적으로 존재해도 되는 요소들을 동적으로 생성해야 된다는 것입니다.

정적 생성 vs 동적 생성(현재 코드) 중 어떤 것이 조금 더 좋은 방식인지 궁금합니다.

4. 게임 초기화와 관련하여

현재 메인 컨트롤러에서 하나하나 값을 비워주고 reset하는 방식을 사용하고 있는데, 문제없는 방식인지 궁금합니다.
최초에 컨트롤러가 실행되며 View를 생성해놨기 때문에, 컨트롤러를 재생성 하는 방식에 비해서 DOM 접근 비용이 낮다고 생각해 해당 방식을 사용했습니다.

5. this 바인딩 유지를 위한 화살표 함수

this 바인딩 유지를 위해서 몇몇 메서드는 화살표 함수로 작성했는데, 일관성을 위해 나머지 모든 메서드도 화살표 함수로 작성해야 하는지 궁금합니다.

---

✅ 리뷰어 체크 포인트

1단계

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

2단계

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