팀 회고록
브랜치
- 전략 자체는 좋았다고 생각합니다.(git-flow)
- 브랜치 작업을 할 때 conflict, develop 최신 사항 반영 시 필요 기능 가져올 때 어떤 방식으로 가져와야하는지(squash merge, local origin pull 후 merge, cherry-pick)에 대한 어려움, 협업할 때의 방법이 익숙하지 않았습니다.
- 컴포넌트 하나씩 만들고 PR 올리고 의견 교류하는게 좋았습니다. 문제 없는지 확인하는 과정이 마음에 들었습니다.
- 작업 방식이 익숙하지 않다 보니 작업이 동기식으로 진행되는 상황이 조금 발생했었다. 비동기식으로 작업하는 방법에 대해 조금 고민해보면 좋을 것 같습니다.
⇒ 비동기적으로 처리할 수 있는 방법이 궁금했습니다.
- develop 최신사항, routing, design 변경할 때 이전이랑 변경하면 충돌(conflict)이 났었습니다.
API 연결
- 예외처리가 되어있지 않은 요청(존재하지 않는 포스트에 대한 좋아요 요청) 때문에 서버가 죽어버리는 상황이 발생해서 개발이 지연되는 상황이 발생했는데, 이 부분이 조금 아쉬웠습니다.
- 각자 API를 다른 방식으로 연동하는 문제(fetch, axios, instance)가 있었습니다. 관련해서 회의를 한번 진행했으면 더 좋았겠다하는 아쉬움이 있었습니다.
API 터진 상황에서의 대처(더미데이터)
- 시작부터 더미데이터를 만들고 잘 동작하는지 확인하고 API 연동을 했어야 했을 것 같습니다.
- 더미 데이터로 테스트를 해보고 API 연동을 했는데
_id가 달라 생기는 문제점, 아이디 없는 문서라고 서버가 죽어버리는 상황이 생겼습니다. - 두번이나 겪은 서버 나가는 현상
- 어떤게 문제점인지도 모르겠는 답답한 상황들
- 잘못한게 아닌데 자책하는 상황의 연속
- 더미 데이터로 했으면 됐을 것 같은데 어떻게 해야하지 당황하고 막연하게 기다리는 시간이 아까웠습니다.
작업 방식의 체계화 부족으로 인한 문제점
- 프로젝트에 대한 경험이 없는 교육생끼리 작업을 하다보니, 초기 단계에서 작업 방식에 대한 구체적인 방향을 잡지 못 해서 작업을 진행하며 어려움이 있었습니다.
- API 터졌을 때 더미데이터를 생성하지 못하고 기다리는 점(작업 방식의 체계화 덜 됐다.)
- 완성된 컴포넌트가 merge되기를 기다리는(PR review가 안달리는 등)상황이 때문에 작업이 밀리는 경우가 발생했습니다.
- 스프린트 방식에 익숙하지 않아 작업이 진행될 때 마다 추가되는 이슈들..
작업 시간의 부족함으로 인해 멘토님의 의견을 모두 적용하지 못했던 점
- 멘토님의 친절한 피드백에도 적용하지 못한 아쉬움
- PR에 남겨주신 많은 의견들을 반영하지 못한 아쉬움
- 리팩토링 기간에 뭔가 다른 라이브러리나 좋은 코드로 바꾸고 싶습니다.
- 라이브러리 적용
- formik
- lodash
멘토님께 궁금한 점
- 프로젝트를 진행하면서 conflict를 github web editor에서 수정하거나, 로컬에서 develop을 pull 한 뒤 merge해서 conflict를 해결한 뒤 올리는 방식으로 작업했는데, 어떤 방식이 더 효율적인지 알고 싶습니다!
- 실제로 실무에서 다른 사람이 작업한 기능이 내 작업에 필요한 경우, 어떻게 작업을 진행하시는지 여쭤보고 싶습니다!
- API를 연동할 때, 기능을 구현할 때나, Context API 등 전체적으로 얘기할 게 있을 때 회의 일정을 어떻게 적절하게 잡을 수 있을까요?
개인 회고
이재웅
주어진 시간이 짧다는 압박감에 프로젝트 초기 기획 단계에서 구체적이고 상세한 계획을 짜지 않고 프로젝트를 진행했습니다.
그 결과 프로젝트를 진행하면서 더 많은 이슈가 발생하게 되었고, 회의를 진행하는 횟수도 잦아지면서 오히려 더 시간을 잡아먹게 되는 상황이 일어나게 되다 보니, 기획 단계에서 구체적인 작업 문서를 만들고 가는게 더 효율적이라는 것을 깨닫게 되는 좋은 경험이 되었던 것 같습니다.
또한, 아직
React에 대한 숙련도가 높지 않은 상태에 추가적으로 시간도 짧다보니 컴포넌트의 추상화나, 반복적으로 사용하는 로직을 hook으로 만드는 부분이 많이 부족했던 것 같아서 아쉬움이 많이 남습니다.그래도 개인이 작업할 때 겪어보지 못했던 많은 상황들(git의 squash merge, cherry-pick, conflict)을 마주하고 해결하는 과정에서 도움이 되는 부분이 많았고,
commit과 pr 단위는 작게 해라. 라는 말을 많이 들었는데, 실제로 팀원끼리 코드 리뷰를 진행해보면서 왜 작은 단위의 pr이 필요한지 와닿는 좋은 경험이었던 것 같습니다.장규범
- 회의시간
- 적절한 회의시간 일정을 잡았어야 됐을 것 같습니다. 현재는 이슈가 터지면 회의를 하는 것이 아닌 체계적으로 기획 회의, 디자인 회의, UI 회의, API 회의, 기능 구현 회의 등으로 나눠서 진행했으면 좋았을 것 같습니다.
- 불필요한 기능들에 대한 의구심
- SNS를 만드는 프로젝트인데 뭔가 너무 거리가 먼 주제를 잡은 것이 아닌가 하는 생각이 많이 들었습니다. 제가 생각한 주제이긴 하지만 기본 구현 사항과 거리가 조금 있었던 것 같습니다.
- CRA로 프로젝트를 만들면서 생기는 많은 이슈들
- CRA로 프로젝트를 생성하고 개발환경을 구성하는 과정이 좋은 경험이었습니다.
- Prettier, ESLint 적용
- Prettier와 ESLint를 적용하면서 잘 적용이 안된 상황이 있었는데 이걸 해결하는 과정이 의미가 있었습니다.
- 전역 상태 관리
- Context API 와 Redux 사이에서 고민을 했는데 이 과정이 한번 쯤은 꼭 필요한 과정이었다고 생각합니다. 그리 무거운 주제도 아니었고 기능 구현이 많은 엄청 큰 프로젝트도 아니라 Context로 처리해도 문제가 없었던 것 같습니다. 무작정 Redux로만 개발을 하려고 한 편견을 깰 수 있었습니다.
- API 연동
- API가 있을 때만 개발하는 것이 아닌 것을 여실히 알게됐습니다. API 서버가 나가있는 상황이 길어졌을 때 어떻게 해야할 지 모르고 기다려야하는 상황이 많았는데 더미데이터로 테스트하고 API는 Postman으로 테스트하고 안정성을 확인 후에 연동을 해야할 것 같습니다.
팽건우
같이 개발을 진행하고 있지만 혼자 쉬고 있는 느낌이 들고 미안합니다. 저의 실력이 부족한 탓인지? 잘 모르겠고 빠르게 실력을 늘리도록 노력해야 겠습니다.
데브코스를 하면서 더 느끼는 것인데 시간관리를 잘 못하고 있다는 고민에 빠져있어 빨리 빠져나와야 겠고
좀 더 깊게 프로젝트에 깊게 파고들고 싶은데 시간이 아쉽다는 생각이 듭니다.
멘토님이 알려주신 프로젝트 초기 방법을 잘 보면서 다시 재정리 하면서 봐야 겠고 우선 완성부터 시켜 놓고 궁금한 점은 다 적어놔서 끝나고 찾아본 뒤에 질문을 하던가 해야겠습니다. 🙂
홍정기
프로젝트가 처음이라 프로젝트 초반에 어떤 사항들을 정리해야 하는지 몰라서, 이 정도면 됐겠지하고 넘어갔었는데 프로젝트를 진행하면서 어떤 기능이 필요한지가 명확하지 않아서 그걸 다시 정의하는 데 시간이 많이 드는 것 같습니다.
마감 기한이 빡빡하다보니 급하게 개발을 하고 있는데, 그러다보니 코드 퀄리티를 생각하지 않고 막 개발하고 있는 것 같습니다. 과제 할 때는 그래도 나름 신경 쓰면서 개발 했던 것 같은데 아쉽습니다.
오히려 프로젝트를 진행하면서 리액트로 개발하는 것보다 깃을 사용하는 부분에서 문제가 더 많았던 것 같습니다. 깃을 제대로 공부하지 않아서 생긴 문제라 프로젝트가 끝나고 차근차근 깃 공부를 해야할 것 같습니다. 그래도 프로젝트 진행하면서 다양한 깃 명령어를 사용하다보니 배우는 점은 많은 것 같습니다.
전체적인 프로젝트 진행 과정을 확실히 정리해야 다음에 프로젝트 할 때 도움이 될 것 같습니다.
작업중인 브랜치에 develop 브랜치의 새로운 변경 사항을 반영해야 할 때 지금은 develop 에서
git pull origin develop 을 실행하고 작업중인 브랜치로 돌아와 git merge --squash develop 으로 변경사항을 가져오는 중인데, 이렇게 하니까 작업중인 브랜치에 필요 없는 기능들이 다 가져와져서 파일 변경사항을 파악하기가 어렵습니다. 이때는 git cherry-pick 을 사용하면 되는건지 궁금합니다.