팀 명 : A4용지
프로젝트 명 : AVOCADO
팀원 : 황시은, 정연수, 오승기, 이원희, 정재현, 권민재
배포 링크 : [아보카도 경매]
아무거나
보여주고
카메라로 판매하는
도떼기경매
`경매` 거래방식을 메인으로 잡은 서비스로, 이용자의 물건을 등록하고 `라이브경매`와 `상시경매`를 통해 이용자는 다양한 상품을 적절한 가격으로 구매할 수 있습니다.
| 황시은 | 정연수 | 오승기 | 이원희 | 정재현 | 권민재 |
|---|---|---|---|---|---|
확실히 이해하면서 진행하자! |
모르는 건 익히고, 할 수 있는 건 최선! |
마인드도 실력도 성장! |
항상 긍정적으로 최선을 다하자! |
미리 하기! | “그냥” 이라 하지 않기 |
- 예외를 반환하는 경우 끝에 OrElseThrow 붙임 ex) 사용자 명을 찾는데 없으면 예외를 반환하는 경우 findMemberOrElseThrow 라고 붙임
- cancle같이 예외 반환이 명확한 경우엔 생략해도 괜춘
- final or static 이 붙는 변수명은
대문자로 작성, 공백이 필요하면_사용 - 그 외엔
Camel Case사용
- 모든 항목은
대문자로 구성 - 각 원소 식별자는 정수가 아닌
**문자열**로 한다.
- domain과 repository는 같은 패키지에 넣자
Git-Flow 브랜치 전략에 따라 기능별로 브랜치를 나누어 작업하고 있고 모든 브랜치에 대해 pull request를 통한 리뷰 완료 후 Merge를 하고 있습니다.
✅ master : 제품으로 출시될 수 있는 브랜치
✅ develop : 다음 출시 버전을 개발하는 브랜치. feature에서 리뷰완료한 브랜치를 Merge
✅ feature : 기능을 개발하는 브랜치
✅ hotfix : 출시 버전에서 발생한 버그를 수정하는 브랜치
참고 문헌
Karma - Git Commit Msg
- 기능 하나당 하나의 브랜치에 작업
- 즉,
한 사람당 한 브랜치를 사용 - 상황에 따라
중간 브랜치를 두고 그곳에 병합할 수 있음 - 브랜치 네이밍은
케밥 케이스사용 ex) 방송의 채팅 피쳐를 맡은 경우 feature-live-chatting - develop의 경우 백, 프론트 구분을 위해 backend/develop, frontend/develop 식으로 구현 - 각 FEATURE들은 중간 브랜치 또는 DEVELOP 브랜치에
스쿼시 머지후 새로운 브랜치 생성
- 머지 conflict 발생시, 병합 지정 충돌 날 때 중간 브랜치 또는 DEVELOP에다 하면 커밋 로그가 지저분해짐
스쿼시 머지후브랜치 삭제- 브랜치 네이밍은
케밥 케이스사용
- 급하게 수정할 일이 있을 때 사용
스쿼시 머지후브랜치 삭제- 브랜치 네이밍은
케밥 케이스사용
EX) 채팅 기능 구현시 Feat: 채팅 기능 구현 필요시 1~2줄 정도의 추가 메시지 달 수 있다.
- 새로운 기능이 추가될 때
- readme, swagger, 주석같이 문서화와 관련된 모든 작업
- 포맷팅, 코드 컨벤션같이 로직이 바뀌지 않은 수정 작업
- 코드 로직 재구성과 관련된 모든 작업
- 사소한 커밋 ex) Chore: 점심 먹기 전 커밋
- test 코드 작성과 관련된 모든 작업
- 문서화를 통한 협업
- PR 과정에서 발생하는 conflict 해결 및 협업 능력 향상
- Spring Boot를 활용해 주어진 요구에 맞춰 REST API 설계 및 구현
- 주어진 요구에 맞춰 ERD 설계
