팀 명 : 낙동강 오리들
프로젝트 명 : Orialz Blur Service
팀원 : 송진현, 이우석, 양을필 , 이지원 , 황시은
배포 링크 : [오리알즈 블러 서비스](https://test.orialz.com/)
내가 보고 싶은 것 만 보자!
사용자가 원치 않는 객체를 지정해 해당 객체가 영상에 나올때 모자이크 처리 해주는 사용자 맞춤형 블러 스트리밍 서비스
[시연영상 보러가기](https://www.youtube.com/watch?v=B1gG7LnyaPo&feature=youtu.be)
| 송진현 (팀장) | 이우석 | 양을필 | 이지원 | 황시은 |
|---|---|---|---|---|
인프라, 하둡 이미지 분산 처리 |
인공지능 사물 인식 |
프론트엔드 영상 Blur 처리 |
백엔드 로그인 + Rest API |
백엔드 파일 분할 업로드 + Rest API |
- 예외를 반환하는 경우 끝에 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 코드 작성과 관련된 모든 작업
- 없는 내용은 목업과
