다시 쓸 것인가, 아니면 수리할 것인가?

https://stackoverflow.com/questions/35233

09-06-2019
|

문제

나는 여러분 모두가 거기에 있었을 것이라고 확신합니다. 목적에 거의 적합하지 않은 삐걱거리는 오래된 코드 기반이 있는 프로젝트를 수행하고 처음부터 다시 작성하거나 이미 존재하는 것을 복구하기로 결정해야 합니다.

기존 통념에서는 실패 위험이 매우 높기 때문에 처음부터 다시 작성하려고 시도해서는 안 된다고 제안하는 경향이 있습니다.그렇다면 이 문제에 직면했을 때 무엇을 했고, 어떻게 결정을 내렸으며, 그 결과는 어떻게 되었나요?

해결책

그것은 실제로 그것이 얼마나 나쁜지에 달려 있습니다.

작은 시스템이고 완전히 이해하고 있다면 재작성도 미친 짓은 아닙니다.

반면, 문서화되지 않은 미스터리 코드가 1천만 줄에 달하는 거대한 레거시 괴물이라면 완전히 다시 작성하는 데 정말 어려움을 겪을 것입니다.

고려해야 할 사항:

그것이 사용자에게 좋아 보인다면, 그들은 어떤 종류의 스파게티 엉망이 당신을 위해 어떤 종류의 스파게티 엉망인지 신경 쓰지 않을 것입니다.반면에, 그들에게도 좋지 않다면, 합의 (그리고 인내심)를 얻는 것이 더 쉽습니다.
다시 쓰면 한 번에 한 부분 씩 해보십시오.지저분하고 무질서한 코드베이스는 이것을 어렵게 만들 수 있습니다 (즉, 한 부분 만 교체하려면 대규모 의존성 코드를 다시 작성해야 함). 가능하면 길을 따라 사용자로부터 점차적으로 다시 작성하고 피드백을받는 것이 훨씬 쉽습니다. .

새 버전을 한 번에 한 부분씩 출시할 수 없는 상태에서 대규모 시스템을 위한 대규모 재작성 프로젝트를 수행하는 것을 정말 주저할 것입니다.

다른 팁

작업할 때마다 코드를 조금씩 정리하면 됩니다.아직 없는 경우 단위 테스트 프레임워크를 설정합니다.모든 새로운 코드는 테스트를 작성해야 합니다.버그로 인해 수정한 이전 코드도 테스트에 포함해 보세요.

정리가 진행됨에 따라 점점 더 많은 불쾌한 코드를 캡슐화된 저장소로 쓸어버릴 수 있습니다.그러면 나중에 하나씩 골라낼 수 있습니다.

아직 사용하지 않는 경우 javadoc 또는 doxygen과 같은 도구도 코드 문서화 및 이해도를 향상시키는 데 도움이 될 수 있습니다.

완전한 재작성에 반대하는 주장은 꽤 강력합니다.원래 프로젝트의 기간 동안 코딩된 수많은 "작은 버그"와 동작이 다시 몰래 들어올 것입니다.

Joel Spolsky의 에세이 보기 절대 하지 말아야 할 일.요약하자면, 다시 작성하면 현재 코드가 필요한 방식으로 작동하도록 만드는 데 배운 모든 교훈을 잃게 됩니다.

또한보십시오: 큰 진흙 공

복잡한 내용을 다시 작성하여 성공하는 경우는 거의 없습니다.유혹적이지만 낮은 비율의 전략입니다.

단위 테스트에서 레거시 코드를 가져와 리팩터링하거나 필요할 때 점진적으로 작은 부분을 완전히 교체하세요.

실제로 매우 나쁘지 않은 한 리팩토링하십시오.

조엘은 이것에 대해 할 말이 많습니다.

최소한 이전 코드를 사용하여 코드를 다시 작성하고 처음부터 다시 시작하지 마세요.이전 코드는 끔찍할 수 있지만 이유가 있는 방식이므로 이를 무시하면 이전 코드에서 아마도 몇 년 전에 수정되었던 것과 동일한 버그를 보게 될 것입니다.

이전 직장에서 다시 작성했던 이유 중 하나는 원본 코드 기반 작업에 충분한 경험을 가진 개발자를 찾을 수 없었기 때문입니다.

