특정 품질 표준을 충족하기 위해 대규모 레거시 코드베이스를 업데이트하는 방법

레거시 코드베이스를 개선하기위한 도구 및 기술에 대한 많은 정보가 있지만 성공적인 실제 사례 연구를 보지는 못했습니다. 대부분의 조언은 미시적 수준에 있으며 도움이 되더라도 많은 사람들이 거시적 수준에서 도움을 줄 수있는 증거가 없기 때문에 많은 사람들을 설득하지 않습니다.

필자는 오늘날의 품질 표준을 충족하기 위해 대규모 레거시 코드베이스를 업데이트 할 때 현실 세계에서 성공한 것으로 입증 된 점진적인 개선 사항을 찾고 있습니다.

전에:

• 대형 : 1MLOC 이상
• 레거시 : 자동 테스트 없음
• 열악한 품질 : 높은 복잡성, 높은 커플 링, 높은 이스케이프 결함

후

• 자동화 된 테스트
• 손쉬운 업데이트 / 유지 보수
• 고품질 : 복잡성 감소, 코드 분리, 이탈 결함 최소화

실제에서 어떤 종류의 증분 단계가 완전히 재 작성하지 않고 품질 표준을 충족하도록 대규모 레거시 코드베이스를 성공적으로 업데이트 했습니까?

가능하면 백업에 대한 답변으로 "성공적인"품질 개선 프로세스를 거친 대규모 레거시 프로젝트의 사례 회사 또는 사례 연구를 포함하십시오.

http://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052 와 같은 서적 은 업계에서 기존의 품질이 좋지 않은 품질이 좋은 코드 기반이 얼마나 큰지를 입증해야합니다.

왜 당신이 듣거나 보지 못했는지에 대한 나의 추측, 그리고 더 중요한 것은, 당신이 그들 중 하나를 직접 연구 할 때까지 그들에 대해 듣지 못할 것입니다. 아무도 여러 가지 이유로 깨끗하게 나오고 그들의 코드를 말할 수있는 사람이 아무도 없습니다. 기본은 사소한 영향을받지 않고 위의 모든 것입니다.

이것은 당신이 말하는 연구의 어려움을 설명 할 수 있습니다. 예를 들어 Peter van der Linden의 Deep C Secrets와 같은 충분한 책을 읽으면 어느 프로젝트에서 누락되었는지 약 백만 달러의 버그를 읽을 수 있습니다.

참고 : 나는 이것을 주석으로 만들고 싶었지만 너무 길었습니다. 나는 이것이 질문에 완전히 대답하지 못한다는 것을 이해합니다.

편집 : C ++ 11 & GCC의 장기적인 생존 가능성에 의문을 제기 합니다. 개발자가 GCC를 리팩터링하고 LLVM / clang으로 더 툴링 할 수 있다면 좋은 예를 제공 할 수 있습니다. 토론에 따르면 일부 개발자는 문서가 부족하여 새로운 개발자의 진입 장벽이 높아지고 있습니다.

2013 년 2 월 3 일 LibreOffice 개발자 중 한 명인 Michael Meeks는 며칠 동안 "LibreOffice : 거대한 코드 기반 정리 및 리팩터링 또는 다시 작성하는 것이 더 나쁜 이유에 대해 이야기합니다. " 정확히 당신이 요구하는 것 같습니다 : "단위 테스트, 복잡한 빌드 인프라, 25 가지로 독일어로 광범위하게 주석이 잘 이해되지 않은 거대한 코드 기반을 취하기 위해 수행 한 것에 대한 토론 수년간의 미지급 기술 부채 "와 현대화.

프리젠 테이션은 온라인 으로 스트리밍 할 수 있으며 , 향후에는 녹음이 가능할 것입니다.

나는 실제로 내 경력에서 상당히 중요한 리팩토링을 세 번 겪었습니다. 코드가 붕괴되는 경향이 있으므로 코드 기반이 충분히 길면 큰 리 팩터를 피할 수 없습니다. 내 모든 예제는 개인 코드베이스에 있었으며 공개 예제를 찾기 어려운 이유를 설명 할 수 있습니다.

처음은 도트 매트릭스 프린터에서만 작동하는 기본 아키텍처를 가진 응용 프로그램이었습니다. 회사에서 더 이상 리본을 공급할 공급 업체를 찾을 수 없을 때 레이저 프린터와 함께 작동하도록 지정했습니다.

