딥 아키텍처 리팩토링과 기능 기반 개발을 결합하는 더 좋은 방법을 찾고

문제 설명:

주어진:

• 소스 제어로서의 TFS
• 아키텍처 디자인이 거의 없거나 거의없는 수많은 레거시 코드가 포함 된 강력한 데스크톱 클라이언트 응용 프로그램
• 고객은 음질, 빠른
  전송 및 사용자에게 친숙하지 않은 UI에 대해 끊임없이 불만을 갖는 새로운 기능을 지속적으로 요구 합니다.

문제:

의심 할 여지없이 애플리케이션에는 깊은 리팩토링이 필요합니다. 이 과정은 필연적으로 응용 프로그램을 불안정하게 만들고 전용 안정화 단계가 필요합니다.

우리는 시도했다 :

마스터 (MB)에서 기능 분기 (FB)로 정기적으로 병합하여 마스터 리팩토링. (실수) 결과 : 많은 불안정한 가지.

우리가 조언하는 것 :

기사 링크 (pdf)
MB에서 RB 로의 병합을 통해 MB와 주기적으로 동기화하는 리팩토링 (RB)을위한 추가 분기를 만듭니다. RB가 안정화 된 후 우리는 master를 RB로 대체하고 추가 리팩토링을위한 새로운 브랜치를 생성합니다. 이것이 계획입니다. 그러나 여기에서는 FB를 MB로 병합 한 후 MB를 RB로 병합하는 것이 어려울 것으로 예상됩니다.

주요 장점 : 대부분 안정적인 마스터.

교수에 대한 더 나은 대안이 있습니까?

나는 과거에도 비슷한 상황을 겪었다. 제가 한:

• 프로젝트의 현재 상태를 평가; 대부분의 상황에서 아키텍처 (또는 부족)는 주요 문제입니다. => 다시 생각하십시오.
• 일반적으로 작업 특징이 있으며, 문제는 프로젝트의 다양한 부분 사이의 높은 결합입니다. 작동하는 기능이 무엇인지 평가하고 재사용했지만 내 아키텍처에서

• 고객과 대화하십시오. 관리자의 말을 잘 모르겠지만 고객과 대화하고 솔직하게 말하는 것이 중요하다고 생각합니다. 그는 당신이 그의 제품의 품질에 노력하고 있음을 알아야합니다. 릴리스 계획에 동의했습니다.

• 2 개의 솔루션을 병합하는 단계에서 (구식 프로젝트에서 아키텍처를 + 기능을 재사용하도록) 구식 제품에서 릴리스 된 것 (새로운 기능)만이 유일하게 이루어졌습니다. 그러나 새 릴리스에는 중요한 버그 수정 만 포함되었습니다. 이전 제품에 대한 릴리스는 거의 없었습니다. 따라서 변경된 사항은 새로운 솔루션으로 쉽게 통합되었습니다.

• 첫 번째 새 릴리스 (새 제품 릴리스)에는 이전 제품에 포함 된 내용 만 포함되어 있습니다 (새 기능 없음). 그것을 안정화 한 후 (안정화는 오래 걸리지 않았습니다) 단일 프로젝트로 작업했습니다.

나는 당신이 (합리적으로 짧은) 산발적 방출에서 벗어날 수 없다고 생각합니다. 고객과 이에 동의 할 수있는 것이 중요합니다.