세번째 프로젝트를 마치고

미리 캔버스에서 지난번에 사용한 템플릿을 못찾아서 대충 비슷하게 만들어따

 

 

지난 포스팅 두번째 프로젝트 회고 말미에 언급한 세미 프로젝트 회고이다.

이제 진짜 내일부터 최종 프로젝트 기간이라 후딱 회고 작성하려고 한다. 

 

코드잇 부트캠프에서 진행하는 정식 프로젝트는 아니지만 세번째는 세번째니까..

 

서비스 소개 : 나만의 링크를 저장하고 공유하는 서비스 입니다. 
프로젝트 기간 : 2024.11.06 - 2024.11.20

[깃허브](https://github.com/codeit9-temporary/linkbrary)
[배포 링크](https://linkbrary-9-99.vercel.app/)

[노션](https://nickel-vegetarian-de0.notion.site/Linkbrary-135f52d774a880c8ba19f7c043a4b1c0?pvs=74)

Linkbrary

깃허브 프로필에 그동안 했던 프로젝트 배포한 사이트 엮어서 프로젝트 구경하기 심어놓았다 😁 

 

주요 기능
1. 유저 기능, 소셜 간편 로그인
2. 폴더 별 링크 관리 
3. 나의 폴더 공유하기   

 

기술 스택 : Next.js v.15 Page Router, 타입스크립트 v.5, 리액트 v.18

CSS : 테일윈드 

Next.js 

- httpOnly 쿠키 사용 

 

패키지 및 라이브러리
- Zustand - 전역 상태 관리 
- 리액트 쿼리 - 데이터 fetch, 캐싱

---

- 내가 기여한 점 & 새롭게 배운 점

1. 서비스 전반에 걸친 모달을 zustand로 구현했다.

모달을 통해 대부분의 api 요청이 이루어지기 때문에 

지난 플젝에서는 jotai를 이용해 모달 상태를 전역적으로 관리했지만 내가 그 로직을 제대로 이해 못했기에..

이 블로그에서 도움을 많이 받았다.

 

2. 요청 성공/실패 여부를 유저에게 보여주기 위해 react-hot-toast를 사용해 토스트를 띄워줬다. 

프록시에서 try catch문으로 에러를 처리했을때 클라이언트에서는 밑에서 에러가 났는지 모르기때문에 

반드시 상위 (클라이언트)로 throw 해줘야 한다는 것을 깨달았다.

비슷하게, api 요청이 실패했는데 프록시에서 대충 뭉뚱그려 처리하면 클라이언트에서는 제대로 된 에러 코드를 확인 못하는 경우가 발생한다.

- 아쉬운 점

KTP회고에서 공통적으로 나온 이야기를 적어보자면 ..

 

짧은 기간 짬내서 한 프로젝트라 기능 구현에 급급해 성능 최적화에 신경쓰지 못한 점 

일부 페이지에 기능이 몰려서 업무 분장이 적절하지 못했다 

후반부에 PR 리뷰하는 시간이 줄어들었다. 

 

... 등 몇 개의 아쉬운 점이 있긴 하지만 모든 팀원이 적극적으로 임하고, 이슈 해결에 다함께 동참하는 팀워크를 보여주었다 

- 지난 프로젝트에서 아쉬운 부분 개선점 적용

브랜치 전략 : 1 feature 1 branch

브랜치의 목적이 잘 나타나고 PR을 잘게 쪼갤 수 있어 좋은 전략같다.

 

일정 관리 

깃허브 프로젝트 로드맵 기능으로 각 이슈 별로 작업 기간을 기록했다.

팀원 별로 전체 작업 현황이 어떻게 되고있는지 파악하기 좋아서 매우 유용했다.

앞으로의 프로젝트에서 일정을 미리 산출하기 위해 참조가 많이 될것같다.

다음 프로젝트에서 개선할 부분 

스토리북을 사용하기로 했다. -> test 페이지같은거 안만들어두댐! 

앱라우터 사용 & 서버 컴포넌트 제대로 사용하기