PetTalk 프로젝트를 되돌아보며

드디어 끝날 것 같지 않던 1차 팀 프로젝트가 끝이 났다!
이번 프로젝트가 나에게 어떤 의미로 남게 될지 의식적으로 확인하면서 진행하려다 보니 정말 많은 것들을 깨닫고 얻은것 같다.

기술적인 성장

React Query와 친해지다

사실 지금까지 React Query가 대충 어떻게 돌아가는구만~ 이런 느낌으로만 알고 제대로 사용해보지는 않았다. 그렇게 프로젝트를 진행했던 것들이 너무너무 아쉬워서, 이번에는 React DevTools를 적극적으로 이용해서 QueryKey를 꼼꼼히 설계하고 작동하도록 했다.

제대로 React Query를 사용해보니, 정말 정말 개발을 편리하게 해 주며 UX를 개선할 수 있는 획기적인 라이브러리라는 것을 깨닫게 되었다! 🤓 서버의 상태가 달라지는 것을 알아서 확인해 필요하면 refetch를 진행해주고, 변한 게 없다면 그대로 데이터를 캐싱해줘 성능까지 좋게 만들어주는 효자가 어디있나... 실제로 React Query를 쓰니까, 전역상태를 관리하던 것이 엄청나게 줄어든 게 실감되어 개발할 때에도 훨씬 편리했던 것 같다.

상태관리 툴 Jotai 발견!

항상 개발할 때 recoil 을 고수했다. 그래서 마찬가지로 이번에도 recoil을 사용하여 개발하려고 하였는데, 멘토님께서
"recoil 대신에 jotai를 사용해 보는 것이 어떨까!!" 라고 제안하셔서, 이번 기회에 한번 사용해보았다.👻

왜 Jotai를 사용했냐고 물어본다 하믄...
1. 훨씬 가벼움 (번들 크기가 더 작음)
2. 점점 더 활발해지고 있는 Jotai 네트워킹
3. recoil의 포맷을 크게 벗어나지 않는 함수형 프로그래밍 방식 (진입 장벽 낮음)

meta...너를 믿었건만...

(20231004 기준)
npm publish 주기만 봐도, recoil이 이제 관리가 소홀해지고 있는게 느껴진다...
후기는, 정말 정말 가볍고 간편해서 client 상태 관리를 유연하게 관리할 수 있었고, 무엇보다 정말 중요한 점인데 팀원들도 어려움 없이 같이 사용했다는 점이다. 아쉬웠던 것은 .. 한글 번역본이 아직은 많이 존재하지 않다는 점이다. 워낙 최신 라이브러리라 그런건지! 그래도 코드 보면 이해가 쏙쏙 되어서 크게 어렵지는 않았다.

아쉬웠던 점

랜더링 순서를 고려하자

React에 대해서 알 만큼 정말 잘 알고 있다고 생각했는데, 아직도 부족한 점이 있다고 항상 느낀다. 되돌아 볼때마다 더 더 그런 생각이 드는 것 같다. 내가 잘 개발했다고 생각한 부분들이 QA때 다양한 case들에서 터지는 것을 보면서 느꼈다. useEffect 와 불필요한 state 들은 남발하고 있지는 않은지. 그리고 또 언제 query의 refetch 가 일어나는지 꼼꼼히 학습해야 하는 필요성이 남아있는 것 같다.

11월 말부터 React 공식문서를 꼼꼼히 파면서 여러가지 실험을 하고 아토믹한 컴포넌트를 미리 만들어보려는 연습을 하려고 한다.
이 때, 같이 내 개인 블로그도 NextJs로 만들어보는 개인 플젝을 진행하려고 하는데 NextJs와는 어떤 차이가 있는지도 비교해보면 정말 재미있는 플젝이 될 거 같아서 왕 기대중이다.

컨벤션에 대하여

이번 플젝을 하면서 eslint 가 어떤 역할을 하고, 어떻게 구동되는지 꼼꼼하게 체크할 수 있었다. 아무래도 팀원들과 모여 머리를 다같이 맞대고 우리가 허용해야 할 컨벤션과 아닌 것을 체크해보는 과정에서 확인할 수 있어서 재미있었다.

하지만 한가지 간과한 것이 있었는데, 함수명과 변수명 등에 대한 통일이다.
팀원들끼리 일관성 있는 코드를 작성하기 위해서는 이에 대해서 미리 필히 논의해봤어야 하는데, 그러한 점을 꼼꼼히 신경쓰지 못한 것이 많이 아쉬웠던 것 같다.

일관적인 코드를 작성하는 것은 매우 어렵다. 특히, 여러 사람이 될 수록 더 그런 것 같다. 그럴 때일수록 규칙을 빡빡하게 만드록 서로서로 코드리뷰할 때 그만큼 더 신경써줘야 한다.

