프로젝트 개요

이 프로젝트를 개발 시작한지도 어연 n개월이 지났다.
해당 기간동안 본 프로젝트와 관리자 페이지의 1차 개발을 완성했다.
이 시기에 배포만을 남겨두고 중간 회고를 진행해보도록 하겠다.

Keep

• 우리는 일주일에 한 번 항상 온라인 혹은 오프라인 미팅을 갖고 이 때 서로의 문제 공유, 혹은 상황 공유를 진행하였다.
  이것의 장점은 각자 역할에 따라 빠르게 개발을 진행할 수 있었다는 점이다.

• 회의마다 개선점 혹은 추가 개발 기능을 논의하여 계속된 발전을 추구하였다.
  기존 코드(기능)의 아쉬운 점 혹은 서비스 확장(추가 기능)을 일주일에 한 번씩 언급함으로써 프로젝트의 정체기를 만들지 않았다.

• 외부에서 각자 배운 것을 공유하는 시간을 가졌다.
  다른 곳에서 알게 된 "개발 지식"을 공유하는 시간을 자연스럽게 확보했다. 회의 중 서로의 의견을 공유하고 우리 프로젝트에 도입하면 좋을지 말지를 함께 의논하는 시간으로 인해 서로 발전할 수 있었다.

Problem

• 가장 아쉬운 점은 백엔드가 2명이었는데, 프론트의 요청사항에 따른 구현에 급급하여 서로의 코드를 리뷰하지 않았다는 것이다.
  이에 따라 서로 개발한 부분에 대하여 질문이 생기면, 그만큼 충분한 이야기가 오가야 했다. 또한 이후에 코딩 컨벤션을 맞춰나가야 할 부분이 생기면 해당 내용에 대해 코딩 컨벤션 정리가 잘 되지 않는 문제가 생겼다.

• 배포 이후 개발 환경과 배포 환경을 구분하지 못했다.
  개발하면서 Test로 인한 dummy data가 DB에 저장되는 상황이 발생하였는데, (아직 배포를 진행하지 않았지만) 배포한 이후 Test해봐야 할 상황에서는 데이터 정합성의 손실의 이슈를 겪을 수 있다.

• 구현에 급급하여 테스트 코드를 꼼꼼히 작성하지 못했다.
  이에 영향으로 프론트엔드 개발자가 API 오류를 찾아주는 사태까지 겪어본 적 있는 점... 문제라고 생각한다.

• 배포 actions를 체크할 때, develop에 푸시하면서 체크했다.
  실제 배포 서비스였다면, 오류를 해결할 때까지 서비스가 동작하지 않을 수도 있는 중요한 문제이다.

Try

• PR을 날렸을 때, 상대방이 코드리뷰를 진행한 후 Merge 하기 규칙을 추가한다.

• 개발 환경과 배포 환경을 서버/DB 모두 분리한다.

• 지금껏 작성한 코드에 대하여 테스트 코드를 만드는 시간을 갖고, 앞으로 만들어 갈 코드는 테스트 코드를 먼저 작성한 후 구현하는 작업순서를 거침으로써 TDD 개발 방식을 진행할 것이다.

• 충분한 빌드-배포 테스트를 로컬 (혹은 개발 서버)에서 거친 후 PUSH한다.

마무리

애정이 많이 있었던 만큼 아쉬움도 많이 남은 프로젝트이다.
앞으로 고칠 점이 많기에, 팀원과 함께 회고 후 개선하고 발전할 나날들을 기대한다.