최희라
Keep
- 공통 컴포넌트를 분리하여 미리 만들어놓고 사용하는 개발 경험
- 코드 리뷰를 하며 직접 개발하지 않은 부분이 어떻게 구현되었는지 살필 수 있고, 리뷰를 받으며 미처 생각하지 못한 개선점을 알고 고칠 수 있었던 경험
- 사용해보지 않은 git 명령어 사용이 익숙해진 경험
Problem
- 사용한 라이브러리를 제대로 공부하지 않아서 에러를 만났을 때 원인 파악이 어려웠던 점
- 기한을 정해놓고 정해진 기한 내에 개발하는 일정 관리가 미흡했고 배포 후 기능 테스트 시간을 충분히 갖지 못한 점
Try
- React, Tanstack Query, 컴포넌트 재사용성을 높일 수 있는 합성 컴포넌트에 대해 공부해보기
- 수시로 기록하기
- 구현 많이해보기
신준혁
Keep
- React와 React Query 공부
- Tailwind를 많이 공부한 부분
- git에 대해 더 많이 알게 된 부분
Problem
- 어떤 일을 할 때 계획이나 예외처리에 대한 생각을 잘 하지못해 추후 버그가 일어난 부분
- React Query에 대한 지식이 부족해 시간을 소모한 부분
- 프로젝트 진행하면서 시간이 촉박했던 부분
Try
- 계획을 꼼꼼히하자
- React Query를 다시 한번 공부하자.
- 개인적으로 프로젝트를 한 번 더 해보자
안범
Keep
- git rebase 등 git 활용 능력 키우기
- React Router Dom의 여러 기능과 React Query에서 사용안해 본 hook을 공부하기
Problem
- react query의 query key에 대한 이해도 부족으로 인해 반복적인 버그 발생
- 개발 일정에 비해 초반 계획과 설계가 부족했던 점
Try
- react query의 query에 대해 공부하기
- tailwind와 cva, cn 함께 사용하는 것을 공부하기 / 디자인 시스템을 구성할 때 tailwind를 활용하는 방법에 대해 공부하기
최성민
Keep
- 부족했지만 디자인 시스템을 구축하려는 시도와, 이를 기준으로 다양한 컴포넌트를 미리 작성해본 경험
- 덕분에 이후의 작업에 대해서는 확실히 빠른 속도로 진행이 되었던 것 같다.
- 컴포넌트를 더 잘게 쪼개는 연습, 그리고 공용 컴포넌트와 도메인에 종속된 컴포넌트를 잘 구분할 수 있는 안목을 키운다면 앞으로 작업하는 데에 크게 도움이 될 것이다.
Problem
- 더 좋은 코드를 작성하고 싶다는 욕심과 부족한 시간 사이에서 발생하는 딜레마
- 결국 마지막 즈음엔 아쉬운 부분이 있어도 일단은 넘어가야 했음
- 디자인 시스템 구축을 위해 선택한 스타일 라이브러리의 아쉬움
- 주문형 CSS를 사용했더니 그 자체로 이미 디자인 시스템과 같다는 생각이 들었고, 그래서 불필요하게 디자인 시스템이란 허울 뿐인 wrapper를 감싸는 느낌이었음
- 동적 스타일링이 불가능한 것에 크게 불편하다고 느낀 점이 많았음
- API 호출 시 페이지 별 필요한 데이터만 넘겨주는 것이 아니라 사용될 여지가 있으면 냅다 내려주는 경우가 있었음
- 그것마저도 명세와 다르게 데이터를 넘겨 주는 경우가 많았음
Try
- 더 좋은 코드를 작성하는 것은 중요하지만, 기한 내에 요구사항을 만족하는 것은 항상 1순위임
- 그런 면에서 코드 퀄리티를 잠깐 포기하고, 추후 리팩토링 한다는 마음으로 찝찝함을 남기지 않는 것이 더욱 도움이 될 것
- 디자인 시스템 구축을 할 일이 생긴다면 좀 더 체계화 된 레퍼런스를 참고하고, 더 세심하게 디자인 요소를 개발한 뒤 컴포넌트 및 테마 작업에 들어가는 것이 좋아 보임
- CSS 라이브러리 역시 동적 스타일링이 가능하고 빌드 타임에 CSS를 미리 생성할 수 있는 zero-runtime css 라이브러리를 도입해보고 싶음
- 백엔드 개발자와 직접 소통하며 제대로 된 협업을 해보고 싶음
정혜연
Keep
- 프로젝트 시작 전 그라운드 룰을 정하여 불필요한 의사소통을 줄여 각자 맡은 역할에 집중
- 협업 환경 개선
- 디렉토리 구조를 체계적으로 구조화함으로써, 폴더 이름과 구조를 일관되게 유지하여 프로젝트의 가독성 향상
- 브랜치 명, 깃허브 협업 방식, 커밋 태그 이름(husky사용)
- 공통 컴포넌트를 활용하여 빠른 페이지 개발 가능
- API 타입 구축 및 Axios 기본 설정 담당자를 통한 효율적인 협업
- 시간 절감 및 일관성 확보
Problem
- 의견을 나눴던 내용에 대한 기록 부족으로 혼란스러움을 겪는 상황 발생
- 실시간으로 협업하는 시간이 많다 보니, 디스코드를 통해 문제점을 말로 공유하고 해결책을 받는 방식으로 진행하여 해결은 빠르게 됨
- 이전에 이야기 나누고 정했던 것에 대해서 다시 이야기가 나옴
- 시간에 쫒겨서 세세한 부분을 충분히 신경쓰지 못하고, 주요 기능이 동작하도록 마무리하는데 급급하게 진행된 부분
- 게시글 글자 수 처리..
- React Query에 대한 부족한 이해와 컴포넌트와 데이터 간의 관계를 정확히 파악하지 않은 채 코드를 작성하여, 오히려 개발 속도가 늦어지는 문제
- 게시글 작성, 수정 페이지를 구현할 때, 주먹구구식으로 코드를 개발을 하거나, 다른 팀원의 코드를 참고하여 끼워 맞추는 식으로 코드를 작성
- 다른 기능에 사용된 훅을 정확한 이해 없이 사용하려다 보니 문제가 발생
- query가 아닌 suspencequery를 사용하면서 예기치 않은 문제가 발생
- 맡은 부분에 대해서 이슈를 미리 생성하지 않아 작업이 한번 겹치는 문제
- 공통 컴포넌트에서 원하는 CSS 속성 사용이 어려움
- className을 사용해도 해결이 되지 않는 문제
- 프로젝트 후반에 들어가면서 시간이 부족한 상황에서, 수정사항에 대한 이슈와 브랜치를 개별적으로 나눌지 한꺼번에 적을지에 대한 의견차가 발생
Try
- 문제가 발생했거나 의견이 있을 때, 곧바로 issue나 discussions를 활용하여 기록하고, 문서화하는 습관을 가지도록 노력이 필요합니다.
- 잘 모르겠는 부분에 대해서, 좀 더 적극적인 자세를 취해야 될 것 같습니다. 개발이 진척이 안된 것에 대해 소극적인 자세가 되지 말고, 더 질문하고 정보를 얻는 것에 노력이 필요합니다.
- 시간에 쫓기더라도, 내가 작성하는 코드는 모두 이해하도록 노력이 더 필요합니다.
- 컴포넌트와 데이터 간의 관계를 이해하고 개발하기
- 사용하는 훅에 대해서는 정확히 알고 사용하기
- 맡은 부분에 대해서 이슈 바로 생성하여 작업 상황을 모두 공유할 수 있도록 주의가 필요합니다.
- React, React Query에 대한 공부
- 유연한 사고와 합리적인 타협이 필요