.png&blockId=3197e115-ee0d-4d9c-9f5d-4b57cb28634e)
Table
Search
잠죽조(잠은죽어서자조) 의 코드스타일 및 코드리뷰 방식에 대해 소개합니다!
Common Rule
Commit은 특정 기능의 구현마다 한 번 씩 나누어서 진행합니다!
Commit은 Commit Convention 을 지키며 Commit 합니다!
서로의 의견을 존중하는 문화를 가집니다! 따라서 딱딱한 어투보다는 부드럽게~!
코드의 정답이 아닌 참고 자료나 생각해 볼 수 있는 글을 첨부합니다!
자신의 코드를 누가 봐도 이해할 수 있는 클린한 코드, 가독성이 좋은 코드를 지향합니다!
우리 팀의 1인당 코드 리뷰 최소 시간은?
15 분 정도 팀원의 코드를 살펴본다.
이 때 이해가 안되는 부분이 있다면 빠르게 물어본다!
10 분 정도 리뷰를 작성한다. ( 필요한 참고 자료는 많은 수록 )
) Code Style
Code Naming Rules
Java
•
Variable
◦
Camel Case
→ Ex) String camelCase;
•
Class Name
◦
Pascal Case
→ Ex) String Pascal Case;
Da taBase
•
Colume
Spring JPA
•
Snake Case
→ Ex) String snake_case;
@Entity
public class
@Column(name = "user_name")
String userName; // -> user_name
Java
복사
QueryDSL
Commit Convention
Commit Type
Tag Name | Description |
Feat | 새로운 기능을 추가 |
Fix | 버그 수정 |
Design | CSS 등 사용자 UI 디자인 변경 |
Style | 코드 포맷 변경, 세미 콜론 누락, 코드 수정이 없는 경우 |
Refactor | 프로덕션 코드 리팩토링 |
Comment | 필요한 주석 추가 및 변경 |
Docs | 문서 수정 |
Test | 테스트 코드, 리펙토링 테스트 코드 추가, Production Code(실제로 사용하는 코드) 변경 없음 |
Chore | 빌드 업무 수정, 패키지 매니저 수정, 패키지 관리자 구성 등 업데이트, Production Code 변경 없음 |
Rename | 파일 혹은 폴더명을 수정하거나 옮기는 작업만인 경우 |
Remove | 파일을 삭제하는 작업만 수행한 경우 |
Code Review Rule
PR Creater
•
PR Template에 따라서 작성합니다.
•
코드 리뷰어가 참고할만한 메모를 작성합니다.
•
궁금한 점이 있었다면 포함해서 작성합니다.
Code Reviewer
•
반영 유무 : 반영 해도 될지 안될지를 작성합니다.
•
복잡성 : 어떡하면 더 구조를 단순화 시킬 지에 대한 내용을 작성합니다.
•
해당 코드에 대한 의견, 수정해야 할 부분이 있다면 해당 내용을 작성합니다.
•
해당 코드에 대해서 궁금한 점이 있다면 작성합니다.
ToDay Code Review
@Setter 및 @Builder @Allargsconstructer 에 대해서
Setter 의 사용은 지양하자 라는 말은 많이 들어보셨을텐데,
왜 사용을 지양해야되는지에 대해서 알아보고
어떤 부분에 있어서 Lombok의 사용을 지양해야하는 건지에 대해서
이번 프로젝트를 진행하는데 있어서 실제로 적용을 하면서 왜 사용을 지양해야 하는지에 대해서
직접 알아봤습니다!
실제로 적용해본 내용을 간단하게 요약하겠습니다.
Setter의 사용을 지양함으로써 개발자가 의도하지 않은 Data의 변경을 막을 수 있었습니다.
그리고 NoArgsConstructor에 (access = protected )의 사용과
Builder를 Class에 직접 사용하지 않게 되면서
그에따라 AllArgsConstructor 또한 사용할 수 없었습니다.
이 부분 또한 Builder의 간편한 사용의 장점을 포기하고 개발자가 의도한 Constructor만 생성해서
해당 Constructor위에 Builder Annotaion을 붙임으로써 의도치않은 Constructor생성을 막고,
Builder의 사용은 가능하게 해서 어느정도의 코드 작성의 편의성은 가져갈 수 있었습니다.
하지만, 코드량이 많아지는 것은 어쩔 수 없을 것 같습니다.
그리고 해당 내용을 모르는 분이 본다면 왜 이렇게 사용했지? 라는 의문이 들 수 있어서
코드의 가독성은 조금 떨어질 수 도 있겠다 라는 생각을 하게 됬습니다!
@Lombok의 @Data Annotation
Unit Test Annotation에 대해서
@SpringbootTest
통합 테스트를 진행하는데 사용하는 Annotation입니다.
실제 운영 환경과 똑같은 환경을 구성해주기 때문에 모든 Bean을 등록해 테스트를 진행합니다.
따라서 Unit Test 와 같이 기능 검증을 위한 테스트가 아니라
전체적인 Program의 동작을 확인하는데 사용합니다.
@DataJpaTest
Data Layer의 Unit Test를 진행하기 위한 Annotation입니다.
기본적으로 DataJpaTest에는 @Transactional Annotation이 적용되어 있어서
영속성 테스트에는 반영되지만, 실제 쿼리는 실행되지 않는 상태를 유지하며 테스트를 진행할 수 있습니다.
