[ KPT 회고 ] 개발의 민족 / 딜리버리 서비스

개발의 민족 프로젝트 발표 PDF 일부

 

Keep : 만족하며 지속하고자 하는 점

• Pull request 시 2인 이상 코드리뷰 후, 본인 외 Merge
• 도메인 별 브랜치 작업 : main, develop, feature#1, 2, 3 ... : 각 기능별 정리
• 프로젝트 시작 전, 컨벤션 규칙 정리
• code with me 와 같은 페어프로그래밍

---

Problem : 불편하기에 개선이 필요하다고 생각되는 점

• 브랜치 전략
  • 브랜치 작업 관련해서 미리 대화를 나눴지만, 사실 현재 작업한 우리의 브랜치를 살펴보면 각자 개인의 스타일이 담겨있다. 예를 들어 폴더 구조 안에 브랜치를 생성하거나, 폴더 구조 없이 브랜치를 생성하는 등 개인의 차이가 있었다.

 

• API 명세와 실제 작업의 차이
  • 시간적 여유가 없는 상황에서 이 부분까지 수정하기에 번거롭지 않을까 싶어서 살짝 넘기고 지나간 부분이 있다. '수정' 기능의 API를 만들 때 API 명세에는 PATCH로 작업했는데 실제 작업물에는 PUT으로 작업되어있는 점을 확인할 수 있다. 

API 명세 예시

PUT으로 설정된 예시 코드

---

Try : Problem의 해결책 또는 실행가능한 점

• 브랜치 전략 재수립
  • 문제가 되는 부분은 아니지만, 통일성이 부족해보여서 폴더구조에 넣거나 폴더구조를 이용하지 않는 등에 대한 부분을 미리 확실하게 규칙을 정해두고 작업을 시작하는 것이 좋다고 생각되었다.
• API 명세 리마인드
  • API 명세를 코드에 맞춰 변경하기보단, API 명세에 맞춰 코드를 작성하는 것을 연습하는 편이 실무에 도움이 될 것이라는 생각이 들었다. 기획자가 만든 요구사항을 변경하는 일은 쉽지 않을 것이라 생각되었기에, 미리 대화를 나눠 API 명세를 수정하고나서 개발을 진행하거나 요구사항대로 진행하는 편이 좋을 것 같다고 생각되었다.

---

개발의 민족 딜리버리 서비스 GitHub 바로가기

↓↓↓↓↓↓

GitHub - delivery-6/delivery-app

---