9/10(금) 늦은 10시 에 회고를 진행합니다!
🎉첫 프로젝트가 끝났습니다!
데브코스 첫 프로젝트인 노션 클론코딩이 마무리 되었습니다!
프로젝트를 마무리한 기분은 어떠신가요?
만족스러운 결과물이 나와 뿌듯해 할 수도 있고 미쳐 마무리하지 못해 찝찝해 할수도 있을 것 같아요. 또 결과는 제쳐 두고 프로젝트가 마무리 되었다는 사실에 홀가분해 하실 수도 있겠네요!
🖊️우리 회고 합시다!
어찌되었던 간에 우리 회고합니다!
프로젝트 기간에 부족했던 것, 아쉬웠던 것, 뿌듯한 것 등등 우리는 다양한 감정을 느끼고 밀도 높은 경험을 했습니다. 그런데 사진 한 장 없는 추억으로 삼고 모든 것을 과거에 남기기에는 너무 아깝지 않을까요?
서로 회고를 통해 기록하고 공유한다면 앞으로 마주하게 될 수많은 프로젝트를 위한 든든한 밑바탕이 될거라 감히 확신합니다!
🤷♂️회고 때 무엇을 하나요??
☝️ 우선 모든 것을 털어내 봅시다.
Good
- 요구사항을 정리하고나니 생각보다 많고 세부적인 요구사항이 많다고 느꼈다. 전부 텍스트로 정리해두고 하나씩 구현해나가면 commit하기에도 좋고, 이슈 분석할 때도 어느 지점인지 팀원 간에 공유가 될 것 같아서, 과정은 힘들었으나 그만큼의 가치가 있었던 부분이라고 생각한다.
- eslint의 rule을 정하는 과정에서 그 동안 나의 코딩스타일을 돌아볼 수 있었고, 코드리뷰에서 주로 지적받던 부분을 미리 린트로 설정해두었기 때문에 실수를 줄일 수 있을 것 같다. 팀원들과 코드리뷰를 하면서도 통일된 스타일이면 가독성도 좋아질 것이라는 점에서 rule을 세부적인 것까지 협의한 것은 잘한 것 같다.
- 이슈 템플릿이나 PR 템플릿을 처음 작성해보았는데, 아직 개발을 시작하진 않았지만 이런 양식이 있으면 서로의 이슈를 파악하고, 진행 내용을 공유하기도 좋을 것 같다. 적극적으로 활용해보아야겠다.
- 기능 개발 시간보다 테스트 시간(스토리북, 브라우저)이 더 오래 걸리는 것 같지만, 확실하게 동작하는 기능을 PR하기 위해서는 필요하다고 생각한다.
- 원래라면 해당 기능 구현 중 발생한 에러를 해결만 하고 넘어가버렸을텐데, 이슈로 등록해 발생 원인과 해결과정을 기록해두다보니 나중에 동일한 이슈에 대해 참고자료가 될 것 같다.
Bad
- 회의 시간에 제한을 두지 않고 진행하다보니 다른 길로 새는 경우나, 우선순위가 떨어지는 주제에 대해 오랫동안 붙잡고 있는 경우가 종종 있었다. 프로젝트 진행 경험이 많지 않다보니 어떤 곳에 힘을 더 쏟아야 하는지가 아직은 애매모호하다.
- figma를 처음 사용해보았는데 와이어프레임과 UI 명세서를 함께 작업하려다보니 이 역시 시간과 노력이 많이 들어가게 되었다. 결과적으로 구현해야할 결과물이 명확해져서 개발 단계에서 추가적으로 논의할 부분이 최소화될 것이라는 점은 확실하지만, 짧은 프로젝트 기간에서 어느정도 까지 협의를 했어야 하는지에 대해서는 여전히 의문이 든다.
- 디렉토리 구조를 미리 정해두고, 네이밍도 해두었는데 이 부분에 생각보다 많은 시간을 쓴 것 같다. 추후 변경해도 되는 부분이라는 점에서 초기에 많은 시간을 쓰는 것은 지양할 필요성을 느꼈다.
- 모든 PR에 대해 코드리뷰를 진행하는 것은 당연히 좋은 부분이다. 하지만 코드리뷰에 소요되는 시간을 고려했을 때에도 정말 '모든' PR에 대해 리뷰를 진행해야하는지가 의문이다.
✌️ 의미 있는 것들을 남겨봅시다!
기획 단계의 협의 과정
- Good → 초기에 많은 부분에 대해 의견 합의를 하고 프로젝트를 시작하니 의견 충돌이 적음
- Bad → 중요성 대비 협의 시간을 길게 가졌던 안건에 대한 아쉬움
요구사항
- Good → 세부적으로 작성
- Bad → 협의 기간의 장기화 (프로젝트 진행 지연)
이슈
- Good → 각자 할 일이 명확해짐, 기능 구현 및 버그에 관한 기록 관리 가능
- Bad → 이슈를 생성하는 단위에 대한 모호함 (컴포넌트 단위, 페이지 단위, ...)
테스트
- Good → PR에서 해당 작업물의 결과를 눈으로 확인할 수 있음
- Bad → 스토리북으로 작성하는 과정에서의 시간 소요 (감수해야하는 부분이겠죠?)
UI
- Good → 와이어 프레임을 통해 프로젝트 결과를 예측할 수 있고, 실제 style 작업을 할 때 참고 가능
- Bad → 레이아웃을 짜는 것에 익숙하지 않은 점 때문에 시간이 많이 소요됨
코드리뷰
- Good → 내 코드 뿐만 아니라 다른 사람의 코드도 한 번씩은 볼 기회가 생김, 미처 발견하지 못한 에러에 대한 초기 대응 가능
- Bad → 기능 구현을 하느라 코드리뷰가 부담으로 느껴질 때가 있다. 코드리뷰를 상세하게 하려면 개발 속도가 지체되고, 그렇다고 무분별하게 approve를 할 경우 예상치 못한 충돌이 날 수 도 있는 딜레마??
🤟 앞으로에 대해 얘기해 봅시다.
- 이슈를 먼저 생성하고 개발을 시작하는 방식이 익숙하지 않지만 github projects에서 현재 진행상황을 파악하기 쉽고, 다른 팀원의 코드 리뷰를 바로바로 할 수 있어서 좋다. 실제로 현업에서도 이런 방식으로 개발을 진행하는지 궁금하다.
- 개발을 시작할 때 api연동을 하여 데이터를 받아오는 작업부터 시작하는지, 화면에 더미데이터를 렌더링되게 하는 작업부터 시작하는지가 궁금하다. 아니면 상황마다 다른것인지?