스프링 개발자가 가장 많이하는 실수

이 글은 스프링 공식 팟캐스트를 번역한 내용이다.

 

[Sping Office Hours - 스프링 개발자가 가장 많이하는 5가지 실수]

https://www.youtube.com/watch?v=nd5JzDIEI6A

[예제코드] 

https://github.com/danvega/spring-common-mistakes

 

 

1. DI 할때 필드 주입(@Autowired) 대신 생성자 주입을 사용한다.

• 필드 주입은 테스트에서 Reflection이나 Mock할때 issue를 만들 수 있다.
  • 생성자 주입을 사용하면 이러한 이슈를 방지할 수 있다.
• 생성자 주입을 사용하면 순환 참조같은 상황을 catch 할 수 있다.
• @Autowired를 사용해야한다면 Test 코드에서만 사용하자

스프링 오피스 아워 한 장면

2. 패키지 구성시 package by layer 대신 package by feature를 고려하자

읽어보면 좋은 글 : https://phauer.com/2020/package-by-feature/

• package by layer로 프로젝트를 구성하면 package에서 제공하는 캡슐화 기능을 포기하게 된다.
• package by feature로 프로젝트를 구성하면 취할 수 있는 장점이 더 크다.
  • class를 기본 public으로 만드는 경우가 있는데 그러지말고 패키지별로 의존성이 관리되게 해보자

Package By Layer

package by feature

3. 기술을 도입할때는 팀원들의 상황을 고려하자

• Hibernate를 모르는데 JPA를 사용하는 것은 잘못된 기술 선택일 수 있다.
• 새로운 기술이 등장해서 도입한다고 할때 team의 누가 support할 것인가.
• 팀이 다 같이 아는 기술을 사용하거나 익숙해질 때까지 누군가 support를 해야한다.

 

4. 표준을 따른다.

• RESTful API URL 명명
• 일관된 응답구조
• 표준을 따라야 읽는 사람이 어떤 부분을 찾아서 읽을지 찾기 쉽다.

 

5. 테스트를 작성하자

• API, 클래스 설계에 대한 피드백을 빨리 얻을 수 있다.
• 단, 테스트 커버리지에 집착하지 말아라 

 

6. 예외처리

• 클라이언트에게 구체적인 예외를 주자
• ex) /customers/68 → 500 error vs /customers/68 → 404 Not Found, user not found UserId = 212
• 서버에서 받은 data는 반드시 validate(유효성 검사) 해야한다.

 

7. Interface 사용을 boilerplate 처럼 쓰지 말기

• 인터페이스 축출이 필요한 상황에는 IDE가 알려준다.
• 필요할때만 사용하도록 하자

 

8. Dependency의 버전/이슈를 주기적으로 관리하자