6주차 데일리 개인 회고

12월 13일 월요일

대성

• 사실
  • 나경이와 영상 제작을 걸고 5꽉의 혈전을 치뤘다.. 마치 복싱 경기가 끝난 것처럼 서로 피투성이였지만 좋은 승부를 했다는 것에 벅차올랐다..!
  • 튜토리얼 기능을 추가하는데 생각보다 고통받았지만 또 나름의 수확이 있었다.
• 생각 & 감정
  • 기존 코드 위에 기능 추가를 할 때 어떤 식으로 해야하는가에 대한 고민을 했다. 많은 컴포넌트에 관여하는 전역변수를 수정/변경을 하고 기존의 컴포넌트는 재사용을 해야하는 상황에서 어떤 식으로 해야하는가였다. 현재 구현에서 최초의 접근 방식은 모든 전역 상태의 뿌리를 거의 똑같지만 살짝 불순한 녀석으로 갈아끼워주고 url에 대한 처리와 튜토리얼에 관한 상태를 추가하는 식이었다. 하지만 아무리 같은 인터페이스를 가져도 핵심 데이터를 갈아 끼워넣는 것 자체가 너무 사이드 이펙트를 발생시킨다는 피드백을 받았다. 이를 해결하기 위해 기본적인 제안으로는 튜토리얼만을 위한 전역상태와 페이지를 별도로 구성하자는 것이였고 페이지를 구성하는 컴포넌트들은 재사용하자라는 것이었다. 그러기 위한 방안으로는 import, export를 동적으로 하는 것, 부모 컴포넌트에서 import하고 자식 컴포넌트에서 export 하기, jotai provider를 사용하기 등 여러가지가 나왔지만 동적 import는 고려해야할 점이 많고 사용 목적이 잘 맞지 않았고 나머지는 자식이 어떤 부모를 import할 지 정해야한다는 점에서 강한 의존성이 생긴다는 것이다. 이것 저것 이야기를 하다가 애초에 context api를 썼다면 이런 문제가 없지 않았을까라는 생각을 했지만 렌더링을 최소화 하겠다는 목적에는 아무래도 필요하다라는 결론을 내릴때 쯤 context api를 이용해서 atom을 전달하면 되지 않을까라는 아이디어가 나왔다. atom자체는 불변하기 때문에 훅을 통해 동적으로 전달해주자라는 것이다. 납득도 되고 두마리 토끼도 잡은 느낌이지만 뭔가 깨름칙한 느낌이 남기는 했다.
  • 팀원의 코드 위에 내 코드를 얹는다는 것은 쉽지 않다. 수정을 할 것이면 모든 것을 고쳐야되고 그렇지 않다면 그 코드를 추상화해야한다. 추상화 후 다시 내 코드가 필요없어져도 추상화의 흔적은 남기고 내 코드의 삭제는 수월해야한다.
  • 아주 잠깐 빗소리를 들을 수 있어 좋았다.
• 피드백