Java Spring 으로 백엔드 개발 시 지양해야할 코딩 패턴:

 

#0. 개요

💡 java spring 으로 프로그래밍 하면서 마주친 몇 가지 간단한 지양하면 좋은 개발 코드 패턴.

 

• 심심치 않게 개발을 하다 보면 아 이런거는 사용하지 않는 게 좋다라고 다들 한 번쯤은 들어봤을 거다.
  • 그래서 이런 포인트들을 간추려 정리하였다.

#1. 쿼리 조회 시 * 사용 지양

• 쿼리 조회 시 필요한 컬럼만 뽑는 것이 좋다.
  • * 로 모든 컬럼값을 불러와서 subquery 등을 구성할 경우 DB는 당연히 더 많은 cost 가 발생한다.

  SELECT * FROM users;
  
  SELECT id, name FROM users;
  

#2. println() 사용 자제

• 참조:
  • https://velog.io/@destiny1616/System.out.println-%EC%82%AC%EC%9A%A9%EC%9D%84-%EC%9E%90%EC%A0%9C%ED%95%B4%EC%95%BC-%ED%95%98%EB%8A%94-%EC%9D%B4%EC%9C%A0�%[…]EC��해야-하는-이유
• 로깅 프레임워크를 사용하면 좋은 점
  • 로그 레벨을 사용한 정보 분리 가능
    • 제공되는 로그레벨:
      • FATAL
      • ERROR
      • WARN
      • INFO
      • DEBUG
      • TRACE
      • ALL
  • 성능이 좋다
• 기존 println() 사용하면 안 좋은 점
  • 정보 분리가 안 됨
    • 해당 메서드는 에러 로그를 2가지로만 분리가 가능
  • 시스템 콜을 호출하기에 성능이 좋지 않음

#3. e.printStackTrace() 지양

• 참고:
• https://dev-jwblog.tistory.com/167
• 성능 문제
  • 해당 메서드는 너무 많은 줄의 에러 로그를 출력 함. ( 불필요한 부분까지 전부 )
  • system.err 이기에 리소스가 비쌈
• *log*.error("Exception : {}", e.getStackTrace()[0]);
  • 로 대체

#4. setter 대신 builder

• 참고
  • https://velog.io/@hope1213/Setter-사용을-왜-지양해야할까
• setter 지양이유
  • 객체 일관성을 유지하기 어려움
  • set 메서드를 호출한 곳에서 어떤 의도로 데이터를 변경하였는 지 명확히 알기 힘듦
• 대신 builder().build() / toBuilder().build()
  • 전자는 Dto class로부터 호출 가능하고, 아예 새로운 객체를 처음부터 선언하여 반환
    • 생성자 호출과 크게 다르지 않음
  • 후자도 새로운 객체를 반환하지만, 객체의 메서드로써, 기존 다른 객체에서 메서드로 호출하면, 해당 객체의 property 를 그대로 이어 받아서 새로운 객체를 반환
    • toBuilder() 와 build() 사이의 property 를 새로 정의 해줄 수 있음