먼저 기본 데이터베이스 구조를 정리한 다음 정규 직원 및/또는 계약자를 더 쉽게 찾을 수 있도록 다시 작성하기로 결정했습니다.

아직 어떻게 되었는지는 들어보지 못했습니다 :)

사람들은 표면적으로는 더 재미있어 보이기 때문에 다시 쓰는 경향이 있다고 생각합니다.

우리는 처음부터 다시 재건해야 합니다!

제대로 해보겠습니다 이 시간!

등.

새 책이 나오네요. .NET에서 브라운필드 애플리케이션 개발 Baley와 Belcham의 작품입니다.첫 번째 장은 무료이며 대부분 플랫폼에 구애받지 않는 관점에서 이러한 문제에 대해 설명합니다.

수리하거나 더 중요한 것은 리팩터링하는 것입니다.둘 다 때문에 조엘이 그렇게 말했어요 또한 그것이 여러분의 코드라면 이 코드를 마지막으로 만진 이후로 훨씬 더 많은 것을 배웠을 것이기 때문입니다..NET 1.1에서 작성한 경우 3.5 SP1로 업그레이드할 수 있습니다.들어가서 주석 처리된 이전 코드를 모두 제거하면 됩니다.이 코드를 처음 작성했을 때보다 지금은 개발자로서 100배 더 나아졌습니다.

제가 생각하는 한 가지 예외는 코드가 정말 구식 기술을 사용하는 경우입니다. 이 경우 새 버전을 작성하는 것이 더 나은 서비스를 제공할 수 있습니다.데이터베이스 작동 방식에 대해 잘 모르는 사람(8년 전의 귀하일 수 있음)이 분명히 설정한 Access 데이터베이스 백엔드가 있는 10,000줄의 코드가 포함된 일부 VB6 앱을 보고 있다면 아마도 다음을 수행할 수 있을 것입니다. 훨씬 더 짧은 시간과 코드로 더 빠른 C#/SQL 기반 솔루션을 구축할 수 있습니다.

그렇게 흑백은 아닌데..그것은 실제로 많은 요인에 따라 달라집니다(더 중요한 것은 "당신에게 돈을 지불하는 사람이 당신에게 무엇을 하기를 원하는가"입니다).

제가 일하는 곳에서는 개발 프레임워크를 다시 작성하고, 다른 한편으로는 (클라이언트의 기술 및 시간 제한으로 인해) 마이그레이션할 수 없는 일부 오래된 시스템을 계속 수정하고 있습니다.이 경우 우리는 코딩 스타일을 유지하려고 노력하며 때로는 빌드 방식으로 인해 많은 해결 방법을 구현해야 합니다.

고객님의 상황에 따라, ~할 것 같다 다른 옵션이 있습니다:라이센스가 있는 타사 코드.

비록 겉보기에 "IP를 버리는 것"이 관리에 큰 장벽이 될 수 있지만 이것이 합리적인 선택이 될 수 있는 몇몇 회사에 컨설팅을 한 적이 있습니다.현재 회사에서는 핵심 프레임워크를 대체하기 위해 타사 코드를 사용하는 실행 가능한 옵션을 진지하게 고려했지만 그 아이디어는 궁극적으로 기술적인 이유보다는 비즈니스적인 이유로 더 많이 거부되었습니다.

귀하의 질문에 직접적으로 답하기 위해 우리는 마침내 레거시 프레임워크를 다시 작성하기로 결정했습니다. 이는 우리가 가볍게 내린 결정이 아니었습니다!14개월이 지난 지금, 우리는 이 선택을 전혀 후회하지 않습니다.버그를 수정하는 데 소요된 시간만 고려하면 우리의 새로운 프레임워크는 거의 그 자체로 가치를 발휘했습니다.부정적인 측면으로는 아직 기능이 완전하지 않기 때문에 우리는 마지막 "프런트 엔드" 애플리케이션을 포팅할 수 있을 때까지 두 개의 개별 프레임워크를 병렬로 유지 관리해야 하는 불가피한 위치에 있습니다.

Michael Feathers의 "레거시 코드로 효과적으로 작업하기"를 읽어 보시기 바랍니다.단위 테스트가 가능하도록 코드를 리팩터링하는 방법에 대한 코칭 조언입니다.

라이센스 : CC-BY-SA ~와 함께 속성

제휴하지 않습니다 StackOverflow