비즈니스 측에서 기능 이름 변경을 요청하는 경우가 있습니다. 크게 보면 이 작업에는 2가지 접근 방식이 있으며, 두 방식은 기본적으로 즉각적인 작업량과 미래의 복잡성/버그 위험 사이에서 트레이드오프 관계에 있습니다:

• 완전 변경(Complete): 리포지터리의 모든 항목을 이름 변경합니다.

장점: 코드 복잡성이 증가하지 않습니다.

• 단점: 실행 작업량이 많고, 즉각적인 버그 위험이 높습니다.

• 파사드(Façade): 가능한 한 최소한으로 변경합니다. 인터페이스, 문서, 오류 메시지 등 사용자에게 노출되는 콘텐츠만 변경합니다.

장점: 실행 작업량이 적습니다.

• 단점: 코드 복잡성이 증가하여 미래 버그 위험이 높아집니다.

파사드 방식을 선택해야 하는 경우#

다음 조건 중 해당하는 항목이 많을수록 파사드 방식을 선택하는 것이 좋습니다:

• 새 이름이 영구적이라는 확신이 없는 경우.

• 해당 기능이 버그에 취약한 경우(규모가 크거나, 복잡하거나, 리팩토링이 필요한 경우 등).

• 이름 변경을 리뷰하기 어려운 경우(기능이 많은 줄, 파일, 또는 리포지터리에 걸쳐 있는 경우).

• 이름 변경이 어떤 방식으로든 영향이 큰 경우(데이터베이스 테이블 이름 변경 등).

파사드 우선 방식 고려#

파사드 방식이 반드시 최종 단계일 필요는 없습니다. 이후 반복 작업에서 완전한 이름 변경을 완수하는 첫 번째 단계로 취급할 수 있으며, 실제로 그렇게 하는 것이 좋습니다(should).