[2단계 - 웹 기반 로또 게임] 피트 미션 제출합니다.#453
Conversation
degurii
left a comment
degurii
left a comment
There was a problem hiding this comment.
처음 시도해보는 개발이라 혼란한 와중에도 잘 진행해주신 것 같아요. 요번주도 고생 많으셨습니다!
개인적으론 지금 레벨에서 MVC다, MVVM이다 이런 것들에 대한 정의를 명확히 내리는 건 크게 의미가 없을 것 같아요. 어떻게 언어로 정의를 한다고 해도, 실제로 본인에게는 그 그림이 그려지지 않을 확률이 높거든요. 요런 상황에서 지금같은 코드가 나오는 건 너무 당연한 일이고, 피트가 부족하다기 보다 빠른 시간 내 많은 것들을 배워야하는 부트캠프라는 특수한 환경때문에 좀 버겁게 느껴지시는 거라고 생각합니다. 그러니 본인의 실력이나 코드에 대해서는 너무 걱정하지 마시고, 우테코 기간 동안 최대한 많은 경험을 쌓아가시면 좋을 것 같습니다.👍👍👍
질문 답변
- 현재 제 미션의 구조인 [index.html에서 컴포넌트를 처럼 불러오기, step2-index.js에서 import문 가져오기, Header.js를 HTMLElement를 상속받은 클래스로 만들어 connectedCallback()와 render()로 UI를 렌더링] 이 방식이 올바른 방법인지 궁금합니다.
접근법 자체는 유효합니다. 다만 해당 코드 세부 코멘트로 리뷰드렸듯, 책임이 너무 커서 분리가 필요해보여요. (comment)
- 제가 완벽하게 리팩토링한 상태로 제출한 것이 아니라 제가 아는 범위 내에서 할 수 있는 만큼 구현한 뒤 제출한 것이라서, 제가 코드를 어떤 방향으로 분리해야 하며 어떤 식으로 view와 controller, service를 분리해야 관심사 분리를 잘 해낼 수 있는지 궁금합니다.
요것도 1번에서 드린 답변으로 갈음할 수 있을 것 같아요. 지금처럼 아키텍처적 감이 없는 상태에서 view는 무엇이다, controller는 무엇이다, service는 무엇이다 해도 절대 와닿지 않으실 수 있고, 그런 것들의 정의나 용례 자체가 개발자마다, 조직마다 다 조금씩은 다르거든요. 그러니 제가 코멘트로 드린 기준을 우선 생각해보시고, 그 후에 확장해나가는 것을 추천드립니다. (comment)
- 제가 태그를 사용하다보니 특정 태그를 제외하고는 div태그만 사용한 것 같은데, 어떤 경우에 시멘틱 태그들을 사용하는 것이 적절한지 궁금합니다.
요건 사실..... 저희는 퍼블리셔분이 있어서 저도 잘 알려드릴 수 없는 영역인 것 같아요 ㅎㅎ..
이런 것들은 MDN에서 괜찮은 가이드를 제공하기 때문에, 요런 문서로 학습해보는 것도 좋을 것 같습니다.
https://developer.mozilla.org/en-US/curriculum/core/semantic-html/
- UI 테스트에 대해서는, 처음에는 필요성을 느꼈지만, 2단계 시작 직전에 "굳이 UI에 대한 테스트가 필요할까?"라는 생각이 들어 테스트를 생략했습니다.... UI에 대해서는 테스트하는 게 일반적인지, 그렇다면 E2E로 진행하는 것이 일반적인지, 아니면 jsdom을 추가로 설치하여 이것으로 테스트를 진행해야 하는지 궁금합니다.
UI테스트의 경우 장기적으로 안정성을 보장해줄 수 있으나, 그 특성상 자주 변경될 수 있어 테스트가 많은 경우 수정 범위가 커지고, 유지보수의 효율을 떨어뜨릴 수는 있어요. 이번 과제와 같은 사이즈에서는 도메인로직만 테스트해주셔도 될 것 같구요.
유닛이냐, e2e냐는 좀 더 목적에 따라 갈릴 것 같아요.
만약 실제 렌더링되어서 유저에게 보이는 모습을 확인하고싶다면 e2e를 적용하는 것이 맞을 것 같구요, 그게 아니라 단순히 어떤 컴포넌트가 어떤 문구나 데이터를 노출하는지, 어떤 스테이트로 유지되는지를 확인하는 정도라면 유닛 테스트가 더 효율적일 것 같아요.
- 제가 현재 가장 크게 느끼는 고민은 "2단계 미션을 진행하면서 도대체 코드를 어떻게 분리하고 정리해야 하지?"입니다. 제가 아예 알지 못하는 부분을 코드로 작성하려고 하니 생각 정리도 잘 안되는 것처럼 느껴졌습니다! 이럴 때 UI 분리와 역할을 잘 이해하기 위해서 제가 참고할 수 있는 자료나 영상이 있다면 공유해주시면 감사하겠습니다🥹
저도 리액트로 먼저 웹개발을 공부해서 비슷한 고민을 했고, 여러 방면으로 찾아봤던 기억이 있어요. 근데 요것이야 말로 이론적인 내용보다는 여러가지 경험이 가장 중요한 것 같습니다. 딱 프론트엔드 개발, 그중에서도 프레임워크 위주로만 이용해본 사람은 아키텍처적 감이 여타 개발자에 비해 확실히 떨어진다고 말씀드릴 수 있을 것 같아요.
저도 사실 경험이 많지 않기 때문에 제 말이 정답이다라고 말씀을 절대 못드리는데요. 대신 제가 공부해왔던 것들을 기반으로 몇가지 제안을 드리도록 할게요.
- 백엔드는 전통적으로 오랫동안 보완되어온 객체지향적 체계가 있거든요. 자바를 할 줄 아신다면 스프링을, 아니라면 Nest.js를 공부해보시는 것을 추천드립니다. 너무 유연해서 오히려 초심자에게는 단점이 되는 프론트 생태계와 달리, 정적 타입 언어와 잘 고정된 아키텍처를 제시하는 백엔드 프레임워크를 사용하면서 개발을 진행하기만 해도, 거기에 수년간 쌓여 발전되어온 인사이트를 배워갈 수 있을 것이라 생각해요.
- 함수형 패러다임에 대해서도 공부해보시는 것을 추천드립니다. 단순히 커링이나 고차함수같이 함수형 언어의 기술적 사용법만을 공부하는 게 아니라, 함수형 언어는 객체지향이 목적인 언어에 비해 어떤 제약과 어떤 자유로움이 있고, 그 제약이 무엇을 위해 설정된 것인지, 그 함수형 언어로 만든 서비스의 전체적인 실행 사이클이 어떻게 돌아가는지, 아키텍처는 어떻게 구성되는지, 어떤 제약때문에 그렇게 구성되었고, 어떤 이점이 있는지 등등.. 본인이 아는 것과 비교해가며 공부해보는 것을 추천드립니다.
- 책으로는.. 음.. 제가 많은 책을 읽어보진 않았는데요. 로버트 마틴의 "클린 아키텍처"정도 추천드릴 수 있을 것 같아요. 요건 제가 취준생 때 봤었는데, 그당시의 저는 경험이 알량해서 반도 이해를 못했던 기억이 나거든요. 그런 와중에서도 꽤 괜찮은 인사이트를 얻었던 경험이 있어 추천드립니다.
src/webView/Main/MainApp.js
Outdated
| #validator; | ||
|
|
||
| #isShowLottos; | ||
| #isOpenModal; | ||
|
|
||
| #purchaseAmount; | ||
| #purchaseError; | ||
|
|
||
| #lottoList; | ||
| #lottoGame; | ||
| #winningError; | ||
|
|
||
| #statistics; | ||
| #rate; |
There was a problem hiding this comment.
[필수]
과제 컨벤션 중에, 클래스를 사용하는 경우, 3개 이상의 인스턴스 변수를 가진 클래스를 쓰지 않는다. 라는 요구사항이 있는데요. 저는 사실 몇개 더 넣어도 코멘트를 남기지는 않는데, 요번엔 멤버변수가 너무 많은 것 같아요.
이런 현상은 메인 앱에 책임이 너무 많다는 지표로 해석될 수 있거든요. 그러니 관심사를 잘 분리해서 책임을 분산해주면 좋을 것 같은데, PR 디스크립션을 보니 요부분에 대해 이미 인지하시고 고민을 많이 하셨던 것 같아 어느정도의 방향성을 제안드릴 수는 있을 것 같습니다.
1단계에서 구현해주신 App.js를 보면 책임 분리가 깔끔하거든요. App 클래스는 validator, inputView, outputView만 알고있고, 그외 도메인 로직을 처리할 땐 메서드간 인자로 넘겨주는 방식을 택해서 App 클래스가 세부적인 도메인 로직이나, 콘솔에 어떻게 출력할지에 대해서는 알지 못해도 되는 방식으로 구현해주셨어요.
사실 그때 해주신 것과 유사하게 모듈을 잘 나눠주시면 되긴 할 것 같은데.. 요부분은 어느정도 아키텍처적인 감이 필요한 영역이라 아마 처음 시도하는 것들이 많은 지금같은 상황에서는 힘드실 수도 있을 것 같아요.
그럼 제가봤을 때 이 상황에서 1차적으로 적용해볼 수 있는 기준은 요런 것들인 것 같아요.
MainApp의 명확한 역활이 무엇인가? 전반적인 로직 사이클을 돌려주는 책임인지, UI적 요소로서의 메인 책임인지?- 여러 멤버변수들이 있는데, 이 값들이 UI를 표시하기 위한 상태인가, 도메인 로직을 수행하기 위한 상태인가?
- 이 클래스에서 유지 중인 변수가 실제로 렌더링 과정 중, 혹은 비즈니스 로직 수행 과정 중에 계속해서 참조되고, 꼭 있어야만 하는 값들인지? 아니면 이 값들을 유지하지 않고서도 적절한 책임 분산을 통해 수행하고자 하는 목적을 이룰 수 있을지?
이런 것들을 먼저 생각해보고, MainApp이 어떤 일들을 하고 있는지 나열해보고, 나름대로 관심사별로 분류한 뒤에, 클래스/함수/파일 분리 무엇이든 상관 없으니 피트가 적절하다고 생각하는 방향으로 책임을 잘게 쪼개보면 좋을 것 같아요. 물론 커스텀 엘리먼트라는 형식 내에서 모든 것을 다 처리해야 할 필요가 없다는 것도 같이 생각해보면 좋을 것 같아요.
구성해봤더니 너무 잘게 쪼개졌다 싶어도 크게 상관은 없어요. 원래 개발은 보통 큰 걸 쪼개는 것보다, 작은 걸 합치는 작업이 더 쉽거든요. 그러니 분리 과정에서 이게 맞나? 같은 자기 검증은 우선 내려두시고 일단 먼저 진행해보시는 것을 추천드립니다.
There was a problem hiding this comment.
- 제가 의도한 방식으로는
MainApp.js가 컨트롤러의 역할을 하고, 모든 멤버변수를 관리할 수 있는 상태로 만드는 것이었습니다. 그치만 어쨋든 요구사항에도 멤버 변수를 줄이라는 명세가 존재했고, 너무 많은 책임을 가지고 있다는 피드백에도 동의해서 전체적인 구조를 뜯어?고쳐보았습니다. 사실 제가 처음 PR을 날리면서 계속 고민했던 점은, 이 방법이 좋지 않은 방법이므로 아예 다른 구조로 작성해봐야겠다~ 였습니다. 그래서 전체적인 구조를 Controller - View - Service로 변경해보았습니다. 제 기준으로 바꾼 방식이 훨씬 가독성도 좋고 제가 조합을 의도하면서도 책임 분리가 되었다고 생각했습니다. - 그럼에도 질문드릴 것이 있는데,
- 이전에 제가 렌더링한 방식에 비해 더 나아진 방식이라고 생각하시는지 궁금합니다!
- 그리고 멤버 변수를 줄였다고 해도, 현재 컨트롤러에 서비스 1개와 view 4개의 변수를 가지고 있는데, 만약 규모가 커지면 view가 더 추가될 것이고, 그러면 controller가 더 많은 view 변수를 가지게 될 것 같은데 컨트롤러도 여러 개로 분리하는 것이 좋은 방식일까요?
- 제가 리액트에 익숙해서, 컴포넌트별로 섹션을 나눈 뒤에 props로 상태를 관리하는 방식을 주로 사용했는데, 새로 짠 구조에서는 index에 전체적인 구조가 존재하고 필요한 div나 p태그 등에 render 메서드를 호출하는 방식입니다. 그래서 지금 index.html 하나의 파일을 여러 개로 나누는 게 좋은지, 아니면 지금 하나의 파일 구조를 틀로 정해놓고 필요한 부분부분에 render메서드를 호출하는 게 좋은지 궁금합니다! (제가 말을 잘 못하는 것 같아서 첨부드리자면, 예를 들어 제가 변경한 코드에서, LottoView.js가 단순 구입 로또 아이콘 및 번호로 이루어진 1줄을 추가하는 방식이 좋은지, 만약 LottoView.js에서
section class="lottos-container"를 포함한 하나의 컴포넌트를 렌더링하는 방식이 좋은지 그런 부분이 궁금합니다)
There was a problem hiding this comment.
- 이전에 제가 렌더링한 방식에 비해 더 나아진 방식이라고 생각하시는지 궁금합니다!
확실히 이전보다 나아졌다고 생각합니다. 이전에는 메인앱에서 UI 상태관리, 도메인 객체 생성하기, 유효성검사 등등 너무 많은 일들을 하고 있었는데, MVC로 구조화하면서 책임이 적절히 분산된 모습이 보여서 좋습니다👍
- 그리고 멤버 변수를 줄였다고 해도, 현재 컨트롤러에 서비스 1개와 view 4개의 변수를 가지고 있는데, 만약 규모가 커지면 view가 더 추가될 것이고, 그러면 controller가 더 많은 view 변수를 가지게 될 것 같은데 컨트롤러도 여러 개로 분리하는 것이 좋은 방식일까요?
넵 규모가 커질 떄 컨트롤러를 분리하는 건 자연스러운 방향입니다. 다만 분리 기준이 중요한데, 단순히 view가 많아져서 분리를 한다기 보다 그 뷰 집합들이 서로 독립적인 기능 흐름으로 나뉘기 시작했는지가 더 적절한 기준인 것 같아요. 아시겠지만 변수 개수 제한, 뷰 개수 같은건 어디까지나 적절한 책임 분산을 유도하기 위한 과제의 장치에 가깝지, 그 자체가 구조를 나누는 직접적인 기준은 아니라고 생각합니다.
- 제가 리액트에 익숙해서, 컴포넌트별로 섹션을 나눈 뒤에 props로 상태를 관리하는 방식을 주로 사용했는데, 새로 짠 구조에서는 index에 전체적인 구조가 존재하고 필요한 div나 p태그 등에 render 메서드를 호출하는 방식입니다. 그래서 지금 index.html 하나의 파일을 여러 개로 나누는 게 좋은지, 아니면 지금 하나의 파일 구조를 틀로 정해놓고 필요한 부분부분에 render메서드를 호출하는 게 좋은지 궁금합니다! (제가 말을 잘 못하는 것 같아서 첨부드리자면, 예를 들어 제가 변경한 코드에서, LottoView.js가 단순 구입 로또 아이콘 및 번호로 이루어진 1줄을 추가하는 방식이 좋은지, 만약 LottoView.js에서 section class="lottos-container"를 포함한 하나의 컴포넌트를 렌더링하는 방식이 좋은지 그런 부분이 궁금합니다)
제가 질문을 잘 이해한 게 맞다면, 지금처럼 전체 골격은 바깥에 두고 각 view가 필요한 부분만 갱신하는 방식으로 가는 게 좋을지, 아니면 각 뷰가 자신이 담당하는 마크업을 조금 더 큰 단위로 직접 소유하는 구조로 가는 게 더 적절할지에 대한 고민으로 이해했습니다. 아마 이 질문의 배경에는, 리액트식 컴포넌트 구조에 익숙한 상태에서 지금처럼 index.html 중심 + 부분 갱신 형태로 바뀌었을 때, 이 방식도 괜찮은 구조라고 볼 수 있는지에 대한 약간의 불안이 있으신 게 아닌가 싶어요.
두 방식을 어느 정도 익숙한 프레임워크에 빗대어 볼 수는 있을 것 같아요. 각 뷰가 자신이 맡은 마크업을 비교적 큰 단위로 소유하는 쪽은 리액트같은 컴포넌트 기반 방식에 조금 더 가깝고, 반대로 전체적인 html 골격을 먼저 두고 필요한 부분만 갱신하는 쪽은 전통적인 DOM 조작 방식에 더 가까운 느낌이라고 볼 수 있을 것 같습니다.
다만 여기서 더 중요한 것은 어떤 방식이 더 좋으냐보다, 하나의 view가 어디까지를 자기 책임으로 가져가는 것이 자연스러운가라고 생각합니다. 제 기준에는, 항상 함께 변경되는 마크업과 동작이라면 하나의 뷰가 더 큰 단위로 들고 가는 편이 자연스럽고, 반대로 큰 구조는 거의 고정되어 있고 일부 내용이나 상태만 바뀌는 영역이라면 지금처럼 바깥에 틀을 두고 필요한 부분만 갱신하는 방식도 충분히 괜찮다고 생각합니다. 그러니 저는 처음부터 특정 형태를 정답처럼 두기보다는, 실제로 함꼐 변경되는 범위가 어디까지인지를 기준으로 구조의 적절성을 판단하는 것이 중요하다고 생각되어요.
답변이 좀 추상적으로 느껴지시겠지만, 실제로 이런 문제는 무엇이 더 좋다, 나쁘다고 쉽사리 단정지을 수 있는 영역은 아니라고 생각합니다. 대신 본인이 선택한 구조로 계속 개발을 진행하며, 새로운 코드와 수정이 쌓이면서 어떤 불편이 드러나는지, 어떤 이점이 있었는지를 같이 보는 편이 더 현실적이라고 생각하거든요.
조금 구체적인 예를 들어보자면, 이후에 로또 구매 영역의 UI가 바뀌어서 구매 개수 문구, 로또 목록, 빈 상태 안내, 스크롤 처리 같은 것들을 항상 같이 수정하게 된다고 해보겠습니다. 만약 이런 수정이 들어올 때마다 index.html, LottoView, 다른 view 쪽 코드까지 같이 열어봐야 한다면, 그 시점에는 로또 목록 영역 전체를 하나의 view가 조금 더 큰 단위로 맡는 쪽이 더 자연스러울 수 있을 것 같습니다.
반대로 로또 목록과 관련된 수정이 들어와도 대부분 LottoView 안에서 끝나고, 바깥 골격은 거의 건드릴 일이 없다면 지금처럼 큰 틀은 바깥에 두고 필요한 부분만 갱신하는 방식이 더 잘 맞는 구조일 수도 있겠구요.
그러서 지금은 어떤 형태를 정답처럼 정해두기보다는, 이후 변경이 들어올 때 수정 포인트가 자연스럽게 한곳에 모이는지를 기준으로 계속 점검해보시면 좋을 것 같습니다.
src/webView/Main/Purchase.js
Outdated
| <input class="input-line" id="purchase-amount" placeholder="금액" /> | ||
| <button class="input-button">구입</button> | ||
| </form> | ||
| <a class="input-error" ${error ? "" : "hidden"}>${error}</a> |
There was a problem hiding this comment.
[권장]
<a> 태그는 링크를 의미하는데, 단순히 에러 메시지를 보여주는 용도로 사용 중인 것 같아요. 태그 변경을 추천드립니다.
GamjaIsMine02
left a comment
GamjaIsMine02
left a comment
There was a problem hiding this comment.
제가 질문했던 내용들에 대해 정말 많은 도움을 받은 것 같습니다! 감사합니다 데구리👍
src/webView/Main/MainApp.js
Outdated
| #validator; | ||
|
|
||
| #isShowLottos; | ||
| #isOpenModal; | ||
|
|
||
| #purchaseAmount; | ||
| #purchaseError; | ||
|
|
||
| #lottoList; | ||
| #lottoGame; | ||
| #winningError; | ||
|
|
||
| #statistics; | ||
| #rate; |
There was a problem hiding this comment.
- 제가 의도한 방식으로는
MainApp.js가 컨트롤러의 역할을 하고, 모든 멤버변수를 관리할 수 있는 상태로 만드는 것이었습니다. 그치만 어쨋든 요구사항에도 멤버 변수를 줄이라는 명세가 존재했고, 너무 많은 책임을 가지고 있다는 피드백에도 동의해서 전체적인 구조를 뜯어?고쳐보았습니다. 사실 제가 처음 PR을 날리면서 계속 고민했던 점은, 이 방법이 좋지 않은 방법이므로 아예 다른 구조로 작성해봐야겠다~ 였습니다. 그래서 전체적인 구조를 Controller - View - Service로 변경해보았습니다. 제 기준으로 바꾼 방식이 훨씬 가독성도 좋고 제가 조합을 의도하면서도 책임 분리가 되었다고 생각했습니다. - 그럼에도 질문드릴 것이 있는데,
- 이전에 제가 렌더링한 방식에 비해 더 나아진 방식이라고 생각하시는지 궁금합니다!
- 그리고 멤버 변수를 줄였다고 해도, 현재 컨트롤러에 서비스 1개와 view 4개의 변수를 가지고 있는데, 만약 규모가 커지면 view가 더 추가될 것이고, 그러면 controller가 더 많은 view 변수를 가지게 될 것 같은데 컨트롤러도 여러 개로 분리하는 것이 좋은 방식일까요?
- 제가 리액트에 익숙해서, 컴포넌트별로 섹션을 나눈 뒤에 props로 상태를 관리하는 방식을 주로 사용했는데, 새로 짠 구조에서는 index에 전체적인 구조가 존재하고 필요한 div나 p태그 등에 render 메서드를 호출하는 방식입니다. 그래서 지금 index.html 하나의 파일을 여러 개로 나누는 게 좋은지, 아니면 지금 하나의 파일 구조를 틀로 정해놓고 필요한 부분부분에 render메서드를 호출하는 게 좋은지 궁금합니다! (제가 말을 잘 못하는 것 같아서 첨부드리자면, 예를 들어 제가 변경한 코드에서, LottoView.js가 단순 구입 로또 아이콘 및 번호로 이루어진 1줄을 추가하는 방식이 좋은지, 만약 LottoView.js에서
section class="lottos-container"를 포함한 하나의 컴포넌트를 렌더링하는 방식이 좋은지 그런 부분이 궁금합니다)
src/webView/Main/Purchase.js
Outdated
| <input class="input-line" id="purchase-amount" placeholder="금액" /> | ||
| <button class="input-button">구입</button> | ||
| </form> | ||
| <a class="input-error" ${error ? "" : "hidden"}>${error}</a> |
|
말씀드렸던 부분을 충분히 고민해서 구조를 다시 잡아주신 점 좋았습니다👍 |
2 participants
학습 목표
이번 미션을 통해 다음과 같은 학습 경험들을 쌓는 것을 목표로 합니다.
제출 전 체크 리스트
리뷰 요청 & 논의하고 싶은 내용
1) 이번 단계에서 가장 많이 고민했던 문제와 해결 과정에서 배운 점
MainApp.js에서 모든 UI와 기능을 구현했습니다. 한 파일에 모두 구현한 뒤, html 구조 및 기능 단위로 파일을 분리하였습니다. 분리 한 뒤 MainApp에서의 값을 전달하는 방식으로는 Attribute 전달, 프로퍼티 전달으로 구현했습니다. 이러한 문법을 전혀 알지 못한 상태에서 구현했기 때문에, 제가 짠 코드임에도 정리가 되지 않고 이해하기도 어려운 코드가 되었습니다. 그래도 최선으로 코드를 작성하기 위해 그전에 제가 해오던 방식대로 Header와 MainApp, Footer 세 개로 페이지를 나눈 후, 전역으로 css를 선언하고, MainApp에서 필요한 컴포넌트을 불러와 조합하는 방식으로 구현하려고 시도했습니다.2) 이번 리뷰를 통해 논의하고 싶은 부분
현재 제 미션의 구조인 [
index.html에서 컴포넌트를 처럼 불러오기,step2-index.js에서 import문 가져오기,Header.js를 HTMLElement를 상속받은 클래스로 만들어 connectedCallback()와 render()로 UI를 렌더링] 이 방식이 올바른 방법인지 궁금합니다.제가 완벽하게 리팩토링한 상태로 제출한 것이 아니라 제가 아는 범위 내에서 할 수 있는 만큼 구현한 뒤 제출한 것이라서, 제가 코드를 어떤 방향으로 분리해야 하며 어떤 식으로 view와 controller, service를 분리해야 관심사 분리를 잘 해낼 수 있는지 궁금합니다.
제가 태그를 사용하다보니 특정 태그를 제외하고는
div태그만 사용한 것 같은데, 어떤 경우에 시멘틱 태그들을 사용하는 것이 적절한지 궁금합니다.UI 테스트에 대해서는, 처음에는 필요성을 느꼈지만, 2단계 시작 직전에 "굳이 UI에 대한 테스트가 필요할까?"라는 생각이 들어 테스트를 생략했습니다.... UI에 대해서는 테스트하는 게 일반적인지, 그렇다면 E2E로 진행하는 것이 일반적인지, 아니면 jsdom을 추가로 설치하여 이것으로 테스트를 진행해야 하는지 궁금합니다.
제가 현재 가장 크게 느끼는 고민은 "2단계 미션을 진행하면서 도대체 코드를 어떻게 분리하고 정리해야 하지?"입니다. 제가 아예 알지 못하는 부분을 코드로 작성하려고 하니 생각 정리도 잘 안되는 것처럼 느껴졌습니다! 이럴 때 UI 분리와 역할을 잘 이해하기 위해서 제가 참고할 수 있는 자료나 영상이 있다면 공유해주시면 감사하겠습니다🥹
결론적으로
✅ 리뷰어 체크 포인트
1단계
2단계