팀에 DI 프레임워크 수동 주입으로 바꾼 얘기 (후기 + 반성)
작년에 우리 팀 레거시 코드베이스에서 스프링 의존성 주입을 생성자 수동 주입 방식으로 정리한 작업을 했습니다. 결과만 보면 만족스럽지만, 과정에서 실수한 것도 많아서 기록 삼아 남깁니다.
배경은 이랬습니다. 필드 인젝션이 난무하고 순환 참조가 4~5군데 얽혀 있었고, 테스트 짜려면 컨텍스트를 다 띄워야 했습니다.
진행 순서는 대략 이랬어요.
1. 우선 순환 참조 그래프를 그려서 문제 지점부터 파악 (여기서 2주 날렸습니다)
2. 신규 코드부터 생성자 주입 강제, 기존 코드는 건드리는 김에 정리
3. 테스트가 없는 모듈은 리팩터링 금지 룰 설정
4. 마지막에 필드 인젝션 남은 것들 일괄 정리
반성할 점은 1번에서 시간을 너무 쓴 겁니다. 처음부터 '고칠 수 있는 것만 고치자'로 범위를 좁혔으면 두 달은 아꼈을 것 같습니다. 리팩터링은 언제나 범위를 정하는 게 절반인 것 같아요.
8 개의 답변
ㅇㅈ 범위 정하는 게 절반이라는 말 진짜 공감
필드 인젝션 일괄 정리는 어찌 하셨어요? 저희는 @Autowired 붙은 거 한 번에 지웠다가 부팅 자체가 안 돼서 반나절 날렸는데 ㅠㅠ
반성 파트가 제일 값진 글. 다들 성공담만 쓰는데 2주 날린 얘기까지 써주는 사람 드물어요. 저장해둡니다.
신규 코드부터 강제하는 방식 좋네요. 저희는 반대로 한 번에 다 갈아엎자고 했다가 브랜치 3주 살아있고 리뷰 400줄 되면서 팀 분위기만 상했음 ㅋㅋ
혹시 순환 참조 해결할 때 어떤 패턴 쓰셨어요? 이벤트로 끊으셨는지 인터페이스 분리하셨는지 궁금하네요. 후속 글 기대합니다
순환 참조 그래프 그리는 데 2주는 좀... 솔직히 그거 IDE 플러그인 돌리면 30분이면 나오는 거 아닌가요? 물론 레거시면 예외겠지만ㅋㅋ
저희도 비슷한 작업 했는데, 3번 룰이 제일 중요합니다. 테스트 없는 모듈 건드렸다가 롤백 못 하고 핫픽스 세 번 냈어요. 그 뒤로는 '테스트 커버리지 0인 파일은 손대지 않는다'를 팀 규칙으로 박아놨습니다. 이거 없으면 리팩터링이 아니라 도박임.
글쎄요, 솔직히 이건 좀 회의적입니다. 생성자 주입이 무조건 정답은 아니고, 순환 참조 4~5개 정도면 구조 자체를 의심해야 하는 거지 주입 방식 바꾼다고 해결될 문제는 아닌 것 같은데요. 뿌리는 다른 데 있는 거 아님?