이번에 팀원 분들 모두 컴포넌트의 단위와 컴포넌트 별 상태관리와 결합도를 낮추기 위해 고민을 많이 하신 것 같고, 지난번 보다 팀원 분들 끼리 하신 코드 리뷰 질도 더 좋아진게 느껴져서 제가 코멘트할 부분이 없다고 느껴질 정도였는데요!ㅎㅎㅎ
코드를 읽으며 공통적으로 고민해보고 적용해보면 좋을 것 같은 부분들이 있어서 이렇게 남겨볼게요!
🗂️ 프로젝트 디렉토리의 구조 잡기
현재 작업해주신 파일을 보았을 때, 어떤 분은 root에 모든 파일이 위치하고 있고, 어떤 분은 index.html과 스타일 코드는 root에 다른 컴포넌트 파일은 src/안에 위치시키기도 하고 각자가 다른 방식으로 파일을 위치시키고 있는데요.
현재는 todoList, todoForm, todoCount 등 몇개 밖에 안되는 컴포넌트가 있어서 파일을 찾고 수정하는데 어렵지 않지만, 만약 여러 사람이 한 프로젝트를 하게 되어 100개가 넘는 컴포넌트를 src/ 밑에 위치시키고 개발한다면 내가 만들고자 하는 컴포넌트가 이미 있는지 찾는 것도 어렵고, 그걸 재사용하고 유지보수하는 것도 굉장히 어려운 일이 될 것 같아요.
그렇기 때문에 이 프로젝트의 개발을 더 효율적으로 하기 위해 디렉토리 구조를 설계하는 것 또한 프로젝트 시작 단계에서 중요한 일인데요.코드와 마찬가지로 폴더 구조 또한 정해진 정답은 없기 때문에 다른 사람들은 어떻게 프로젝트 폴더 구조를 설계하는지도 찾아보시고, 어떤 이유로 어떻게 설계했는지 보시면 좋을 것 같아요.
그러고나서 본인이 생각했을 때 어떤 형태가 효율적일 것 같은지 현재의 프로젝트에 적용해보시면 좋을 것 같아요. (개발하다가 마음에 안들면 디렉토리 구조를 다 갈아 엎기도 하지만 프로젝트가 커질수록 돌이키기가 더더욱 어려운 일인 것 같아요. 처음부터 잘하자(?)ㅋㅋㅋ)
리액트 파일 구조 관련 글도 한번 참고차 공유드릴게요.
🗃️ 컴포넌트 분리와 추상화
작성해주신 코드를 보았을 때, 컴포넌트라는 관점에서 공통된 Core를 추상화를 통해 일관된 방식으로 관리될 수 있도록 설계해보고 현재의 코드를 개선할 수 있을 것 같아요.
제가 설명드리는 것보다 코드로 잘 설명된 글이 있어서 아래에 남겨드릴게요!이 부분 한번씩 읽어보시고 이해가 안 되신다면 다시 이야기 해봐도 좋을 것 같아요~
⚠ 결합도(의존성)를 낮추는 방법
이번에 PR에 질문에 많이 작성해주셨던 부분이
현재 컴포넌트들 끼리 의존도가 괜찮게 작성되어져 있나요? 이었던 것 같아요.그런 측면에서 현재는 todoList, todoCount, todoForm 등이 외부(App.js)에서 주입하는 action들이 많아질 수록 결합도는 올라가고 복잡성 또한 높아질 것으로 보여요.
그렇기 때문에 가능하다면 todoCount와 가까운 곳 혹은 todoCount 내부에서 count와 관련된 동작이 이루어 지는 것이 좋다고 생각 되는데요.이를 해결하기 위해 아래와 같이 코드를 변경해볼 수 있을 것 같아요.
as-is ) Todo 변경이 되었을 때 변경 시키는 곳에서, 변경되어야 할 컴포넌트의 render 함수를 호출해 리렌더링
to-be ) Todo 변경이 되었을 때 변경된 것을 알고 스스로 리렌더링customEvent, Pub-Sub 디자인 패턴, 옵저버 패턴 등의 방법이 있는데 키워드만 우선 남겨드릴테니 한번 직접 공부해서 적용해보시면 좋을 것 같아요~찾아봤지만 잘 모르겠다 하시면 말씀해주세요 다같이 티타임에 다시 이야기해봐요~
보너스(알아두면 좋지만 아직 중요하지 않은 것)🌟 사용자 경험(UX)에 대한 고민
저번 티타임 때 제가 코드리뷰를 하며 과제와 큰 연관이 없으면 코멘트를 달다가 지운다고 했던 것중에 하나가 사용자 경험에 대한 내용들인데요.
나중에 프로덕트 FE 개발자로 일하게 된다면 사용자 관점에서 많은 고민을 하면서 개발을 하시게 될 텐데 그런 측면에서 아예 언급하지 않는 것 보다 천천히 고민해보시면 좋을 것 같아 쓰윽 남겨볼게요.
이번 과제에서 예시로 들 만한 것들은 validation error와 에러 메시지 일 것 같아요.현재는 대부분 에러가 발생하면 Throw가 발생하면서 state 추가가 되지 않도록 되어있는걸로 보이는데요.하지만 유저 관점에서 서비스를 이용하면서 submit을 눌렀는데 아무일도 발생하지 않는다면 유저는 자기 잘못이 아닌 “서비스가 장애가 났다“, “이 서비스 개발 진짜 잘 못했다” 라고 생각할 것 같아요.
그렇기 때문에 유저의 잘못이 어떤 것인지 정확한 에러메시지를 전달하고 그 다음에 제대로된 액션을 유도해주는게 프로덕트 개발자로서 중요한 부분 중 하나라고 생각해요.
예시로, 유저가 2자 이상 입력해야 submit이 가능한 상황에 1글자만 입력하고 submit을 했다면, 아무 반응을 안하는 것 보다, “2글자 이상 입력해주세요” 라는 메시지와 함께 input의 테두리가 빨개지며 다시 input에 focus를 해줄 수 있을 것 같아요.
지금 이렇게 반영하셔야하는 부분은 아니고 앞으로 팀 프로젝트나 사이드 프로젝트 등 개발하실때도 계속해서 고민해보시면 좋을 것 같은 포인트라 언급만 드립니닷!
🤩 <script /> 에 대해
index.html에 <script />를 추가할 때 script 위치에 따른 성능 차이가 있어요.
추가적으로 script에 있는 defer와 async 속성에 대해 알아두시면 좋을 것 같아요
