Refactoring - 리팩토링 관련 문제들

리팩토링을 진행하는 것도 좋지만, 리팩토링으로 인해 발생할 수 있는 문제점들 혹은 리팩토링이 어려운 상황에 대해 알아두는 것도 중요하다.

리팩토링으로 인해 발생할 수 있는 문제점들...

- 데이터 베이스

리팩토링에서 문제가 되는 부분 중 하나가 바로 데이터 베이스이다. 많은 비즈니스 어플리케이션은 바탕이 되는 데이터 베이스 스키마와 강력히 결합되어 있다. 이 때문에 데이터 베이스 수정이 어려워진다.

아무리 데이터 베이스 스키마와 객체 모델의 상호 의존성을 최소화하려고 시스템을 꼼꼼하게 계층 구조로 제작했더라도, 데이터 베이스 스키마를 수정하면 데이터도 이전해야 하는데, 이것은 시간도 오래 거릴 뿐 아니라 위험성도 높다.

이 문제를 해결하기 위해서 객체 모델과 데이터 베이스 모델 사이에 별도의 소프트웨어 계층을 두는 방법이 있다.

이렇게 하면 두 모델에 생긴 변경 사항을 따로 유지할 수 있어서 한 모델을 수정할 때 다른 모델은 수정할 필요 없이 그저 중개 계층만 수정하면 된다. 

- 인터페이스 변경

객체의 중대한 장점 중 하나는 인터페이스를 건드리지 않고 내부의 구현 코드를 수정할 수 있다는 점이다.

객체를 이용하는 부분을 수정하지 않고도 객체의 내부 구조를 안전하게 수정할 수 있지만, 인터페이스를 수정하면 어떤 문제가 발생할지 알 수 없으므로 인터페이스를 건드리지 않는다는 것은 큰 장점이다.

리팩토링에서 불안한 점은 상당수의 리팩토링이 인터페이스를 수정한다는 것이다.

함수명 변경도 그 자체가 인터페이스를 수정하는 작업이다.

특히, 이미 배포를 한 프로그램이고 내부 함수명을 수정했다면 그 인터페이스를 사용하는 측에서도 수정을 해야하므로 더 복잡하게 수정해야만 할 수도 있다.

위 문제를 해결하기 위해선 기존 인터페이스가 새 인터페이스를 호출하게 수정하면 간단하게 해결이 된다.

리팩토링을 하면 안되는 상황.

- 코드를 처음부터 새로 작성해야 할 때

코드가 돌아가지 않는다면 그건 완전히 새로 작성을 하라는 신호이다. 테스트만 하려다 코드가 버그 투성이라 안정화할 수 없음을 알게 될 경우가 바로 그 때이다. 

코드가 제대로 돌아가는 것이 가장 중요하다. 리팩토링은 그 이후의 일임을 반드시 명심하자.

- 납품일이 임박했을 때

납품일이 가까운 시점에 리팩토링을 해봤자 그로 인한 생산성은 납기가 지난 후에나 가시화될 테니 쓸데 없다.

하지만, 납품일이 임박한 경우가 아니면 시간이 없다는 핑계로 리팩토링을 미루면 안 된다.