코틀린 + 스프링 조합을 사용하면서 느낀점안드로이드는 코틀린이 이미 대세로 자리잡은지 꽤 되었지만.. 백엔드는 아직 자바+스프링 조합이 훨씬 많이 사용되는 것 같다.최근 유니콘 기업들이 신규 프로젝트를 코틀린+스프링 조합으로 진행하는 것을 보고 따라써봤다.사실 예전에는
DB에서 값을 조회할 때 조회 조건이 동적으로 바뀌어야 하는 경우가 종종 있다.SQL 쿼리를 이용해 조회할 때 주로 when/case 등의 문법을 사용하여 해결하는 경우가 있는데.. 개인적으로 when/case 문은 안티패턴이라고 생각한다.. (SQL을 너무 복잡하게
try/catch 블록은 원래 추하다. 코드 구조에 혼란을 일으키며, 정상 동작과 오류 처리 동작을 뒤섞는다. (클린코드)위와 같이 try-catch를 반복적으로 사용하는 경우 내 손가락도 아프고.. 가독성도 떨어진다.. 스프링의 @ControllerAdvise 를 이
실무에서 엔티티를 생성하다보면 auddit(감사) 목적으로 거의 모든 엔티티에 들어가는 필드(컬럼)들이 있다. 일일이 작성하기 매우 귀찮은데.. Spring Data Auddit 기능을 활용하여 귀찮을 일을 줄일 수 있습니다..Spring Audit 기능을 활용하기 위
엔티티를 작성할 때 제가 생각하는 몇가지 원칙이 있습니다.그중 엔티티(객체)의 Setter 사용 금지 원칙(?) 에 대해 알아보겠습니다.엔티티를 작성할 때 습관적으로 모든 필드에 setter를 생성하는 경우가 있습니다.하지만 Setter를 무분별하게 남용하다 보면 여기