Portfolio

본인이 맡은 일

2주차는 UI 개발을 마무리하고, 기능을 50% 이상 붙이는 것에 집중하기로 했다.

이번 주 수요일에는 영상을 제출해야 했어서, 기능은 제대로 붙이지 않더라도 데모를 보여줄 수 있는 UI 개발부터 완료할 수 있도록 일정을 잡았다.

팀장으로서 팀 리딩 및 매 스프린트, 스크럼 시간 회의 진행

로그인, 회원가입 페이지 개발

UI 개발 완료
로그인, 회원가입 기능 개발 및 API 연결
rtk 를 통한 로그인, 회원가입 input form state 관리
로그인, 회원가입에 따른 auth token 관리 기능 개발

Intersection Observer 를 사용하여 무한 스크롤 hook 개발

main branch merge 과정에서 발생하는 conflict 해결

프로젝트 1일 1배포

기술적으로 고민한 부분

Type 이름에 대한 고민

우리는 Type 이름을 정의할 때, UserType, PostType 이런식으로 Model 이름 뒤에 Type 을 suffix 로 붙여 사용하고 있는데, 타입 이름이 불필요하게 너무 길어지는 것 같다.

그리고, API request, response 타입 이름에는 앞에 Request, Response 를 붙이기로 했는데, 이렇게 하다보니 RequestAuthUserType 같이 타입 이름이 너무 과하게… 길어져서 오히려 가독성이 떨어지는 것 같았다. API rq, rs 타입 이름에 대한 컨벤션이 있는지 궁금

그리고 API response 가 Model Type 과 동일한 경우에도 response 용 타입을 또 만들어주어야 할까..?

rtk 에서 꼭 state 관리를 해야하는지에 대한 고민

회원가입 페이지의 input form 의 value 들을 원래는 useState 와 useEffect 만으로 관리하고 있었음

그런데, 멘토님께서 다음과 같은 경우, 전역 상태 관리를 사용한다고 조언해주심

새로고침을 해도 유지되어야 하는 상태

API로 가져오는 상태

다양한 상태에 영향을 끼치는 상태

→ input form value 들은 “새로고침을 해도 유지되어야 하는 상태”라고 생각해서 rtk store 에서 관리할 수 있도록 했음.

근데, 그냥 읽기, 쓰기 기능만 사용하고 있는 것 같았음

예를 들어 회원가입 페이지에서 사용하는 useSignupForm hook 을 다음과 같이 짰는데,

signupFormValues 를 selector 로 가져오고,
formValue 가 변경될때마다 store 에 있는 해당 state 를 변경

이 이외에는 굳이 store 를 사용해야할 필요가 없는 것 같아서 이런 방식이 맞는지 고민중…

hook 을 잘 만들기

hook 을 좀 잘 만들어서 쓰고 싶다. 보통 현업에서는 자주 사용되는 hook 들은 그냥 라이브러리를 쓴다고 한다.

특히 form 같은 경우는 useForm 이 국룰… 이라 하는데, 아무래도 이번 팀 프로젝트의 공통 팀 목표는 “기술적 성장”에 초점을 맞추는 것이기 때문에, 공통으로 쓰이는 hook 들은 최대한 우리가 만들어 사용하고자 했다.

하지만 처음으로 공용 hook 을 만들다보니, 계속 구멍이나 수정사항들이 생겨났다.

→ 예를 들어 useInput 을 만들어 input 들을 관리하면, input 이 여러개이고 그것들을 한 번에 관리해야하는 경우, 매번 hook 을 만들어 사용해주어야 하기 때문에 코드 길이가 늘어나고, 성능상으로도 적합하지 않았다.

이 부분은 정말 어쩔 수가 없는 것 같다. 처음부터 버그가 없는 hook 을 만들려고 노력하되, 계속 구멍과 수정사항들을 경험해 나가면서 나만의 hook 을 만드는 조건을 확립해나가야할 것 같다.

재사용 가능한 컴포넌트보다는, 확장성 있는 컴포넌트 만들기

사실 이 부분은 요즘 많이 와닿음.

멘토님께서도 children 뚫어놓는게 훨씬 도움된다 하심

이슈 트래킹

package-lock.json

팀장으로서 매일 배포를 관리하면서, 가장 많이 생긴 conflict 는 package-lock.json 에서 발생한 충돌이였다. 이것때문에 진짜 골머리를 썩혔다. package-lock.json 파일의 충돌을 수정해도, 팀원들의 PR 을 보면 계속 해당 파일 변경사항이 생겨났다.

이 부분에 대해 멘토님께 여쭤보니, 팀원들의 로컬 node version 이 달라서 생긴 문제라는 것을 알게 되었다.

그래서 팀원들에게 nvmrc 도입을 건의했고, 현재는 nvmrc 파일을 추가해서 로컬 node version 까지 맞춰 사용하고 있다.

api 폴더 구조의 비효율성

api 를 사용하는 페이지에 맞춰ㅓㅅ

양혜진