안녕하세요. 프로그래머스 데브코스: 클라우드 기반 백엔드 엔지니어링 과정을 듣고 있는 쿠폰의 민족팀입니다.
지난 10월 22일, 팀이 구성된 이후 맡게 된 첫 번째 프로젝트 만큼 나름 의욕 넘치게 진행됐던 개발 진행과정에서의 경험을 공유합니다.
저희 팀의 프로젝트인 ‘우아한 쿠폰들‘은 배달의 민족의 쿠폰 서비스를 클론코딩 한 프로젝트입니다.
- 스크럼 마스터(SM)
- 나상원
- 프로덕트 오너(PO)
- 한맹희
- 개발자(Developers)
- 나상원, 한맹희, 이주오
- 나상원, 한맹희, 이주오
- Java 11
- Spring Boot 2.5.6
- JPA
- AWS RDS(MySQL8)
- AWS EC2, S3, Code Deploy
- gradle 7
- Jacoco
- Notion
- Slack
- Jira
- ERDCloud
- Postman
- Rest Docs
- Dbeaver, Mysql WorkBench
- Github Action
- sonar cloud
**Woowahan-Coupons**
├─docs
│ └─asciidoc
├─main
│ ├─java
│ │ └─com
│ │ └─coumin
│ │ └─woowahancoupons
│ │ ├─config
│ │ ├─coupon
│ │ │ ├─controller
│ │ │ ├─converter
│ │ │ ├─dto
│ │ │ ├─service
│ │ │ └─validator
│ │ │ └─annotation
│ │ ├─customer
│ │ │ ├─controller
│ │ │ └─service
│ │ ├─domain
│ │ │ ├─coupon
│ │ │ ├─customer
│ │ │ └─store
│ │ ├─global
│ │ │ ├─error
│ │ │ └─exception
│ │ └─store
│ │ ├─controller
│ │ └─service
│ └─resources
└─test
└─java
└─com
└─coumin
└─woowahancoupons
├─coupon
│ ├─controller
│ ├─document
│ ├─factory
│ └─service
├─domain
│ └─coupon
└─store
├─controller
└─service
- 지라등의 협업툴로 애자일 프로세스 경험 해보기
- git flow 브랜치 전략을 사용하여 하나의 프로젝트 코드를 여러명이서 효율적으로 관리 해보기
- 컨벤션을 정해서 맞춰가며 프로젝트 진행 해보기
- 깃허브 컨벤션
- 코드 컨벤션
- 처음부터 많은걸 하려고 하지 않는다.
- 애자일 처럼 처음부터 동작가능한 최소 기능을 만들고 여유가 있을때 살을 붙인다.
- 2주를 1주씩 스프린트를 두개로 나누어서 첫 스프린트 때 최소 기능을 가진 애플리케이션을 선 배포
- 2주를 1주씩 스프린트를 두개로 나누어서 첫 스프린트 때 최소 기능을 가진 애플리케이션을 선 배포
- 선착순 N명을 처리하기 위한 트랜잭션 다루기
- Jacoco 사용해서 테스트 커버리지 80% 이상 달성하기
- 쿠폰 번호는 어떻게 생성해야 하지?
- 쿠폰 테이블은 어떻게 설계 할까?
- 배민을 예로 들었을때 쿠폰의 발급 주체는 누구고 쿠폰의 사용 대상은?
- 쿠폰을 사용할때의 다양한 조건은 어떤게 있지?
- 내 API를 사용하게 될 클라이언트에게 어떻게 하면 보기 좋은 문서를 보여줄 수 있을까?
- AWS Cloud 사용 및 CI/CD 적용해보기
배달의 민족 앱을 분석해 보면서 도메인과 기능을 도출하고 쿠폰 서비스에 대한 이해를 하고자 했습니다.
- 쿠폰 발급 주체
- 쿠폰 어드민
- 매장 어드민
- 쿠폰 scope 주체
- 배민 자체 (ex 배민 첫 주문 만원 할인, B마트 추석맞이 할인 쿠폰)
- 음식점 브랜드 → brand (ex 네네치킨 브랜드관 쿠폰)
- 음식점 → store (ex 맹호수제돈까스 부천점의 최소 주문금액 별 할인 쿠폰)
- 쿠폰 발급 대상
- 음식을 주문하는 배민 모바일 앱 사용자
- 쿠폰 발급 방식
- 쿠폰 번호 등록
- 클릭으로 바로 등록
- 쿠폰 사용 조건
- 최소 주문 금액
- 사용 기간
- 발급 후 N일 동안 사용
- yyyy.MM.dd ~ yyyy.MMdd 까지
- 첫 주문
물건 N개 이상 구매 (라이브 쇼핑)N개월간 현대카드 사용하지 않음포장 or 배달- 사용후 특정 시간 후 재발급 가능
- 사람 별 제한
- 수량 제한(선착순 이벤트)
- 쿠폰 종류
- 할인 쿠폰
- 고정 금액 할인 (ex 천원 할인 쿠폰)
- 퍼센트 할인 (ex 20% 할인 쿠폰)
무료 쿠폰배달비 무료 쿠폰
랜덤쿠폰
- 할인 쿠폰
- 사용자 - 쿠폰을 발급받아서 실제 사용하는 주체
- 매장(사장님), 브랜드 - 음식점과 그 프렌차이즈로서, 쿠폰을 생성할 수 있습니다.
- 쿠폰 운영자(배민) - 사내에서 쿠폰 어드민 페이지를 통해 쿠폰 서비스를 운영합니다.
팀 노션에 작성한 초기 사용자 스토리의 일부
유스케이스를 통해 드러난 도메인의 개념들을 객체와 상태 등으로 점차 모델링 해 나갔습니다.
- 데일리 스크럼 14시
- 프로젝트 코어타임 14 ~ 19시
1- ⭐ feat : 새로운 기능에 대한 커밋
2- ⚙️ chore : 그 외 자잘한 수정에 대한 커밋
3- 🐞 fix : 버그 수정에 대한 커밋
4- 📖 docs : 문서 수정에 대한 커밋
5- 💅 style : 코드 스타일 혹은 포맷 등에 관한 커밋
6- ♻️ refactor : 코드 리팩토링에 대한 커밋
7- 🚦 test : 테스트 코드 수정에 대한 커밋
8- 🚀 CI : CI/CD
9- 🔖 Release : 제품 출시
10- 🎉 init : 최초 커밋
11- 🛠️ Config : 환경설정에 대한 커밋
12- 🦔 Revert : 리버트-
브랜치 전략은 git flow를 사용했습니다.
-
깃허브는 원본 저장소를 fork 하는 방식으로 사용했습니다.
-
PR로만 merge되게 하였습니다.
-
리뷰 approval이 2개 이상이여야만 merge 승인이 나도록 했습니다.
-
테스트를 모두 통과해야 merge가 가능하도록 설정했습니다.
-
지라 1티켓 = 1PR 원칙 (PR안에 커밋 수는 제한을 두지 않았습니다.)
-
깃허브 - 지라 연동 기능을 사용했고 PR 단위로 적용했습니다.
- 백로그로 추가된 이슈는 단위를 작게 쪼개서 하위작업으로 추가하도록 했습니다.
-
깃허브-지라 연동 스마트 커밋 기능 사용
-
에픽의 하위 작업이 완료되면, 상위 작업을 완료로 이동
-
깃허브 PR merge시 이슈 자동 완료 처리
코드 컨벤션은 구글의 자바 컨벤션을 따르기로 결정했습니다.
또한 sonar lint를 적용해서 리뷰를 받기 전에 컨벤션에 대한 검사를 수행하도록 했습니다.
롬복을 사용할때 발생할 수 있는 사이드 이펙트를 최소화 하기 위해 다음의 룰을 정했습니다.
- @setter 금지
- @Getter 사용 가능
- @NoArgsConstructor 사용 가능 그외 생성자 관련 Annotation 사용 금지
- 선택적 @Builder 사용가능
- dto 클래스 네이밍은 surffix로 Dto 붙이기
- nested dto 클래스의 필드는 dto 사용 금지
- collection 형태이면 wrapper로 감싸서 일급 컬렉션 만들기
- java ci with gradle : ci 및 빌드 확인
- Sonar-build : push 된 commit 코드스멜 등 코드 분석
- deploy : 배포
- 되도록이면 PR할때 해당 코드에 대한 테스트를 포함하도록 했습니다.
- jacoco를 이용해서 코드의 커버리지 확인과 커버리지 기준을 80%로 제한하여 만족하지 않으면 빌드가 되지 않도록 했습니다.
