메인 프로젝트 회고

좀 더 나은 세상, 봉사활동 플랫폼

github
배포 링크

메인 프로젝트때는 프리때보다 모든걸 더 신경써서 했던 것 같다. 프리 회고때도 썼지만 부족했던 문서화, 소통 등을 개선하려 정말 많이 노력했다.

문서화 및 소통

기획때 나서서 강조했던 부분은 문서화와 소통이었다.
프리 프로젝트때 API 명세서가 없어 정말 많이 고생했던 경험을 나누면서, API 명세서를 꼭 만들어 주셨으면 좋겠다고 말씀드렸고 포스트맨으로 받을 수 있었다. 사실 당연한건데, 연습 개념이었던 프로젝트라서 그만큼 당연한 문서화 시킬 생각을 못했고 그래서 고생했을수도 있다.

원활한 소통을 위해 프론트엔드 팀은 항상 ZEP 스페이스에 모여서 각자 코딩을 했다. 모르는게 생기면 옆에 가서 찌르면 즉각 응답을 받을수 있었고, 여기서 같이 서로의 에러도 해결하고 빠른 소통이 가능해서 정말 좋았다.

나중에는 백엔드분들도 빠른 소통을 위해 들어와 계시기도 했고, 디스코드 응답도 다들 빨라서 문제가 생길때마다 빠른 수정을 받을 수 있었다. 메인 팀에서 가장 좋았던건 다들 소통이 아주 잘 됐다는것!

잘했던 점

타입스크립트로 진행 성공

팀원 두분이 타입스크립트를 아예 써본적도 공부한적도 없는 상태셔서 처음 말씀드렸을때 완성을 시킬수 있을까에 대한 걱정을 하셨었다.
하지만 이유를 들어 제안을 드렸고 승낙해 주셔서 결과적으로 프로젝트가 잘 완성되어 뿌듯했다.

리팩토링 진행

하드코딩 되어 있는 코드를 보면 팀원분께 이런식으로 수정해도 되겠는지 양해를 구하고 리팩토링을 진행했다. 또 중간중간 팀원분들이 작업하신 코드에서 작업을 해야 할 때 조금 더 효율적으로 할 수 있는 방법이 보이면 먼저 양해를 구하고 수정했다.
하지만 이 부분은 아쉬웠던 부분에도 가장 크게 해당하기 때문에 아쉬웠던 점에 적도록 하겠다.

에러 해결 과정을 꾸준히 기록했다.

서버와 통신하는 과정, 카카오와 연동하는 과정에서도 수많은 에러를 만났는데 꾸준히 기록했다. 에러를 새벽 2시에 해결했는데 블로깅을 하느라 4시에 잔 적도 있었다..

하지만 바로바로 기록해두는게 까먹지도 않고 나중에 같은 문제를 만났을 때 도움이 된다는걸 이미 많이 겪어봐서 잘했던 점이라고 생각한다.

아쉬웠던 점

문서화는 잘 되었지만 가장 아쉬웠던 점은 바로 코드리뷰 를 진행하지 않은 점이다.
프리때 코드리뷰를 하기로 했었는데 PR을 올려도 확인을 안하고 그냥 머지 하라고 했었기 때문에 메인때는 꼭 하고 싶었는데 결국 메인때도 못했다.

다양한 이유가 있었지만 메인때는 멘토가 배정되어서 다른팀은 멘토분이 코드리뷰를 해주고 계셨기 때문에 우리팀도 해당되는 줄 알았는데, 알고보니 코드리뷰를 지양한다는 지침이 있었다고 한다.(이유는 모르겠음)

우리끼리라도 코드리뷰를 했어야 했는데 처음부터 하질 않다보니 자연스럽게 각자 작업물을 바로 머지하게 됐고 (ㅠㅠ) 같은 동기고 같이 배우는 입장이지만 조금더 나은 방법이나 틀린 부분에 대한 부분을 서로 이야기 나누면서 바로잡기 어려웠다.

그래서 리팩토링을 진행할때에도 코드리뷰를 했었다면 이쪽 부분의 설계는 처음부터 이렇게 하는게 좋겠다고 서로 의견을 나눴을텐데 라는 생각이 들면서 정말 아쉬웠다..

다음에 또 팀프로젝트를 할 기회가 있다면, 코드리뷰는 필수적으로 나서서 주장해야겠다고 느꼈다.

---

메인도 끝!

기술 발표때 react-hook-form 을 사용해 사이트 전체 form을 관리한 부분에 대해 발표했다. 왜 이 라이브러리였는지, 또 비제어컴포넌트와 제어 컴포넌트의 차이는 무엇인지 등에 대해서 안그래도 꼭 정리해보고 싶었는데 발표를 계기로 더 확실히 공부가 되어서 좋았다. :)

결과적으로 팀원분들과 소통도 잘 되고 누구하나 빠짐없이 열심히 했던 프로젝트라서 더 애착이 간다. 그리고 제출했다고 끝이 아니라 지속적으로 서비스를 리팩토링 하고 유지해보기로 했기 때문에, 틈틈이 기능을 추가하거나 디자인도 더 예쁘게 수정해보고 싶다.