밀접하게 연결된 클래스를 리팩토링하는 방법은 무엇입니까?

Question

나는 밀접하게 결합 된 큰 응용 프로그램을 리팩터링하고 더 정비 가능하고 유연하게하려고 노력 중입니다.

많은 단위 테스트가 있으므로 단계별로 리팩토링을 수행하겠습니다.

어떤 디자인 &이 작업을 수행하기 위해 리팩터링 패턴을 구현/적용해야합니까?

좀 생각할 수 :

• Extract Interface
• Extract Method
• Dependency Injection

는 또한 자신의 경험과 리팩토링 작업의 이런 종류의 모범 사례를 공유 할 주시기 바랍니다.

UPDATE

나는이 리팩토링 because of the reasons explained in this question을 수행하고있다. 기본적으로 나는 인터페이스의 몇 가지를 추출하지 않고 플러그인 시스템을 구현할 수 없으며 이러한 인터페이스는 순환 참조 문제없이 컴파일하기 위해 40 개 이상의 DLL에서 응용 프로그램을 분리해야합니다.

Answer 1

모든 답변을 주셔서 감사합니다. 여러 가지 방법으로 어려움을 겪은 후 가장 좋은 방법은 모든 것을위한 인터페이스를 만드는 것이 었습니다. 이 덕분에 디자인을 자유롭게 변경할 수 있었고 하루 만 빌드를 중단 할 수있었습니다 (프로젝트가 컸기 때문에 하루에 너무 많은 참조와 단위 테스트 + 일부 리팩토링을 수정해야하기 때문에).

모든 인터페이스를 추출하고 수정 한 후 별도의 솔루션을 만들어서 자유롭게 디자인하여 재생할 수 있습니다.

기본적으로 첫 번째 이동은 모든 것을 인터페이스로 옮긴 다음 내부 종속성을 제거하려고해야한다고 생각합니다.

Answer 2

리팩토링은 특히 밀접하게 결합 된 시스템에서 가볍게 취하지 않아도됩니다. 그것은 종종 수행되기 전에 보람있는 작업처럼 보일 수 있지만, 내 경험으로 볼 때, 일단 기존의 문제를 해결하는 것보다 새로운 버그를 소개 할 가능성이 높아지기 때문에 곧 시작되면 부담이 될 수 있습니다.

주요 리팩터링을 시작하기 전에 새로운 제품을 처음부터 새로 만들거나 즉시 필요한 부분 만 리팩터링하는 등의 이점과 개선점을 고려해야합니다. 시작하기 전에 아키텍처, 역할 및 책임에 대해 잘 알고 있어야하며, 예상치 못한 기존 행동을 통해 깨 졌을 때 알 수 있어야합니다.

또한 리팩터링 후 어떻게 될 것인지 디자인하고 현재 구현에 매핑하여 어떻게 유지할 수 있는지 유익합니다. 가능한 한 자주 회귀 테스트를 실시해야합니다.

디자인이 리팩토링을 분명히 필요로 할 때 완벽 주의자에게 좌절 할 수 있지만 때로는 변경의 비용/이점을 고려해야하며 전투를 양보해야합니다. 변경해야 할 경우주의 깊게 밟고 한 번에 너무 많이하려고하지 마십시오.

Answer 3

인터페이스에 대한 리팩토링과 종속성 삽입이 커플 링을 줄이는 데 핵심이 될 것입니다. 또한 종속 오브젝트 작성을 위해 팩토리 사용을 고려할 수도 있습니다.

Answer 4

이것은 큰 질문이며 전체 책을 답변으로 쓸 수 있습니다. 다행히도, 누군가 이미 있습니다. Michael Feathers의 레거시 코드과 함께 효과적으로 작업하십시오. 그것은 당신의 질문에 대답하는 데 전적으로 헌정 된 책입니다.

정말 좋은 책입니다.나는 그곳에 확실히 코드 완성, 디자인 패턴 및 Pragmatic Programmer을 모든 개발자의 라이브러리에 있어야합니다.

Answer 5

위의 모든 항목과 일부 항목.하지만 그 중 하나를 시작하기 전에 큰 그림을 생각해 보겠습니다. 프로그램의 섹션 (패키지, 프로젝트 등)을 정의한 다음 기능을 이동시켜 적절한 패키지에 배치 할 계획을 세우십시오. 그렇다면 모든 것이 논리적으로 패키지 추출을 시작하기 위해 추출 인터페이스, 종속성 주입 및 팩토리 메소드를 사용해야하는 곳입니다.

Answer 6

Phlip에서 훌륭한 조언 : Refactor the Low-hanging Fruit

나는 그것이 훨씬 더 많은 정보없이 특정 경우에 적합한 특정하는 리팩토링 말을 아주 열심히 생각합니다.