문제점 (어려웠던 점, 아쉬웠던 점)
- 서로 업무를 분담하고 작업을 한뒤에 하나의 코드로 어떻게 합쳐야할지 감이 잘 안왔다.
작업을 최대한 컴포넌트로 분리하여 App.vue와 index.js와 같은 컴포넌트들을 배치하는 파일만 다같이 Merge작업을 진행 한다.
- 의사 결정 과정이 한 방향으로 향하지 않을 때 어떤 결정을 내려야 할지 어려웠다.
의견이 한방향으로 모아지지않을 경우에는 팀장의 의견을 채택하는 것으로 합의를 한다.
- 깃으로 협업하는 부분이 익숙하지 않아 깃헙 브랜치를 체계적으로 만들지 못한 부분이 아쉬웠다.
Feat/new_post
,Fix/login
처럼 브랜치 명칭에 작업 내용도 추가했다면 브랜치를 보는 것만로도 작업 과정이 정리되었을 것 같다. (현재는dev_[작업하는 부분]
으로 작성함.)
커밋 내역과 브랜치 현황도 프로젝트의 협업 과정을 증명할 수 있는 도구이기 때문에 프로젝트를 시작하기에 앞서 짧게나마 같이 깃을 공부하는 시간을 가진다.
- 디자인적인 통합이 잘 안되었다.(페이지 구성 포함) 개발 능력과 별개의 부분이라고 생각 → 그래서 해당 부분에 대한 팀원들의 확신이 없는 듯하다
디자인 시스템을 먼저 작성하고 이를 기반으로 각자 개발한 뒤에 최종적으로 통일하는 방식으로 한다.
- 현재 문제인데, 코드가 난잡하다. 코드 스타일이 통일되지 않았다.
추후에 검수가 필수적이다. 한명이 전담하는게 통일성 있을 것 같다.
- 기능 단위로만 분담하다보니 기능의 일부 과정이 중복되는 경우가 있다. ex) API 호출
미리 공통으로 사용할 유틸들을 작업한 후 업무를 분담한다면 추후 수정할 부분을 줄일 수 있었을 것 같다. (api호출, localstorage 작업 등)
- 상태정보 보존에 관한 문제(새로고침시 증발)
라우터 params로 id정보를 전달한다 → url정보를 통해 id를 조회하는 것으로 상태정보를 따로 저장하지 않아도 구동하게 리팩토링한다