Refactoring

들어가며 현재 서비스중인 AuthService가 387줄의 거대한 God Object로 성장해버렸다. 로그인, 회원가입, 소셜 로그인, 이메일 찾기, 비밀번호 변경 등 인증 관련 모든 기능을 한 클래스에서 처리하다 보니 테스트도 어렵고 수정할 때마다 긴 코드를 찾아봐야 하다보니 유지보수에 있어서 너무 불편했다. 이를 SRP 원칙에 따라 3개 서비스로 분리하고, Facade 패턴으로 재구성한 과정을 기록했다. 문제 상황 God Object가 된 AuthService AuthService - 387줄 - 의존성: 11개 - 담당 책임: 6가지 1. 로그인/로그아웃 (토큰 관리) 2. 회원가입 (검증 + 외부 API + DB 저장) 3. 소셜 로그인 (카카오/구글/네이버) 4. 이메일/전화번호 찾기 5. 이메일 인증 발송/확인 6. 비밀번호 변경 한 클래스가 6가지 책임을 가지고 있고 명백한 SRP 위반이다. ...

들어가며 현재 사내에서 서비스중인 앱의 백엔드 코드에서 중복되는 코드가 심하게 일어나는 부분이 있었다. 회원과 관련된 추가정보(경력, 학력, 논문 등)들이 총 7개가 있는데 이 7개의 도메인들의 CRUD 로직이 100% 동일하다는 것에 템플릿 메서드 패턴을 적용하여 리팩토링을 해보면 어떨까 생각이 들었다. 추가정보 도메인 총 7개의 기존 서비스 로직의 코드 라인에는 생성, 조회, 리스트조회, 수정, 일괄 수정, 삭제, 일괄 삭제, 소프트 삭제, 삭제복원을 포함하여 약 210줄의 코드가 동일한 로직으로 중복되고 있었다. 문제 상황 분석 중복 코드의 심각성 7개의 서비스 클래스가 거의 동일한 구조를 가지고 있었다. 예를 들어 경력(Career) 서비스와 학력(Education) 서비스를 비교해보면 다음과 같았다. ...