두 번째는 C에서 Java로 수백 개의 자동 테스트 스크립트를 마이그레이션하는 것이 었습니다. 부분적으로 더 나은 크로스 플랫폼 기능이 필요했고, 일부는 새로운 C 개발자를 고용하기가 어려웠 기 때문입니다.

세 번째로 여전히 중간에 있습니다. 커플 링을 줄이고 플랫폼 간 목적으로 단위 테스트를 수행 할 수 있도록 거대한 단일 응용 프로그램을 모듈화하고 있습니다.

나는 산을 등반하려는 노력을 비교합니다. 당신은이 거대한 목표를 앞두고 있지만, 거시적 차원에서는 다루지 않습니다. 한 번에 하나의 손잡이를 가져 가고 항상 대체 위치를 유지하고 다음 안전 장치가 제자리에 올 때까지 이전 안전 장치를 분리하지 마십시오. 작은 점진적으로 개선하기 시작하고 잠시 후 돌아 서면이 아름다운 전망이 나타납니다.

예를 들어 60,000 개의 고 결합 코드 파일이 있다고 가정 해 봅시다. 단위 테스트를 시작하기를 원하지만 종속성으로 인해 불가능합니다. 어떻게 고치나요? 하나의 파일을 분리 합니다. 자동화 된 테스트를 추가합니다. 계속하기 전에 안정된 땅으로 돌아옵니다. 59,999 번 반복하십시오.

단순하게 들리면 간단하기 때문 입니다 . 쉽지는 않지만 간단합니다. 처음에는 어떤 진전도 눈치 채기가 어렵습니다. 우리는 불가능한 리팩터링에 대해 2 년을 보냈고, 끝날 때까지 몇 년을 앞질렀을 것입니다. 그러나 되돌아 보면 코드가 이미 얼마나 나아 졌는지 갑자기 깨닫고 새로운 기능을 계속 제공 할 수있었습니다. 그 동안 고객에게

다른 두 번 같은 방식으로 작동했습니다. 응용 프로그램을 항상 작동 상태로 유지하면서 취할 수있는 가장 작은 안전한 단계를 찾으십시오. 당신은 올바른 방향으로 가고 있는지 확인하기 위해 큰 그림에 대해서만 걱정합니다. 모든 행동은 작고 꾸준하며 점진적입니다.

수백만 줄의 코드 기반 작업에 대한 개인적인 경험에서 나는 효과가있는 몇 가지 전략을 발견했습니다.

모든 버그 (닫힌 버그)를보고 범주별로 분류 해보십시오. 특히 그들이 속한 구성 요소로 분류하십시오. 둘 이상의 구성 요소에 속하는 경우 해당 구성 요소에 유의하십시오. 이 작업을 완료하면 어느 버킷이 가장 큰지 살펴보고 시작 위치를 결정하는 데 사용하십시오. 또한 파일의 개정 이력을보고 가장 많이 변경된 사항을 확인하고 시작 위치의 안내서로 사용할 수 있습니다. 기본적으로 수행하려는 작업은 가장 깨진 부분을 찾아서 반복하는 것입니다. 또한 모든 것을 동시에 수정하려고하면 더 이상 문제가 발생하지 않는다는 것을 알았습니다.

"시스템"문제를 나타내는 여러 구성 요소에 속하는 것이 많고 너무 밀접하게 결합 된 코드 또는 새로 고침이 필요한 API를 가리키는 경우가 있습니다.

많은 시간을 보낸 다른 영역은 기존 코드베이스를 테스트하는 것입니다. 여기에는 여러 가지 전략이 있으며 모두 장점이 있지만 아무도 문제에 대한 완전한 해결책은 없습니다.

• 단위 테스트는 작동 할 수 있지만 종종 밀접하게 결합 된 코드로 인해 단위 테스트 할 수있는 것으로 제한되는 경우가 있습니다. 그러나 당신이 할 수있는 곳에 그것을하십시오.
• 외부 테스트는 또 다른 방법입니다. 나는 아마도 당신이 이미 이것을 가지고 있다고 가정하고 그렇지 않다면 그것을 만드는 데 시간을 할애 할 것입니다. 또한 나를 위해 일한 것은 시스템에 결함 / 이벤트를 무작위로 주입하는 기능을 추가하는 것입니다. 그 외에도 여러 가지를 동시에 주입하여 새로운 방식으로 실패하게하십시오.