adds-bug 님의 상세페이지[7팀 박의근] Chapter 1-2. 프레임워크 없이 SPA 만들기 (2)

과제 체크포인트

배포 링크

https://adds-bug.github.io/front_6th_chapter1-2/

기본과제

가상돔을 기반으로 렌더링하기

  • createVNode 함수를 이용하여 vNode를 만든다.
  • normalizeVNode 함수를 이용하여 vNode를 정규화한다.
  • createElement 함수를 이용하여 vNode를 실제 DOM으로 만든다.
  • 결과적으로, JSX를 실제 DOM으로 변환할 수 있도록 만들었다.

이벤트 위임

  • 노드를 생성할 때 이벤트를 직접 등록하는게 아니라 이벤트 위임 방식으로 등록해야 한다
  • 동적으로 추가된 요소에도 이벤트가 정상적으로 작동해야 한다
  • 이벤트 핸들러가 제거되면 더 이상 호출되지 않아야 한다

심화 과제

Diff 알고리즘 구현

  • 초기 렌더링이 올바르게 수행되어야 한다
  • diff 알고리즘을 통해 변경된 부분만 업데이트해야 한다
  • 새로운 요소를 추가하고 불필요한 요소를 제거해야 한다
  • 요소의 속성만 변경되었을 때 요소를 재사용해야 한다
  • 요소의 타입이 변경되었을 때 새로운 요소를 생성해야 한다

과제 셀프회고

  • 문제 이해를 위한 학습에 충분한 시간을 할애했고, 그래서 문제 해결 과정이 (1주차에 비해) 매끄러웠다.
  • 시간 관리에 더 신경써야한다. 학습 과정의 비율이 너무 높아서, 코드로서 문제를 직접 다루는 시간이 적었다.

기술적 성장

  • 가상 Dom 생성 과정을 직접 확인함
  • 디바운스, 스로틀링 개념에 대한 학습

학습 효과 분석

  • 가상 돔이 무적의 치트키가 아닐 수 있다는 점을 고려해야 함 -> 회사 직원분들을 위한 아고라 페이지를 React를 사용하여 만든 것은 적절한 선택이 아니었다는 생각을 하게 됨
  • 추후 이번 주차 심화 과제 해결에 다시 도전해서 Diff 알고리즘을 더 이해해보고자 함

리뷰 받고 싶은 내용

저는 주어진 시간 안에 과제를 해결해야 할 때, 관련된 개념이나 기술에 대한 학습에 너무 많은 시간을 쓰는 경향이 있는 것 같습니다.

이번에도 금요일이 마감이었는데, 수요일까지는 제공해주신 학습 자료를 기반으로 필요하다고 느낀 개념들을 확인하는 데 집중했고, 실제 구현은 목요일부터 시작하게 됐습니다.

사실 이런 패턴은 이번 과제뿐 아니라 실무를 할 때도 반복되는 것 같습니다. 관련 내용을 충분히 이해하고 싶다는 마음이 앞서다 보니, 정작 구현에는 상대적으로 늦게 착수하게 되고, 결국 시간에 쫓기게 되며 ‘조금 더 일찍 손을 대볼 걸’ 하는 아쉬움이 늘 남습니다.

물론 기반 지식을 쌓는 건 중요하지만, 혹시 실제 해결 단계로 들어가는 데 막연한 부담감이나 두려움 때문에 상대적으로 편한 학습에 머무르고 있었던 건 아닐까, 스스로 의문이 들었습니다.

혹시 멘토님도 예전에 비슷한 경험이 있으셨는지, 그리고 이런 스타일은 개선이 필요한 부분인지 궁금합니다. 좀 더 저돌적으로 코딩을 시작해보는 연습이 필요한 걸까요?

같은 맥락에서, 멘토님은 시간이 촉박한 과제를 진행하실 때 관련 개념 학습과 구현 사이의 균형을 어떻게 잡으시는지도 듣고 싶습니다. 먼저 손을 움직여 보면서 감을 잡는 식으로 가시는지, 아니면 기본을 먼저 정리하고 시작하시는지도요. 효율적인 실행 루틴이나 판단 기준이 있다면 조언 부탁드립니다.

과제 피드백

Q. 시간이 촉박한 과제를 진행하실 때 관련 개념 학습과 구현 사이의 균형을 어떻게 잡으시는지도 듣고 싶습니다.

A. 의근님 저는 의근님의 방법이 틀리다고는 생각하지 않아요.사실 지금과 같은 학습을 위한 과제의 경우 학습을 먼저 충분히 하는 것은 당연히 권장하는 방법인것 같습니다. 하지만 회사 과제의 경우는 다를 수 있을 것 같아요. 회사는 정해진 일정이 있고 그안에서 학습과 과제를 완수해야하는 것이 필수 이니까요. 이것은 어떻게 보면 일정관리라고 생각해요. 저도 당연히 주니어 초빈에는 학습비용이 많이 들었어요. 어떤때는 과제를 제때 해내지 못했던 적도 있고요. 도전적인 과제를 정해진 시간에 못하는 경우는 많았습니다. 시니어때도 있었죠. 다만 이것을 어떻게 풀어가느냐가 중요한 것 같습니다. 예를들어 프로젝트를 진행하다보면 학습비용이 커서 "아 이건 일정내에 해내기 힘들겠는데?" 싶은 상황이 오면 미리 공유하고 일정을 확보할 수 있는지 확인해볼 수 있을 것 같아요. 반면 마감일 막판에 일정조정 요청을 하는 것은 피해야하죠.

과제 구현에 있어서는 일단 세가지 원칙을 지키면 어떨까 싶어요. 첫번째 일단 구현해봅니다. 구현하면서 코드는 엉망 진창일 수 있지만 일단 구현하려는 대상을 학습하면서 돌아가게는 만듭니다. 두번째는 코드 리팩토링단계에요. 그냥 굴러가는게 아니라 잘 굴러가게 만드는 것이죠. 코드도 깔끔하게 정리하면서요. 세번째는 빠르게 만듭니다. 성능적인 면까지 고려해서 좀 더 빠르거나 UX가 좋게 만들 수 있는 지를 살펴 보는 것이죠.

이렇게 단계별로 진행하면 구현된 코드를 계속 만들어가기 때문에 불안함이 줄어들 수 있습니다!