패스트캠퍼스X야놀자 : 백엔드 개발 부트캠프_Java 토이 프로젝트2

1. K : Keep, 현재 만족하고 있는 부분 또는 계속 이어갔으면 하는 부분
2. P : Problem, 개선이 필요한 부분
3. T : Try, 문제에 대한 해결책 또는 다음에 시도해 볼 것

---

1. K

   (1) 이전 프로젝트를 진행한 후에 개선해야 할 점을 미리 문서로 정리한 후, 프로젝트 시작하기 전에 팀원들과 다같이 공유한 부분이 좋았다.

 

   (2) Java 및 Git commit 컨벤션 등 룰을 정해서, 마치 '한 사람'이 프로젝트를 구현한 것 처럼 보이게 해서 프로젝트에 짜임새를 더하였다.

 

   (3) RFP를 보고 구현 전에 사전 설계를 진행해서, 프로젝트의 변경 가능성을 최소화 하였습니다.

---

2. P

   (1) RFP에만 충실하기 위해 구현을 하였다. 물론 기획자가 아닌 개발자지만, '서비스가 어떻게 흘러갈까?' '다른 서비스는 어떻게 제공될까?' 등 구현하려는 서비스 자체의 흐름을 더 꼼꼼하게 파악할 필요가 있었다고 생각한다. 우리 팀은 서비스 자체에 집중하기 보다는 RFP에 나와있는 사항들을 빠짐없이 구현하는데에 더 초점을 두었던 것 같다. 다음 프로젝트 때는 서비스 자체부터 꼼꼼하게 파악하기 시작함으로써 더 완성도 있는 서비스를 구현하고 싶다.

 

   (2) 구현한 API를 github의 wiki에 저장해두었다. 그런데 만약 api가 조금 바뀐다던가 응답 구조가 바뀔 경우, 이 wiki를 모두 수정해야한다는 단점이 있었다. 이후에 알아보니 스웨거라는 툴을 이용해서 자동으로 api 명세서를 만들어주는 툴이 있었다. 다음에는 이를 적용시키면 더 좋을 것 같다.

---

3. T

   (1) Github의 issue를 사용해보고 싶다 issue를 통해 feature 브랜치를 만들어서 관리하고 싶다. PR을 보내면 자동으로 이슈와 브랜치가 닫히는 기능을 추가하면 프로젝트 작업 관리에 더 도움이 될 것 같다.

 

   (2) Github에서 코드리뷰를 더 꼼꼼하게 하면 좋을 것 같다. 지금까지는 merge하기 전에 줌에서 간단히 자기가 구현하거나 수정한 부분을 화면 공유해서 보여주고, merge를 했다. 그런데, 이렇게 화면 공유로 빠르게 지나가는 것보다 github에서 코드를 꼼꼼히 보면서 코드리뷰를 하면 더 좋을 것 같다.

---

이전 프로젝트보다 더 체계적으로 진행한 것 같아서 좋다. 이 다음 3차 프로젝트에서도 이 회고를 바탕으로 더욱 체계적인 프로젝트를 만들고 싶다.