(3) 리팩토링의 문제와 해결 그리고, 적용범위

리팩토링의 문제 및 해결.

=> 문제 : 데이터베이스(DB)의 변경

많은 비지니스 로직들은 DB 스키마와 매우 의존적이다.

- 이 문제 해결을 위해서는 호환 객체(Adapter)를 이용하는 것을 고려한다.

- 호환 객체의 호환 부분만 수정하면, DB 에 덜 의존적일 수 있다.

해결 : 호환객체는 DB의 의존을 최소화

=> 문제 : 메소드 서명의 변경 (디스크립터 변경)

이미 많은 곳에서 메소드가 사용되어, 모든 서명을 변경하기가 쉽지 않다.

- 오버로드를 이용하는 방식

(1) 기존 서명을 남기고, 새 서명을 가진 메소드를 제작한다.

(2) 기존 서명은 새 서명을 가진 메소드를 호출하도록 변경한다.

- 경우에 따라서는 기존 서명을 사장(Deprecated) 시켜놓을 방법도 있다.

사장을 결정할 시, 사장이유 및 해결에 대한 Document 를 남긴다.

해결 : 구 서명은 새로운 서명을 사용.

리팩토링을 하지 말아야 할 때

1) 리팩토링 대신에 다시 작성하는 것이 좋은 경우가 있다.

리펙토링이 어려운 설계를 변경해야할 경우가 발생할 수 있다.

- 설계가 크게 변경된다면, 재작성이 더 좋은 경우가 존재한다.

주의 : 단, 대부분의 기능이 정상적으로 작동을 해야한다.

제안 : 현재 로직을 세부 컴포넌트로 분리하고, 리팩토링할 것을 고려해야된다.

단! 휴지통에 버리기 전에 재활용은 해야 한다!!

2) 마감시간이 다 되었을 경우.

고객과의 약속이 더 중요. (약속을 지킬 수 있는 방향으로 가야함)

설계도 중요하지만, 기간도 맞춰야된다.(비즈니스 이해관계)

마치며...

간단하게 정리한 리팩토링입니다. 경험과 이전에 공부했던 자료를 이용하여 포스팅하였는데, 조금 더 공부하고 여러 프로젝트를 하면서 적용해보면서 훨씬 좋은 내용으로 업데이트 할 계획입니다.

읽어주셔서 감사합니다.