<aside>
⏰ 9/10(금) 늦은 10시 에 회고를 진행합니다!
</aside>
🎉첫 프로젝트가 끝났습니다!
데브코스 첫 프로젝트인 노션 클론코딩이 마무리 되었습니다!
프로젝트를 마무리한 기분은 어떠신가요?
만족스러운 결과물이 나와 뿌듯해 할 수도 있고 미쳐 마무리하지 못해 찝찝해 할수도 있을 것 같아요. 또 결과는 제쳐 두고 프로젝트가 마무리 되었다는 사실에 홀가분해 하실 수도 있겠네요!
🖊️우리 회고 합시다!
어찌되었던 간에 우리 회고합니다!
프로젝트 기간에 부족했던 것, 아쉬웠던 것, 뿌듯한 것 등등 우리는 다양한 감정을 느끼고 밀도 높은 경험을 했습니다. 그런데 사진 한 장 없는 추억으로 삼고 모든 것을 과거에 남기기에는 너무 아깝지 않을까요?
서로 회고를 통해 기록하고 공유한다면 앞으로 마주하게 될 수많은 프로젝트를 위한 든든한 밑바탕이 될거라 감히 확신합니다!
🤷♂️회고 때 무엇을 하나요??
☝️ 우선 모든 것을 털어내 봅시다.
Good
- 요구사항을 정리하고나니 생각보다 많고 세부적인 요구사항이 많다고 느꼈다. 전부 텍스트로 정리해두고 하나씩 구현해나가면 commit하기에도 좋고, 이슈 분석할 때도 어느 지점인지 팀원 간에 공유가 될 것 같아서, 과정은 힘들었으나 그만큼의 가치가 있었던 부분이라고 생각한다.
- eslint의 rule을 정하는 과정에서 그 동안 나의 코딩스타일을 돌아볼 수 있었고, 코드리뷰에서 주로 지적받던 부분을 미리 린트로 설정해두었기 때문에 실수를 줄일 수 있을 것 같다. 팀원들과 코드리뷰를 하면서도 통일된 스타일이면 가독성도 좋아질 것이라는 점에서 rule을 세부적인 것까지 협의한 것은 잘한 것 같다.
- 이슈 템플릿이나 PR 템플릿을 처음 작성해보았는데, 아직 개발을 시작하진 않았지만 이런 양식이 있으면 서로의 이슈를 파악하고, 진행 내용을 공유하기도 좋을 것 같다. 적극적으로 활용해보아야겠다.
- 기능 개발 시간보다 테스트 시간(스토리북, 브라우저)이 더 오래 걸리는 것 같지만, 확실하게 동작하는 기능을 PR하기 위해서는 필요하다고 생각한다.
- 원래라면 해당 기능 구현 중 발생한 에러를 해결만 하고 넘어가버렸을텐데, 이슈로 등록해 발생 원인과 해결과정을 기록해두다보니 나중에 동일한 이슈에 대해 참고자료가 될 것 같다.