리팩토링 '빅뱅' 금지
회원 정보를 담은 엔티티인 member 에서 정규화 명목으로 MemberAddress 를 만들어뒀으나 활용도가 낮아 다시 address 필드로 통합하는 리팩토링을 시도했다.
member 엔티티는 다른 도메인에서 두루 참조하고 있었기 때문에 해당 코드들에서 다량의 컴파일 에러가 발생했다. 사전에 이를 고지했고 당초 10분 미만 작업으로 해결할 수 있을것으로 낙관했으나 후속작업이 지체돼 프로젝트 일정 전체에 악영향을 줄 것이란 불안감이 커졌고 결국 작업을 원상 복구했다.
결론적으로 리팩토링을 너무 우습게 봤다는 생각이 든다.
찾아보니 이런 방식을 ‘빅뱅’ 방식이라고도 하며 매우 무식한 방법이라고 한다.
미니 프로젝트였으니 망정이지 대형프로젝트였다면 예측하지 못한 사이드 이펙트가 많아질 수 있고 롤백도 어려워질 수 있다.
TODO = '사전영향 분석' & '점진적 리팩토링'
사전 영향 분석:
참조하는 코드의 목록을 파악해 작업량을 예측한다.
점진적 리팩토링:
기존 시스템을 유지하면서 새로운 구조를 점진적으로 도입하고, 최종적으로 기존 구조를 제거한다.
예를 들어 삭제대상인 MemberAdress를 유지하고, Member에 칼럼만 추가해 두가지 로직이 모두 가능하게 해두고 차차 참조를 줄여 memberAdress가 필요없게끔 만든 뒤 리팩토링을 완성했다면 피해가 없게 된다.
1단계 (확장): 기존 MemberAddress를 유지한 채 Member 엔티티에 String address 필드 신규 추가.
주소 저장 및 수정 로직을 변경하여 MemberAddress와 Member.address 두 곳에 모두 데이터를 쓰는 '이중 쓰기' 구현.
2단계 (전환): 주소 조회 로직을 Member.address를 우선적으로 읽도록 수정.
새 필드가 null일 경우에만 기존 MemberAddress를 읽는 '폴백' 로직 적용.
과거 데이터 이관을 위한 일회성 마이그레이션 스크립트 실행.
3단계 (정리): 데이터 이관 완료 후, '폴백' 및 '이중 쓰기' 로직 제거.
더 이상 참조되지 않는 MemberAddress 엔티티와 관련 파일을 최종적으로 안전하게 삭제함.
'error note' 카테고리의 다른 글
| 구글클라우드 결제계정 생성시 '유효하지 않은 전화번호' 오류 해결 (0) | 2025.09.18 |
|---|---|
| 플러터 안드로이드 버전 호환문제 해결방법 (0) | 2025.08.19 |
| 앓던 이가 빠지다. 톰캣 multipart 개수 제한 문제 (2) | 2025.07.24 |