팀 규칙

팀 문화

회의

• 매일 아침 데일리 미팅
  • 했던 일
  • 해야 할 일
  • 이슈사항 공유 (삽질 등)
• 매일 금요일 저녁 회의
  • 주말에 해야할 일 공유
  • 데모 후 Q&A에서 나온 이슈사항 정리 (다음주~)

개발 컨벤션

프론트

• 프론트 부분은 도메인 개발한 팀원이 담당
• JS 파일 분리해서 사용

패키지 구조

• 패키지 구조 참고 : https://www.slipp.net/questions/36
• 이번 프로젝트에서는 위 페이지의 2안을 따르기로 결정

메서드 컨벤션

• 컨트롤러
  • 참고 : https://www.slipp.net/questions/79
• 서비스
  • 생성 - save
  • 조회 - findBy{dto}~~
    • Return이 Entity인 경우 Repository에 맞춰서 메서드 네이밍
    • Return이 Dto인 경우 find{Dto명}ById와 같은 방식으로 네이밍
  • 수정 - update(엔티티의 전체 데이터 수정시), update{수정할 속성}And{수정할 속성}...
  • 삭제 - deleteById
• DTO
  • entity -> dto : from
  • dto -> entity : toEntity

로깅전략

• 요청이 들어오는 곳에 로그를 작성한 후 장애 발생하는 경우 추가하는 전략 (컨트롤러에서 로그를 찍기 때문에 서비스에서는 작성하지 않음)
• 복잡한 로직에 대해서 로그 작성 고려
• exception 예외 및 logback-access 로그 작성

Git 컨벤션

커밋

• Commit message 참고 : https://gist.github.com/joshbuchea/6f47e86d2510bce28f8e7f42ae84c716
• 한글로 작성할 것!
• 커밋 단위는 본인 방식대로 하되 추후 유동적으로 조정

브랜치

• git-flow 사용
• 각자 개발한 결과를 develop에 PR 보냈을 때 코드리뷰 할 것, 모든 팀원이 Approve 한 경우 develop에 merge

코드 리뷰

• 참고 : http://woowabros.github.io/experience/2017/10/30/baemin-mobile-git-branch-strategy.html
• 잘한 것에는 아낌없이 칭찬해주기

PR

• 공통
  • 스쿼시 커밋으로 merge하기
  • 만약 급하게 merge 해야한다면 slack에 팀원들에게 알려준 후 merge 실행할 것
• 프론트
  • 프론트 기능 관련 PR은 보낸 시간을 기준으로 1시간 동안 팀원들이 실행해보고 이슈사항이 있다면 알려준다
  • 만약 1시간 동안 아무 문제가 없는 경우 PR 보낸 팀원이 merge
• 백엔드
  • 기본적으로 모든 팀원이 approve 하는 경우 merge
  • 단, 주말은 2명이 approve 한다면 merge 실행

리뷰어 피드백

• 기본은 자기가 작성한 코드의 피드백은 자기가 수정
• 하트 이모지로 자신이 수정할 피드백에 표시
• resolved 닫지 말기