레거시 소프트웨어 개발의 세계에 오신 것을 환영합니다.

코드는 수십만, 수백만, 수천만 줄이 있습니다.

이러한 코드 라인은 가치가 있으며, 이는 수입원을 창출하고이를 대체하는 것은 불가능합니다.

귀하의 비즈니스 모델은 해당 코드 기반을 활용합니다. 따라서 팀 규모가 작고 코드 기반이 큽니다. 사람들이 새로운 버전의 코드를 구매하거나 기존 고객을 행복하게하려면 기능을 추가해야합니다.

완벽한 세계에서 거대한 코드 기반은 wazoo에서 단위 테스트되었습니다. 당신은 완벽한 세상에 살고 있지 않습니다.

덜 완벽한 세상에서는 기술 부채를 고칠 예산이 있습니다. 코드를 단위 테스트 가능한 부분으로 나누고, 광범위한 통합 테스트를 수행하고 반복하십시오.

그러나 이것은 새로운 기능을 생성하지 않고 부채를 상환하고 있습니다. “업그레이드 인센티브를 생성하기 위해 코드를 수정하면서 기존 코드의 수익을 거두는”비즈니스 사례와 일치하지 않습니다.

엄청난 양의 코드를 가져와 더 현대적인 기술을 사용하여 다시 작성할 수 있습니다. 그러나 기존 코드와 상호 작용할 때마다 가능한 브레이크 포인트가 노출됩니다. 시스템에서 해킹하면 다시 작성하지 않은 하위 시스템의 단점을 실제로 보상합니다. 항상.

할 수 있는 것은 신중하게 행동하는 것입니다. 실제로 이해하고 나머지 시스템과의 동작 및 상호 작용을 잘 이해하는 코드의 일부를 찾을 수 있습니다. 단위 테스트를 추가하고 동작을보다 명확하게 만들어 현대화 할 수 있습니다.

그런 다음 주로 앱과 상호 작용하는 나머지 앱 부분을 찾아 한 번에 하나씩 공격하십시오.

그렇게하면 고객이 지불하고자하는 기능을 추가하여 서브 시스템을 개선 할 수 있습니다.

요컨대 이것은 비즈니스 사례를 제공하는 것을 깨뜨리지 않고 변경하는 것이 가능한 기술입니다.

그러나 이것은 당신의 질문이 아닙니다. 귀하의 질문은 “거대한 일을하고 있고 물건을 부러 뜨릴 수있는 일을하고 있으며 모범 사례를 어떻게 따르나요?”입니다.

큰 일을 할 때, 안정적으로하고 싶다면 버그를 추적하고 작성하는 것보다 더 많은 노력을 기울이는 것이 사실입니다. 이것은 소프트웨어 개발의 일반적인 규칙입니다. 물건을 작성하는 것은 쉽고, 완벽하게 작동하는 것은 어렵습니다.

당신은 아마도이 거대한 변화가 진행될 것이라고 이해 관계자들에게 약속 한 비즈니스 사례를 머리에 걸었을 것입니다. 그리고 그것은 “완료”입니다. “좋아요”

권한과 예산이 있다면 실제로 변경 사항이 적용되었다는 확신을 가지도록 노력하거나 변경 사항을 거부하십시오. 이것은 친절하지 않고 정도의 문제가 될 것입니다.

그다지 힘이 없지만 여전히 약간의 힘이 있다면, 새로운 시스템 이 단위 테스트 가능 하다고 주장하십시오 . 일부 서브 시스템을 다시 작성하는 경우 새 서브 시스템은 올바르게 지정된 동작과 그에 대한 단위 테스트를 가진 작은 부품으로 구성되어야합니다.

그렇다면 최악의 경우가 있습니다. 당신은 빚에 깊이 들어가 있습니다. 현재 기능을 사용하기 위해 취약하고 더 많은 코드를 사용하여 프로그램의 미래에 대항하여 결과를 손상 시킵니다. 스윕 기반 QA를 수행하여 최악의 문제를 찾고 나머지는 무시합니다. 이것은 현재 가장 저렴하기 때문에 실제로 비즈니스 관점에서 정답입니다. 이익을 창출하기 위해 부채로 들어가는 것은 유효한 사업 전략입니다. 특히 파산을 통해 부채를 청산하는 것이 (코드 중단) 표에 있습니다.

큰 문제는 회사 소유자의 인센티브가 의사 결정자와 프로그래머와 거의 일치하지 않는다는 것입니다. ‘납품’해야하는 압력이 많이있는 경향이 있으며, 거의 보이지 않는 (상사에게) 기술 부채를 발생시킴으로써 그렇게하는 것은 단기적이고 때로는 중기적인 전략입니다. 모든 부채를 만들지 않으면 서 상사 / 이해 관계자에게 최상의 서비스를 제공 할 수 있습니다 .

답변