패키지 구조 재편과 Service를 Util로 전환한 리팩토링 가이드
목차
docs: 패키지 구조 및 Mapper XML 위치 규칙 문서화
리팩토링은 기능 변경 없이 코드 품질을 올리는 작업임. 이번엔 패키지 구조 정리와 Service 계층을 Util 방식으로 전환하는 게 핵심이었음.
패키지 구조 재편
기존: 기능별 패키지 내 Controller/Service/Mapper 혼재
개선: Controller(web)와 Util(utl)만 존재
Service를 static Util로 전환한 이유:
- 단일 진입점이 명확해짐
- 의존성 주입 복잡도 감소
- 단위 테스트 작성 용이
전환 단계
| Phase | 대상 | 내용 |
|---|---|---|
| 1-1 | 독립 Service 6개 | 의존성 없는 것 먼저 |
| 1-2 | 중간 의존성 4개 | 1-1 완료 후 |
| 1-3 | 핵심 금융 Service 3개 | 마지막으로 신중하게 |
| 2 | XML 정리 | 죽은 XML 제거 |
리팩토링 중에 기능이 깨지면 안 됨. 각 단계마다 빌드 후 다음으로 넘어감. 커밋도 단계별로 분리해서 롤백 용이하게 유지함.
리팩토링 시 주의사항
리팩토링은 기능을 바꾸지 않는 게 원칙임. 같은 동작을 더 읽기 좋은 코드로 표현하는 것.
| 좋은 리팩토링 | 나쁜 리팩토링 |
|---|---|
| 중복 코드 메서드 추출 | 동시에 기능 변경 |
| 변수명 의미있게 변경 | 테스트 없이 진행 |
| 복잡한 조건식 단순화 | 한 번에 대규모 변경 |
코드 리뷰 부담을 줄이려면 리팩토링 커밋과 기능 변경 커밋을 분리하는 게 좋음.
끝
댓글 0
첫 댓글 달아줘.