👨👩👧👦 Team Culture
- 매일 오전 10시에 모여서 각자 진행 사항 및 이슈 논의
- 프로젝트 기간 내 오전 10 ~ 12 / 오후 2 ~ 4시까지는 항시 접속 및 응답
- PR할 경우 2명 이상의 승인이 되어야 Merge가 가능
- 작업 중 발생한 에러는, 팀원끼리 같이 해결
- 프로젝트 진행 중 배려와 존중 / 커뮤니케이션 상시 !
Git Convention
Branch
main: 서비스 운영 브랜치입니다.dev: 개발 환경 브랜치입니다. 개별적으로 작업했던 내용을 합치고 검토합니다.feat/refa/...: 프론트 & 백엔드 세부 브랜치
Git flow
- 개인 브랜치에서 작성 후 dev 브랜치로 PR 요청
- 2인 이상 승인 후 dev 브랜치로 merge
- PULL -> 작업 -> COMMIT -> PULL(이전 시간 동안 누가 작업했을지도 모르니까) -> PUSH
Branch protection rules
- PR할 경우 2명 이상의 승인이 되어야 Merge가 가능해진다.
Commit & Pull-Request Message
| 이슈 | 내용 |
|---|---|
| 🚀API | API 관련 |
| 🤬BugFix | 버그 발견 |
| 🎨CSS | 스타일링 관련 |
| 🖥Deploy | 배포 관련 |
| 📓Docs | 문서 작성 관련 |
| 🌟Feat | 기능 개발 |
| ❗Issue | 이슈 관련 |
| ❓Question | 개발 질문 |
| 🏭Refactor | 코드 리팩토링 |
| ⚙Set | 개발 환경 세팅 |
| ✅Test | 테스트 관련 |
Backend Convention
1. 매퍼 → 빌더패턴 지향
@Builder 는 클래스레벨 생성자 메서드 레벨에서사용
- 생성자별로 설정되는 멤버변수 내용을 정의하고 생성자에 @Builder를 설정하게되면 해당 생성자를 사용하는 Builder가 생성되어 의미있는 객체만 생성할 수 있게 된다.
- 가독성을 높일 수 있다.
- 객체 생성 시점에 값들을 넣어줌으로써, Setter의 사용을 줄일 수 있게 된다.
2. 엔티티 클래스에서 @Setter 사용지양
- **@Setter를 지양해야하는 이유**
- Setter를 사용하면 의도가 불명확하고 변경하면 안되는 중요한 값임에도 불구하고 변경 가능한 값으로 착각할 수 있다. (== 안정성 보장이 안된다.)
- 무분별한 변경으로 객체의 일관성을 보장하기 어렵다.
- 빌더 패턴 사용
- 팩토리 메서드 사용
3. @NoArgsConstructor(access = AccessLevel.PROTECTED)
- 사용이유 : 기본 생성자의 접근 제어를 PROCTECTED 로 설정해놓게 되면 무분별한 객체 생성에 대해 한번 더 체크할 수 있는 수단이 되기 때문
- 객체의 일관성을 유지가능
4. 컨트롤러, 서비스 클래스에서 CRUD 메서드는 동사형으로 사용
Controller
- 목록조회 : 00List()
- 상세조회 : 00Details()
- 등록만 : Create()
- 수정만 : Update()
- 삭제만 : Delete()
Service
- 목록조회: get00List()
- 상세조회: get00()
- 등록: create00()
- 수정: update00()
- 삭제: delete00()
5. 다른 팀원이 내 코드를 보고 이해할 수 있도록 주석 상세하게 달기
/**
*전체 게시물 조회
*@parampostGet현재 유저가 보고있는 게시물의 마지막postId를 담고있는 객체
*@param pageable default page = 0, size = 4
*@return최신순으로 페이지네이션된 게시물 목록
*/
@GetMapping
public ResponseEntity<MultiResponse<?>> getList(
@ModelAttribute PostGet postGet,
@AuthMember MemberDetails memberDetails,
@PageableDefault(size = 4) Pageable pageable) { ... }
백엔드 개발자