최근 소셜 로그인 구현 코드를 리팩토링하는 과정에서 SOLID 원칙을 조사하고 적용해보았습니다. 따라서 이번 포스팅에서는 SOLID 원칙 설명과 리팩토링 과정을 정리하고자 합니다. 💡 배경 & 문제 인식이전에 소셜(카카오) 로그인 API를 서버측에 구현했는데, 문득 서비스에 새로운 소셜 로그인이 추가될 경우 현재 코드 설계는 적합하지 않다고 판단했습니다. 그 근거는 아래와 같습니다. 위의 UML 클래스 다이어그램은 기존 카카오 소셜 로그인 기능의 설계 구조입니다. 우선 소셜 로그인에 사용되는 객체가 모두 구현체로 정의되어 있는 것을 확인할 수 있습니다. 즉, 만약 서비스에 새로운 소셜 로그인이 추가되는 경우에 해당 소셜 로그인에 알맞는 컨트롤러 구현체, 서비스 구현체를 그때그때 구현해야 한다는 것입니다..

이번 방학부터 자바 Spring을 학습하면서 프로젝트에 내용을 하나씩 적용해보고 있는데, 이 과정에서 첫 번째로 마주친 문제는 N+1 문제이다. 이번 포스팅에서는 N+1 문제가 무엇이며 왜 발생하는지를 알아보고, 이를 해결하기 위한 방안들과 그 중에서 어느 해결법을 적용했는지 기록하고자 한다.  📋 문제 상황현재 프로젝트에서 Scrap 객체와 Dataset 객체는 아래와 같이 다대일 관계를 갖고 있다. // domain/Scrap.java@Entity@Getter@Builder@AllArgsConstructor@NoArgsConstructorpublic class Scrap { // ... @ManyToOne(fetch = FetchType.LAZY) @JoinColumn(na..