프로젝트가 있습니다. 이 프로젝트에서는 기능을 추가하기 위해 기능을 리팩터링하고 기능을 추가하기 위해 프로젝트를 리팩터링했습니다.
문제는 내가 끝났을 때 그것을 수용하기 위해 약간의 인터페이스 변경이 필요하다는 것이 밝혀졌습니다. 그래서 변경했습니다. 그런 다음 소비하는 클래스는 새로운 인터페이스 측면에서 현재 인터페이스로 구현할 수 없으므로 새로운 인터페이스도 필요합니다. 이제 3 개월 후 거의 무관 한 수많은 문제를 해결해야했으며 1 년 동안 로드맵 된 문제를 해결하려고하거나 문제가 컴파일되기 전에 어려움으로 해결되지 않는 것으로 보이는 문제를 찾고 있습니다. 다시.
앞으로 이런 종류의 계단식 리팩토링을 어떻게 피할 수 있습니까? 서로 너무 밀접하게 의존하는 이전 수업의 증상일까요?
간단한 편집 :이 경우 리 팩터 가 특징 이었습니다 . 리 팩터 는 특정 코드 조각의 확장 성을 높이고 일부 커플 링을 줄 였기 때문입니다. 이것은 외부 개발자가 더 많은 것을 할 수 있다는 것을 의미했습니다. 이것이 제가 원했던 기능이었습니다. 따라서 원래 리 팩터 자체가 기능적으로 변경되어서는 안됩니다.
5 일 전에 약속 한 더 큰 편집 :
이 리팩터링을 시작하기 전에 인터페이스가있는 시스템이 있었지만 구현시 dynamic_cast에는 가능한 모든 구현을 통해 간단하게 전달했습니다. 이것은 분명히 인터페이스에서 상속받을 수 없었으며 두 번째로 구현 액세스 권한이없는 사람은이 인터페이스를 구현하는 것이 불가능하다는 것을 의미했습니다. 그래서 나는이 문제를 해결하고 공공 소비를위한 인터페이스를 열어서 누구나 그것을 구현할 수 있고 인터페이스를 구현하는 것이 계약 전체를 개선해야한다고 결정했습니다.
내가 한 모든 장소를 찾아서 불 사고로 죽였을 때, 나는 특정한 문제로 판명 된 곳을 찾았습니다. 그것은 이미 구현되었지만 다른 곳에서 더 나은 모든 파생 클래스 및 복제 기능의 구현 세부 사항에 달려 있습니다. 대신 공용 인터페이스 측면에서 구현되어 해당 기능의 기존 구현을 재사용 할 수 있습니다. 제대로 작동하려면 특정 컨텍스트가 필요하다는 것을 알았습니다. 대략적으로 말하면, 이전 구현 호출은 다소 비슷했습니다.
for(auto&& a : as) {
f(a);
}
그러나이 컨텍스트를 얻으려면 컨텍스트를 더 비슷한 것으로 변경해야했습니다.
std::vector<Context> contexts;
for(auto&& a : as)
contexts.push_back(g(a));
do_thing_now_we_have_contexts();
for(auto&& con : contexts)
f(con);
이는 이전에 일부로 사용되었던 모든 작업에 대해 f일부 g는 컨텍스트없이 작동 하는 새로운 기능 의 일부로 작성되어야하며 일부는 현재 지연된 일부로 작성되어야 함을 의미합니다 f. 그러나 모든 방법 f이 이러한 맥락을 필요로하거나 요구하는 것은 아닙니다. 그들 중 일부는 별도의 수단을 통해 얻은 뚜렷한 맥락을 필요로합니다. 따라서 f전화를 거는 모든 것 (대략 말하면 거의 모든 것 )에 대해, 필요한 경우, 필요한 상황, 어디에서 가져와야하는지, 그리고 오래된 것에서 f새로운 f것과 새로운 것으로 나누는 방법을 결정해야했습니다. g.
그리고 그것이 내가 지금있는 곳에서 끝나는 방식입니다. 내가 계속 한 유일한 이유는 어쨌든 다른 이유로이 리팩토링이 필요했기 때문입니다.