8월 21일 (수) 회고 - dev-FEFIVE/NadoCat GitHub Wiki

각자 자유로운 형식으로 작성해주세요.

로그인/회원가입 제외한 대부분의 페이지에서 ensureAutorization가 필요한데, 이 함수는 jwt 토큰을 검증하는 역할을 한다.
Token과 UUID를 zustand를 통해 저장해서 계속 들고 다니게 할 예정이다. zustand를 사용해 저장하는 방법에 대해 다시 복습해야겠다.
refresh token이 있다면 access token이 재발급되게 하고싶은데 어떻게 해야할까?

이제서야 본격적으로 클라이언트 측 작업에 들어간다. 늦게 들어간 만큼, 팀원들의 작업 내용을 많이 참조하면서 진행하고 있다. 리액트 쿼리의 러닝 커브를 고려하지 못한 점이 아쉽다. 체득을 위해 한 번 더 복습이 필요할 것 같다.

평소처럼 upsteam 데이터를 merge 하는데 Merge made by the 'ort' strategy.라는 것을 갑자기 눈에 보였다. "recursive" 병합 전략을 최적화한 방식이라는데 프로젝트가 끝나면 한번 찾아봐야겠다.
S3로 이미지 업로드하는 것을 처음 해봤다. 팀원이 만들어준 함수를 가져다 사용한 게 전부이지만 이미지 때문에 백엔드 코드를 수정해야 해야 했고 프론트에서도 백엔드로 데이터를 보내는 방법도 조금 달랐다. 방법을 찾아보니 예전에 해봤는데 내가 기억을 못 한 거다. 프로젝트 끝나면 관련 내용을 정리해 봐야겠다.
게시글 수정 기능을 만드는데 정말 너무 헷갈렸다. 변경되는 데이터만 고려하려니 너무 복잡했다. 특히 DB에서 삭제되는 태그, 추가되는 태그, 유지되는 태그 이걸 구분하는 게 너무 복잡했다. 이미지도 같았다. 구현해야 할 사항을 하나하나 적어보니 어느 정도 구현 방식이 생각났고 구현 사항에 알맞게 코드를 구현할 수 있었다. 역시 요구사항 분석 및 설계는 정말 중요하다.

Prisma를 사용해 데이터를 가져올 때 리턴값이 지저분했는데 이걸 늦게 체감한 게 아쉽다. 데이터 변환이 필요할 때마다 해당 컴포넌트에서 변환했는데 별로 보기에 좋지도 않고 지저분해 보였다. 데이터 처리는 최소한 서비스 로직에서, 혹은 쿼리문으로 데이터를 가져오는 레이어에서 진행하는 게 가장 깔끔한 것 같다.
위 내용과 이어진다. 결론적으로 다른 팀원분이 만들어주신 공용 컴포넌트를 사용할 때도 문제가 발생했다. 리턴된 데이터 형태가 달라서 이걸 맞춰준다고 interface type과 씨름을 했다... 뒤늦게 든 생각이지만 데이터 리턴하는 방식에 통일감을 주면 좋았을 것 같다.
타입! Typescript를 사용하면서 타입 관련 에러를 정말 많이 본 하루였다. 처음에는 당황스러웠는데 계속해서 비슷한 메세지를 보니 점점 익숙해지는 것 같다. 좀 더 일찍 익숙해졌다면 interface를 더 깔끔하게 선언할 수 있었을 것 같다.