1. 커밋을 잘 쪼개자
의미있는 단위로 커밋하기. 나중의 내가 알아볼 수 있고, 다른 사람도 알아볼 수 있도록.
2. 리뷰어를 위해 PR에 설명을 달아두자
대개 리뷰어는 코드를 작성한 사람에 비해 컨텍스트가 부족하기 때문에, 양질의 리뷰를 위해 리뷰어에게 배경을 설명해주는 것이 좋다.
3. 스프링 의존성을 주입받을 때는 생성자로
스프링 팀에서는 의존성 주입 시 constructor를 통해 주입받는 것을 권장하고 있다.
그 이유는
1. 순환 참조를 (컴파일 시점에) 방지할 수 있다. 생성자 주입은 빈을 생성한 후 의존성을 주입하는 세터 주입, 필드 주입과는 다르게 객체를 생성하는 시점(생성자)에 필요한 빈을 주입한다.
2. 테스트에 용이하다. DI의 핵심은 관리되는 클래스가 DI 컨테이너에 의존성이 없어야 한다는 것이다. (생성자 주입 사용 시 @Mock, @Spy 없이 매우 간단하게 테스트 코드를 만들 수 있다.)
3. 코드가 더러워지는 것을 막는다. (생성자 주입을 사용할 경우 의존성이 명시적으로 드러난다.)
4. 불변성(immutability)을 보장한다. 필드 주입과 수정자 주입은 해당 필드를 final로 선언할 수 없지만, 생성자 주입은 가능하다.
5. 오류를 방지할 수 있다.
https://madplay.github.io/post/why-constructor-injection-is-better-than-field-injection
4. 서버를 띄우기 위한 설정파일(application.yml)의 가이드를 적어두자
spring:
datasource:
url: jdbc:h2:mem:testdb
username: sa
password: password
driver-class-name: org.h2.Driver
jpa:
database-platform: org.hibernate.dialect.H2Dialect
open-in-view: false
show-sql: true
hibernate:
format_sql: true
ddl-auto: update보통 .gitignore에 설정파일을 추가해 깃헙에는 들어가지 않는다.
README.md 등에 설정 파일 가이드를 적어주자.
+ 실행시 profile을 다르게 주입해줄 수 있다. 이 기능을 활용하면 여러 환경의 설정(dev, test 등)을 파일로 분리할 수 있다.
5. 클린아키텍쳐
클린 아키텍쳐를 적용하면 서비스와 도메인이 외부의 요소(DB, Open API 등)에 의존하지 않고도 실행을 잘할 수 있고, 테스트도 가능해진다. 외부 인프라적인 요소가 정해지지 않은 상황에서 어떻게 하면 도메인 로직을 개발할 수 있을지 고민해보자.
도메인과 엔티티를 분리해보자.
6. PUT과 PATCH
PATCH는 일부 필드 수정에만 쓰이고, PUT은 전체 수정에 쓰인다.
일반 게시물 수정의 경우에는 PUT이 더 잘 어울릴 것이다.
7. Controller 메서드 이름은 비즈니스적으로
post, patch 등으로 시작하는 이름은 구체적으로 REST에 종속적인 이름이므로,
비즈니스적으로 어떤 동작을 하는지가 조금 더 드러나면 좋다.
ex) postPosting -> createPosting, patchPosting -> updatePosting
8. 커스텀 Exception을 사용하자
service단에서는 직접 정의한 exception을 throw 해주는 게 좋을 것 같다.
나중에 프로젝트가 커지면 Exception의 종류도 다양해지니, 어떤 기준으로 그룹핑하고 관리할 것인지도 고민해보자.
9. 주석 등은 사유를 달아놓을 것
불필요한 코드(주석 등)는 main에 머지하지 않는 게 좋음.
만약 수정이 필요한 경우라면 FIXME, TODO 등의 라벨과 사유를 함께 적어 추후 관리가 쉽게 하기.
보통 Feature 개발에 시간을 쓰다 한참 지나서 이게 왜 있는 주석인지 까먹기 때문.
화이팅!!!
