상당히 큰 제품을 가지고 작업하고 있습니다. 닷넷 1.0은 여전히 진행 중이므로 많은 양질의 코드를 가지고 있으며 단위 테스트를 염두에두고 작성되지 않았습니다. 이제 우리는 품질을 향상시키고 각 기능 및 버그 수정에 대한 테스트를 구현하려고합니다. 우리가 지금 가지고있는 가장 큰 문제 중 하나는 의존성 지옥과 신 개체입니다. 특히 하나의 신이 있습니다 : Session. 기본적으로 프로그램의 현재 세션과 관련된 모든 것이이 개체에 있습니다. 몇 가지 다른 신이 있습니다.하나님 객체를 해체하기위한 인터페이스 상속?
어쨌든, Resharper를 사용하여 인터페이스를 추출하여이 god 객체를 "조롱 할 수있는"객체로 만들었습니다. 그러나 이것은 실제로 테스트하기가 어렵습니다. 왜냐하면 대부분의 경우 코드 작성을 통해 100 가지의 다른 메소드와 특성을 조롱하는 데 필요한 코드를 살펴야하기 때문입니다.
이 클래스를 실제로 분할하는 것은 지금 당장 의문입니다. 왜냐하면 말 그대로 수백 개에 이르는 클래스에 대한 참조가 있기 때문입니다.
비록 인터페이스가 있고 (거의 모든 코드가 인터페이스를 사용하도록 리팩토링 되었기 때문에), 나는 흥미로운 아이디어를 가지고있었습니다. ISession 인터페이스가 다른 인터페이스에서 상속 된 경우 어떻게됩니까? 업데이트 할 필요가 없습니다 것입니다 ISession를 사용하여 기존 코드를, 이런 식으로
interface IBar
{
string Baz{get;set;}
}
interface IFoo
{
string Biz{get;set;}
}
interface ISession: IFoo, IBar
{
}
없으며, 실제 구현의 업데이트가 가지고있다 : 우리가 이런 식으로 뭔가가 있다면 예를 들어
. 그러나 새로운 코드에서 우리는 더 세분화 된 IFoo 또는 IBar 인터페이스를 사용할 수 있지만 ISession을 전달할 수 있습니다.
그리고 결국, 나는 같은 아마 쉽게 결국에 지금 실제 ISession 및 세션 신 인터페이스/오브젝트
을 휴식하고이를 참조하십시오. 이것은이 신을 대상으로 시험하고 결국 깨뜨리는 좋은 방법입니까? 이것은 문서화 된 접근 방식 및/또는 디자인 패턴입니까? 이런 식으로 한 적이 있습니까?
+1 : 이는 단계별 리팩터링을 수행하는 합리적인 방법처럼 들립니다. –
체크 아웃하지 않은 경우 Michael Feathers의 [Working Effectively With Legacy Code] (http://amzn.com/B005OYHF0A)가 중요 할 수 있습니다. 여기에는 테스트중인 프로젝트를 가져 오는 데 도움이되는 많은 전략이 포함되어 있습니다. 대다수는 분명하지만 인쇄물로 보는 것은 자신감을 갖게 해줍니다. –
@AnthonyPegram 실제로 내 목록에있는 다음 책은 – Earlz