방탈출-싸이클1 리팩터링1

대상: (예: OrderService, 결제 모듈, API 응답 구조 등)

언어 / 프레임워크:

1. 개요

2. 문제 인식 — 무엇이 문제였나?

현재 코드 혹은 구조에서 느낀 불편함, 버그, 유지보수 어려움 등을 구체적으로 기록하세요.

문제 상황

• 예외 처리가 되지 않아서 존재하지 않는 id에 대해서 등록하거나, 삭제하려고 할 때, 예외를 다루지 않았다.
• repository dao 관련한 이름들이 혼용되어 사용되어 있어서 클래스와 파일들이 이해하기 어려웠다.

문제가 되는 코드 / 구조

// 문제가 있는 코드나 구조를 붙여넣으세요 (코드가 아닌 경우 텍스트로 설명)

문제 유형 체크

• 중복 코드 / 로직
• 불명확한 이름 (변수, 메서드, 클래스 등)
• 단일 책임 원칙(SRP) 위반 — 너무 많은 역할
• 높은 결합도 — 변경 시 여러 곳에 영향
• 낮은 응집도 — 관련 없는 것들이 한곳에
• 확장하기 어려운 구조 (OCP 위반)
• 테스트하기 어려운 구조
• 성능 문제
• 가독성 / 이해하기 어려움
• 기타:

3. 변경 이유 — 왜 바꿔야 하는가?

지금 당장 동작하더라도 왜 바꾸어야 하는지 그 필요성을 설득력 있게 정리하세요.

• 유지보수 측면:
• 확장성 측면:
• 가독성 측면:
• 테스트 용이성 측면:
• 기타 이유:

4. 변경 방향 — 어떻게 바꿀 것인가?

어떤 방식으로 접근할지, 어떤 기법·패턴·원칙을 적용할지 계획을 기록하세요.

접근 전략

• Optional 사용
• JdbcxxxxxxRepository 클래스 네이밍으로 통일

적용할 기법 / 패턴 / 원칙

• 메서드 추출 (Extract Method)
• 클래스 / 인터페이스 추출
• 디자인 패턴 적용 (패턴명: )
• 레이어 / 모듈 분리
• 의존성 역전 (DIP) 적용
• 불변 객체 / VO 도입
• 기타:

변경 후 구조 (다이어그램 or 설명)

5. 변경 결과 — 어떻게 바뀌었나?

변경된 코드 / 구조

// 리팩터링 후 코드나 구조를 붙여넣으세요

Before / After 비교

6. 기대 효과 및 실제 효과 — 무엇이 나아졌나?

예상했던 효과와 실제로 느낀 효과를 구분해서 기록하면 더 좋습니다.

7. 테스트

• 기존 테스트 모두 통과
• 신규 테스트 케이스 추가
• 수동 검증 완료
• 해당 없음

// 주요 테스트 코드 (있을 경우)

8. 회고

배운 점

어렵거나 아쉬웠던 점

다음에 적용해 보고 싶은 것

• [ ]
• [ ]

9. 참고 자료

🗓 마지막 수정: YYYY-MM-DD