협업에 대하여

코드 리뷰는 항상 어렵다. 어려운게 끝은 아님

처음에는 팀원들 코드 하나하나 동작 원리를 뜯어보고 확인하면서 리뷰를 남겼는데, 프로젝트 후반부로 갈수록 기능 구현에 급급해서 PR올라온 것에 오류가 없거나 충돌이 없으면 바로 머지했던 것 같다. 이런 나의 모습이 아쉬워서 내가 나름대로 세운 코드 리뷰의 법칙을 공유해보고자 한다!

1. 일관성 있는 코드를 작성했는지?
   우리가 지킨 규칙이 있을 것이다. 작게로는 변수명 컨벤션, 함수명 컨벤션을 지켰는지. 그리고 함수는 맨 상단에 쓸 건지 아래에 쓸 건지...
   크게 본다면 우리가 사용하기로 한 기술 스택의 범위에서 벗어나는 코드를 작성한 것이 없는지, 폴더나 파일의 위치와 구조는 올바른지까지도 확인할 수 있다.

2. 불필요한 코드가 중복되어 있지는 않은지?
   console 을 출력하는 코드나, 사용하지 않는 state나, 아무런 값도 반환하지 않는 void 함수를 남발하는 경우 팀원이 확인해줄 수 있다.

3. 서비스의 성능을 떨어트릴만한 요소가 있는지?
   지나치게 많이 랜더링을 한다든지 컴포넌트간의 의존성을 크게 높이는 코드를 방지할 수 있도록 확인해야 한다. 내가 만든 컴포넌트를 다른 사람도 이용할 수 있게끔 확장성을 고려하여 만드는 것이 협업에 있어 매우 중요하기 때문이다.

이렇게 3가지 경우만 고려해도 코드리뷰의 반 이상은 성공한다고 생각한다! 그렇기 때문에 초심을 생각해 이 세가지 체크리스트는 항상 마음속에 가지고 다니자.

나의 PR 작성 태도

내가 작성한 컴포넌트, 기능에 대하여 팀원들이 알아보기 쉽도록 사용 설명서처럼 적는 PR도 있고, 어떤 원리로 만들었는지 설명을 최대한 많이 적을 수 있도록 노력했었던 것 같다.

특히 이번 PetTalk 프로젝트는 자신이 만든 아토믹한 컴포넌트를 다른 팀원들이 이용해야 하는 경우가 많았기 때문에, 더 더 노력했었다.

확실히 그동안 했던 다른 프로젝트들보다 더욱 상세한 설명을 작성하려고 했었고, 팀원들이 참고해야 하는 사항을 꼼꼼히 체크하니 나도 나의 작업을 되돌아볼 때 명료하게 확인할 수 있어 훨씬 좋았다.

오프라인으로 만나 함께하기

오프라인으로 만나 각자 오늘 할 작업 분량에 대해 짧게 브리핑하고, 집중하여 개발을 진행하면서 모르는 것을 바로바로 물어보니 온라인으로만 개발하는 것보다 훨씬 빠르게 피쳐 개발을 할 수 있었다.
팀 프로젝트를 할 때 서로 비동기적으로만 소통하니까 불편한 점이 많았었는데, 매일 만나 프로젝트에 대해 이야기하니 서로가 하고 있는 작업에 대해 충분히 이해할 수 있어서 좋았다.

솔직함

내가 할 수 있는 것과 할 수 없는 것에 대해 솔직히 이야기하며, 한계에 마주하였을 때 이를 다른 사람에게 솔직히 이야기하는 것은 매우매우 어려운 일이라고 생각한다. 하지만, 협업을 할 때에는 이 어려운 일을 해야 할 때가 많다.

팀원들끼리 솔직하게 모르는 것은 모른다. 힘들다면 힘들다!라고 이야기하는 것이 어려운 분위기가 만들어지면 어떡하나...라고 걱정을 많이 했었는데,
팀원들이 진솔하게 프로젝트에 임해주고, 모르는 것은 바로 질문하여 해결하는 모습을 많이 보여줘서 서로의 상황이나 실력에 대해 훨씬 더 잘 이해할 수 있어 갈등 없이 프로젝트를 마무리할 수 있었던 것 같다. 😄

이번 프로젝트가 나에게 어떤 의미로 남게 되었는지 확인하고 이를 되짚는 과정은 매우 중요하다고 생각한다. 의미 없는 프로젝트들만 포폴에 쌓아올리는 대학생이 되지 말자!!! 😧

펫톡 보러가기 => https://github.com/prgrms-fe-devcourse/FEDC4_PETTALK_Yrnana.git