복잡한 레거시 앱에서 새로운 버그가 발생할 가능성을 낮추기 위해 어떤 방법을 사용할 수 있습니까?

내가 일하는 곳에서 나는 종종 오래된 시스템 (.NET 1)에서 코드를 완성한 스파게티를 개발하고 버그 수정해야합니다. 변수 이름, 프로그램 구조 또는 주석에 대한 생각은 거의 없습니다.

이로 인해 어떤 비트가 변경되어야하는지 이해하는 데 오랜 시간이 걸리고 수정을 했으므로 기존 소프트웨어를 '파손'하는 경우가 많습니다. 난 정말 정말 하거나 이에 대한 프로그래머 시간 (시스템이 대규모 인) 생각 - 모두의 필요성을 볼 수없는 개발자를 리팩토링에 겪고 있지만, 기존의 (동료들과) 몇 달을 보내고 싶어.

다른 것을 깨뜨렸다는 것을 알기 위해 무언가를 고치는 데 며칠이 걸리므로 코드에서 작업 해야하는 것을 두려워합니다. 이것은 분명히 무능 해 보이게합니다. 어떻게 처리 할 수 ​​있습니까?

작업중인 부품에 대한 테스트 작성을 시작하십시오. 다음과 같은 워크 플로를 시도 할 수 있습니다.

1. 변경하려는 부분에 대한 테스트를 작성하십시오. 또한 기존 코드의 작동 방식을 이해하는 데 도움이됩니다.
   • 필요한 경우 테스트를 지원하도록 코드를 리팩터링하지만 시간이 짧은 경우 비 단위 테스트를 작성할 수 있습니다.
2. 테스트를 실행하여 예상대로 작동하는지 확인하십시오.
3. 변경하십시오. 지속적인 코드 개선의 정신으로 필요한 경우 리팩터링하지만 제거하지 마십시오.
4. 테스트를 다시 실행하여 동일한 기능을 유지했는지 확인하십시오.

테스트를 버리지 않으면 시간이 지남에 따라 응용 프로그램의 가장 중요한 부분 및 / 또는 일시적인 부분을 다루는 테스트 스위트가 만들어지고 변경 작업이보다 쉽고 안전 해집니다.

Michael Feathers의 레거시 코드 로 효과적으로 작업하는 것이 도움 이 될 수도 있습니다.

나는 Bob Martin 삼촌 의 보이 스카우트 규칙 을 따르고 싶습니다 .

"지저분한 유산이있을 때해야 할 일은 ... 난장판을 멈추고 청소를 시작하는 것입니다.

그렇다고 관리자를 회의실로 불러서 코드를 리팩터링하는 동안 향후 3 개월 동안 기능을 제공하지 않을 것이라고 말하는 것은 아닙니다. 이러지 마! 오히려“보이 스카우트 규칙”을 채택하고 체크 아웃 할 때보 다 조금 더 깔끔하게 각 모듈을 점검한다는 의미입니다.

반복에서 반복 및 릴리스에서 릴리스까지이 시스템을 정리하면서 새로운 기능을 계속 추가 할 것입니다. 다른 방법은 없습니다. "

코드베이스의 혼란으로 인해 몇 시간이 걸리는 수정 사항을 관리자에게 설명 할 수 있습니다. 다른 개발자는 원래 개발자 인 경우 리팩토링이 필요하지 않습니다. 시스템 내부를 알고 있지만 관리자가 해당 개발자가 지식을 떠날 경우 위험이 있음을 알아야합니다.

완전한 리팩토링을 수행하는 것은 일반적으로 실현 가능하지 않으므로 종종 한 번에 작은 비트를 리팩토링합니다 (몇 가지 방법 또는 모듈). 이 수정 프로그램을 만들기 위해 몇 일 걸리는 경우 지옥, 어쩌면 당신은 포함 할 수 있습니다 작은 동시에 상기 문제 모듈의 리팩토링.

코드를 리팩토링하는 데 몇 개월을 소비해야합니까? 또는 변경하면서 코드를 리팩터링 할 수 있습니까? 예를 들어, Foo 방법을 수정해야한다고 판단되면 Foo 방법을 리팩토링 할 수 있습니다. 그리고 Foo가 문제라는 것을 알아 내기 위해 12 가지 다른 방법을 밟아야한다면, 나중에 여러분이나 다른 사람이 코드가 무엇을하는지 알 수 있도록 해당 방법에 주석을 남길 수 있습니다. 물론, 그것은 스파게티 코드가 여전히 있다는 것을 의미하지만 최소한 코드베이스를 올바른 방향으로 움직여서 쉽게 줄을 찾을 수 있습니다. 코드를 리팩토링하기 위해 여러 달 동안 코드를 리팩토링하는 것은 큰 인기가 될 것입니다. 즉, 최종 사용자가 전체 시간 동안 원하는 것을 제공하지 않기 때문입니다.

또한 단위 테스트를 만들거나 기존 테스트 스위트를 확장하면 실수로 무언가를 부술 가능성이 낮아집니다.

또 다른 팁. 버그가 나타날 때, 붕대를 적용한 후에 는 멈추지 마십시오 !

5 가지 이유를 물어보고, 빨간 약을 복용하고 토끼 구멍이 얼마나 깊고, 근본 원인 (그리고 그 아래의 경로)을 고치십시오.

시스템에 대해 많이 배웁니다. 수정 및 리팩터링 대상의 우선 순위를 정하는 데 도움이됩니다. 그리고 몇 번의 여행 후에는 스파게티의 모 놀리 식 힙을 강화하기 위해 견고한 "지지 빔"이 있습니다.

수정 사항이 확실한지 확실하게 확인할 때까지 이전 코드를 그대로 유지할 수 있습니다. 모든 변경 사항이있는 경우 런타임에 변경 사항을 토글하고 새로운 회귀 버그의 위치를 ​​신속하게 찾아 낼 수 있습니다.

// old code
...

if (!File.ReadAllText("c:\patch_control.txt").Contains("StrangeUIBugFix=0"))
{
    // new code goes here
    ...
}

// old + new code
int someValue = 
    IsEnabled("StrangeUIBugFix") ? a + b :  // new code
    a * b; // old code

한가지 : Never change any existing code if you are not sure what effect change would have on complete application.