코드베이스를 처음부터 다시 작성해야하는 경우

코드베이스를 처음부터 다시 작성해야하는 경우

---

코드를 처음부터 다시 작성하지 않는다는 Joel Spolsky의 기사를 다시 생각합니다. 그의 주장을 요약하자면, 코드는 녹슬지 않으며, 많은 유지 보수 릴리스 후에는 예쁘지 않을 수도 있지만 작동하면 작동합니다. 최종 사용자는 코드가 얼마나 예쁜지 신경 쓰지 않습니다.

여기에서 기사를 읽을 수 있습니다 : 절대하지 말아야 할 일

나는 최근에 프로젝트를 인수했고 그들의 코드를 살펴본 결과 꽤 끔찍합니다. 나는 이전에 만든 프로토 타입을 즉시 생각했고 어떤 프로덕션 환경에서도 사용해서는 안된다고 명시 적으로 말했습니다. 하지만 물론 사람들은 듣지 않습니다.

이 코드는 웹 사이트로 구축되며 문제의 분리, 단위 테스트 및 모든 곳에서 코드 중복이 없습니다. App_Code에서 여러 클래스를 계산하지 않는 한 데이터 레이어, 실제 비즈니스 로직이 없습니다.

저는 이해 관계자들에게 기존 코드를 유지하고 버그 수정 릴리스 및 일부 사소한 기능 릴리스를 수행하는 동안 테스트 주도 개발을 염두에두고 우려 사항을 명확하게 분리하여 즉시 다시 작성해야한다고 권고했습니다. . ASP.NET MVC 경로를 사용할 생각입니다.

내 유일한 관심사는 물론 처음부터 다시 작성하는 데 걸리는 시간입니다. 멤버십 등을 사용하여 완전히 복잡하지 않고 방앗간 웹 애플리케이션을 실행합니다.

비슷한 문제를 겪은 사람이 있습니까? 어떤 특별한 조치를 취하 셨나요?

최신 정보:

그래서 .. 내가 뭘하기로 결심 했나? 나는 Matt의 접근 방식을 취하고 많은 영역을 리팩토링하기로 결정했습니다.

• App_Code가 커져서 빌드 시간이 느려지기 때문에 많은 클래스를 제거하고 클래스 라이브러리로 변환했습니다.

• 모든 ADO 호출을 포함하는 매우 간단한 데이터 액세스 계층을 만들고 이러한 호출을 실행하는 SqlHelper 개체를 만들었습니다.

• 
  훨씬 더 간결한 더 깨끗한 로깅 솔루션을 구현했습니다 .

더 이상이 프로젝트 (자금, 정치, 어쩌구 저쩌구)에서 일하지 않는 동안, 어떤 프로젝트가 얼마나 나쁘게 작성 될 수 있는지에 대한 엄청난 통찰을 얻었고, 한 개발자가 일을 훨씬 깨끗하고 읽기 쉽고 공정하게 만들기 위해 취할 수있는 단계를 시간이 지남에 따라 점진적인 작은 단계로 더 잘 평평 해집니다.

---

지금 모든 문제가 있다고해서 계속해서 문제를 겪어야하는 것은 아닙니다. 예를 들어 새 데이터 계층의 이점을 얻을 수있는 특정 버그를 시스템에서 수정 한 경우 새 데이터 계층을 만듭니다. 전체 사이트에서 사용하지 않는다고해서 사용할 수 없다는 의미는 아닙니다. 버그 수정 중에 필요에 따라 리팩터링하십시오. 코드를 변경하기 전에 코드가 무엇을하는지 정확히 이해했는지 확인하십시오.

코드 복제에 문제가 있습니까? 다음에 복제 된 코드의 버그를 수정해야 할 때 중앙 위치의 클래스 또는 유틸리티 라이브러리로 가져옵니다.

그리고 다른 응답자들이 이미 언급했듯이 지금 테스트 작성을 시작하십시오. 들리는대로 코드가 결합되어 있으면 어려울 수 있지만 어딘가에서 시작할 수 있습니다.

작업 코드를 다시 작성해야 할 이유가 없습니다. 그러나 이미 버그를 수정하고 있다면 "더 나은"디자인으로 코드의 특정 부분을 재 작업 할 수없는 이유가 없습니다.

---

Joel의 기사는 실제로 모든 것을 말합니다.

기본적으로 결코.

Joel이 지적했듯이 처음부터 너무 많은 것을 잃게 될 것입니다. 아마 당신이 생각하는 것보다 더 오래 걸릴 것이고 최종 결과는 무엇입니까? 기본적으로 같은 일을하는 것. 그렇다면 비즈니스 사례 는 무엇입니까?

이것이 중요한 점입니다. 처음부터 무언가를 작성하려면 비용이 듭니다. 그 돈을 어떻게 회수 하시겠습니까? 많은 프로그래머들은 단순히 코드를 좋아하지 않기 때문에이 점을 무시합니다.

---

" Fact and Fallacies Of Software Engineering (소프트웨어 엔지니어링의 사실과 오류) "에서는 "재사용 된 코드의 수정은 특히 오류가 발생하기 쉽습니다. 구성 요소의 20 ~ 25 % 이상을 수정해야하는 경우 처음부터 다시 작성하는 것이 더 효율적이고 효과적입니다. " 숫자는 해당 주제에 대해 수행 된 일부 통계 연구에서 나옵니다. 코드베이스의 품질에 따라 숫자가 다를 수 있다고 생각하므로 귀하의 경우이 진술을 고려하여 처음부터 다시 작성하는 것이 더 효율적이고 효과적인 것 같습니다.

---

나는 그러한 응용 프로그램을 가지고 있었고 다시 작성하는 것은 매우 보람있었습니다. 그러나 "개선"함정을 피해야합니다.

모든 것을 다시 작성할 때 새로운 기능을 추가하고 배짱이 없었던 오랜 문제를 수정하고 싶은 유혹이 듭니다. 이로 인해 기능 크리프가 발생할 수 있으며 재 작성에 필요한 시간이 엄청나게 늘어날 수 있습니다.

정확히 무엇을 변경하고 무엇을 다시 작성할 것인지 미리 결정해야 합니다 .

---

나는 그 기사에 다소 동의하지 않는다. 대부분의 경우 Joel이 정확하지만 가끔 (드물지만) 재 작성이 좋은 생각이라는 것을 나타내는 반례가 있습니다. 예 :

• Windows NT (이전 DOS 코드 기반에서 벗어남.이 기반 위에 Win2k, WinXP 및 곧 출시 될 Win7이 구축되었습니다. 예, Vista도 마찬가지입니다. 이전 기반에있는 Windows의 마지막 버전은 악명 높은 WinME였습니다.)
• Mac OS X (FreeBSD에서 주력 제품을 재 구축)
• 경쟁사가 사실상의 표준을 대체하는 많은 경우. (예 : Excel 대 Lotus 123)

나는 Joel의 주장이 주로 기존 버전의 상당히 잘 작성된 코드에 기반을두고 있다고 생각합니다. 당신이 물려받은 코드가 정말 그렇게 나쁘다면, 재 작성을 요청하세요. 무서운 것들이 있습니다. 전혀 견딜 수 있고 합리적으로 잘 작동하는 경우 새로운 항목을 더 느린 속도로 단계적으로 적용하십시오.

---

저는 이전 코드의 리버스 엔지니어링 비즈니스 규칙을 포함하여 처음부터 코드를 다시 작성한 소규모 전담 팀의 일원이었습니다. 원래 응용 프로그램은 C ++로 작성된 웹 서비스 (정기적 인 충돌 및 심각한 메모리 누수 포함)와 ASP.Net 1.0 웹 응용 프로그램이었고 대체는 C # 2.0 asmx 기반 웹 서비스와 Ajax가있는 ASP.Net 2.0 웹 응용 프로그램이었습니다. 팀이 한 일 중 일부를 경영진에게 설명했습니다.

1. 새 코드가 준비 될 때까지 프로덕션에서 기존 코드 기반을 지원했습니다.
2. 경영진은 재 작성 (첫 번째 릴리스)이 새로운 기능을 도입하지 않고 기존 기능 만 구현하는 데 동의했습니다. 마지막에 1-2 개의 새로운 기능 만 추가했습니다.
3. 소규모 팀은 뛰어난 이해력과 협력을 가진 경험이 풍부한 개발자들로 구성되었습니다.
4. 조직에서 C ++ 인재를 확보하기가 더 어려웠고 C #은 향후 유지 관리를위한 더 나은 대안으로 여겨졌습니다.
5. 우리는 공격적인 일정에 동의했지만 동시에 C # 2.0, ASP.Net 2.0 등에서 작업 할 수있는 자신감과 동기가 높았습니다.
6. 우리는 고위 경영진으로부터 우리를 보호 할 팀 리더가 있었고 스크럼과 같은 프로세스를 따랐습니다.

이 프로젝트는 매우 성공적이었습니다. 매우 안정적이고 성능이 훨씬 뛰어났습니다. 나중에 새로운 기능을 추가하는 것이 더 쉬웠습니다. 따라서 올바른 리소스와 상황이 주어지면 코드 재 작성이 성공적으로 수행 될 수 있다고 생각합니다.

---

준 합법적 인 이유 중 하나만 떠 오릅니다. 바로 정치입니다.

저는 코드베이스를 처음부터 다시 작성해야했고 그것은 정치와 관련이있었습니다. 기본적으로 코드베이스를 관리했던 이전 코더는 방금 고용 된 새 팀에 소스 코드를 공개하기에는 너무 당황했습니다. 그녀는 코드에 대한 모든 비판이 자신에 대한 비판이라고 느꼈고, 그 결과 그녀가 강요 당했을 때만 나머지 우리에게 코드를 공개했습니다. 그녀는 소스 저장소에 대한 관리 액세스 권한이있는 유일한 사람이며 모든 소스를 공개하라는 요청을받을 때마다 코드에 대한 모든 지식을 종료하고 집으로 돌아가겠다고 위협합니다.

이 코드베이스는 15 년이 넘었으며 다양한 스타일을 가진 다양한 사람들의 컨볼 루션과 뒤틀림이 있습니다. 그 스타일들 중 적어도 그녀가 우리에게 공개 한 작은 부분에는 코멘트 나 사양이 포함되지 않았습니다.

일부 코드 만 사용 가능하고 기한이 있기 때문에 전체를 다시 작성해야했습니다. 그 결과 나는 심각한 지연을 일으켰다는 주장을했기 때문에 소리를 지르지 만, 논쟁보다는 머리를 숙이고 끝냈다.

정치는 엄청난 고통이 될 수 있습니다.

---

나는 정확히이 상황에 처해 왔지만 전체 재 작성보다는 리팩토링 프로세스를 통해 상황을 변경하기 위해 노력했습니다. 내가 만난 문제는 내가 작업하고 있던 코드의 엄청난 복잡성이었다. 끔찍하고 특수한 경우 중심의 개발 페이지는 모두 if-case와 복잡한 정규식을 기반으로 약 10 년 동안 계획되지 않은 성장과 확장에 걸쳐 계층화되었다.

내 목표는 동일한 입력에 대해 동일한 출력을 제공하지만 향후 성장을 촉진하고 성능을 향상시키기 위해 보닛 아래에서 훨씬 더 깨끗하고 원활하게 작동하도록 기능별로 리팩토링되는 것이 었습니다. 일반적인 솔루션은 깨끗하고 빠르지 만 시스템에 의해 구문 분석되는 문서의 모호한 특수 사례가 나타나기 시작하고 내 멋진 깨끗한 코드가 다음과 같은 출력을 생성하므로 코드에 대한 수정 작업이 점점 더 어려워지고 복잡해졌습니다. 작고 모호한 방식으로 원본과 약간 다릅니다 (이것은 웹 페이지 였기 때문에 다른 양의 공백은 이전 IE 버전에서 모든 종류의 레이아웃 문제를 일으킬 수 있음).

재 작업 된 코드가 사용되었는지는 모르겠습니다. 완전히 통합되기 전에 회사를 떠났지만 의심 스럽습니다. 1,500 개의 'if'문과 3 줄 정규식이 동일한 작업을 수행 할 수 있는데 왜 20 줄의 코드를 사용합니까?

---

완전한 재 작성의 한 가지 위험은 작업이 지속적으로 진행된다는 것입니다. 당신은 수익에 기여하지 않는 비용입니다. 짜증나는 코드는 돈을 버는 코드입니다.

하지만 기존 코드를 한 번에 하나씩 수정하면 머니 머신이 어떻게 작동하는지 아는 사람이 바로 당신입니다.

---

내 대답은 다음과 같습니다 . 가능한 한 자주 처음부터 다시 작성 하십시오 .

저는 제 경력의 대부분을 우리가 정중하게 "프로그램"이라고 부르는 똥 더미를 계승하며 보냈습니다. 관리자들에 의해 "록 스타"로 여겨지는 젊고 경험이없는 프로그래머가 작성한 것입니다. 이러한 것들은 일반적으로 고칠 수 없으며 결국 처음부터 다시 작성하는 데 소비 한 것보다 10 배 더 많은 노력을 기울이게됩니다.

그렇지만, 나 또한 내 다시 작성하여 엄청난 혜택을했습니다 자신의 주기적 작업을. 모든 재 작성은 다른 방식으로 잠재적으로 더 나은 작업을 수행 할 수있는 기회 이며 이전 버전의 일부는 재사용 할 수 있어야합니다 .

즉, 모든 재 작성이 좋은 생각은 아닙니다. 예를 들어, Windows Vista.

---

언젠가는 손실을 줄여야합니다. 이 코드 기반을 방금 상속했다면 의도하지 않은 결과를 초래하는 변경을 수행 할 수 있으며 테스트 부족으로 인해 찾기가 거의 불가능합니다.

최소한 즉시 테스트 작성을 시작하십시오.

---

처음부터 완전히 다시 작성하는 대신 단위 테스트를 도입하면서 작은 단계로 코드베이스를 리팩토링하기를 원합니다. 예를 들면

1. 프로젝트 전체에서 재사용을위한 테스트를 통해 중복 코드를 공통 클래스로 이동
2. 별도의 테스트 가능한 모듈을 만들기위한 인터페이스를 소개합니다. 그런 다음 테스트에 의존하면서 인터페이스 뒤에서 구현을 리팩터링하여 아무것도 중단하지 않도록 할 수 있습니다.

---

예를 들어, 해당 영역에서 작업 할 때 데이터 모델을 사용하여 데이터베이스에 대한 백엔드를 만들고 (즉, 사용자 로그인 먼저, 사용자 관리 등) 기존 전면을 조정하는 등 조금씩 작업을 수행하고 싶습니다. -end는 새로운 백엔드를 사용합니다 (인터페이스 기반이므로 테스트를 추가 할 수도 있음). 이렇게하면 처음부터 다시 개발하여 복제 할 수없는 문서화되지 않은 비틀기 및 동작이있는 기존 코드를 유지하면서 우려 사항을 일부 분리 할 수 ​​있습니다.

잠시 후 코드베이스의 약 60 %를 마이그레이션하여 공식 프로젝트가 아닌 새로운 백엔드를 사용하게 될 것입니다. 따라서 다른 40 개 작업을 수행하기 위해 개발 시간에 대해 논쟁 할 수있는 더 나은 위치에있게 될 것입니다. %, 그리고 일단 완료되면 기존 프런트 엔드 클래스의 크기와 복잡성이 크게 줄어들 것입니다. 완전히 마이그레이션 된 후에는 새 뷰를 구현할 시간이 있으면 새 백엔드 모델 및 컨트롤러 구성 요소를 재사용 할 수 있습니다.

---

기술 사양을 작성하여 시작하십시오. 코드가 그렇게 끔찍하다면 실제 사양도 없을 것입니다. 따라서 포괄적이고 상세한 사양을 작성하십시오. 처음부터 다시 작성하려면 어쨌든 사양을 작성해야하므로 시간이 좋은 투자입니다. 기능에 대한 모든 세부 사항을 포함하도록주의하십시오. 앱의 실제 동작을 조사 할 수 있기 때문에 이것은 쉬울 것입니다. 개선 제안을 자유롭게 포함하되 현재 동작의 모든 세부 사항을 캡처해야합니다.

조사의 일부로 시스템에 대한 자동화 된 테스트를 작성하여 예상되는 동작을 조사하고 문서화하는 것을 고려할 수 있습니다. 단위 테스트보다는 블랙 박스 / 통합 테스트에 초점을 맞추십시오 (그렇게 추한 코드라면 어쨌든 허용하지 않을 것입니다).

때 이 사양을 가지고 당신은 가능성이 응용 프로그램은 실제로는 훨씬 더 복잡 당신의 첫 인상보다 것을 발견하고 처음부터 다시 작성 재고 것입니다. 대신 점진적으로 리팩토링하기로 결정했다면 사양과 테스트가 많은 도움이 될 것입니다. 그러나 계속해서 다시 작성하기로 결정했다면 지금부터 작업 할 좋은 사양과 작업이 완료되면 알려주는 통합 테스트 모음이 있습니다.

---

나는 이것이 두 가지에 달려 있다고 생각합니다.

1) 레거시 코드베이스의 기본 설계에 얼마나 결함이 있는지,

2) 재 작성하는 데 걸리는 시간.

1) The company I work for used to have a horribly designed codebase, which made the refactor really difficult because we could not refactor one bit at a time, the main problem was not with individual classes and functions but with the overall design. So the refactoring approach, would be very difficult. (If overall design was good, but, say, individual functions were 300 lines long and need breaking up, then refactoring makes sense).

2) Despite a lot code and very convoluted, run processes. Our engine was not doing all that much. So the rewrite was not that long. Sometimes managers don't realize the that functionality of hundreds of thousands of lines of code can be rebuilt in very short time.

We tried to explain this to our CTO (small company), but he still thought rewrite would be to risky, so me and my co-worker rewrote the basic functionality of the engine in about four weekends. Then showed to our CTO and finally was convinced.

Now, if building basic functionality would take us six months we wouldn't have much on a argument.

---

There is also a conflicting statement in economics that says,

Never account for sunk costs

Sunk costs, according to Wikipedia (https://en.wikipedia.org/wiki/Sunk_cost):

In economics and business decision-making, a sunk cost is a cost that has already been incurred and cannot be recovered.

When sunk costs are coupled with political pressure or personal ego (what manager wants to be the one to admit that they made a poor decision or didn't properly monitor results, even if it was unavoidable or out of their immediate control?), it leads to a situation called escalation of commitment (https://en.wikipedia.org/wiki/Escalation_of_commitment), which is defined as:

a pattern of behavior in which an individual or group, when faced with increasingly negative outcomes from some decision, action, and investment, will continue rather than alter their course—something which is irrational, but in alignment with decisions and actions previously made.

How does this apply to code?

Having a rather long career as a software developer now, one common thread I've found is that, when faced with a challenging or ugly codebase (even if it is our own from two years ago), our first instinct is to want to throw out the old, ugly code and rewrite it from scratch. If it is a familiar codebase, then this is usually born from the fact that we are now much more familiar with the pitfalls of the project and business requirements than we were when we started the project, so we (perhaps subconsciously) yearn for the opportunity to fix our past sins by erasing them with perfection. If it is an unfamiliar codebase, we often tend to over-simplify the challenges faced by the original developers, glossing over "minor details" in favor of "big-picture" architectural-level thinking, and often blowing budgets and timeframes due to a lack of understanding of the complex minutia of the business cases that the code was originally meant to solve.

Then there is the whole concept of technical debt, which, just like financial debt, CAN and WILL accrue to the point that a codebase becomes technically insolvent. More and more time and resources are invested into troubleshooting bugs, extinguishing fires, and overly-challenging improvements to an extent that forward progress becomes expensive, difficult, and perilous. Projects take longer and longer due to defects and being pulled off of project work to fix production issues. After hours "incidents" start becoming expected operation instead of some rare blip. Instead of stepping back and starting to do things right to increase our future productivity (and quality of life), we find ourselves in a position where we are forced to add more and more technical debt in order to meet deadlines - the technical equivalent to taking cash advances on a credit card to make a minimum payment on another card.

That all being said, it neither means that we should rewrite whenever possible, nor should we avoid rewriting working code at all costs. Both extremes are potentially wasteful, and the latter does tend to lead to escalation of commitment (because at all costs means with total disregard to costs, even if those costs completely outstrip the benefits). What needs to occur is an objective assessment of the costs and benefits of rewriting code versus making incremental improvements. The challenge is finding someone with both the expertise and objectivity to make that decision properly. For us developers, we are generally biased towards rewriting because it tends to be a lot more interesting and engaging than working on some crappy legacy codebase. Business managers tend to be biased the other direction because a rewrite imposes some unknowns with little perceivable immediate benefit. The result is generally the absence of a real decision, which then defaults to continuing to dump hours into existing code until some circumstance necessitates a directional shift (or the developer covertly rewrites the code, and usually gets a spanking for it).

I've worked on codebases that were somewhat salvageable, albeit ugly. They didn't follow established practices or standards, didn't use patterns, weren't pretty, but they performed their intended functions reasonably well and were flexible enough that they could be modified to meet anticipated future needs for the expected life of the application. While not glamorous, it was perfectly acceptable to keep this code alive while making incremental improvements when the opportunity arose. Doing otherwise would have produced little benefit other than looking pretty. I would say that most code about which the should I rewrite this? question arises falls under this category, and I find myself explaining to the junior developers on the team that, while it would be great fun to rewrite YetAnotherLineOfBusinessApp in {insert whizzbang framework here}, it is neither necessary or desirable, and here are some ways we can improve it...

I've also worked on codebases that were hopeless. These were applications that barely launched in the first place, usually way behind schedule and in a reduced-functionality state. They were written in a way that no one but the original developer would have any chance of understanding what the code ultimately does. I refer to this as "read-only" code. Once it is written, any attempted change potentially results in systemic indecipherable failure of unknown origin, leading to panicked wholesale rewrites of massive monolithic code constructs that serve no purpose other than to educate the current developer on what is actually happening to a variable cleverly named obj_85 by the time execution reaches line 1,209 nested 7 levels deep in if... else..., switch, and foreach... statements somewhere in the DoEverythingAndMakeCoffee(...) method. Attempts to refactor this code results in failure. Every path you follow leads to another challenge, and more paths, and then paths that branch, and then circle back to a previous path, and after two weeks of heads-down refactoring of a single class you realize that, while maybe better encapsulated, the new code is nearly as whacky and obfuscated as the old code, probably contains even more bugs because the original intent of what you refactored was totally unclear, and, not knowing what exact business cases led to the original disaster in the first place, you can't be sure you've fully replicated the functionality. Progress is almost non-existent because translation of the codebase is nearly impossible and something so innocent is renaming a variable or using the proper type produces an exponential amount of unintended side effects.

Attempting to improve codebases like the above is an exercise in futility. Refactoring usually results in a 80% rewrite anyways, and the end result is nowhere near an 80% improvement. You end up with something that is very inconsistent, and the new code has a lot of compromises that had to be implemented in the interest of interoperability with legacy code (half of which was unnecessary because the legacy code that the new code needed to interoperate with later gets refactored out anyways). There are only two paths that can be followed... continue to accrue technical debt by hacking in "fixes" and modifications while hoping that the application is deprecated (or you get transferred to another project) before it collapses under its own weight, or someone makes the business decision and takes the risk of doing a complete rewrite. I hate both of these options, because it usually means waiting until something critical has failed or a project is way behind schedule, and you then spend the next three months of evenings and weekends trying to get something breathing that probably never should have been alive in the first place.

So, how do you decide?

1. How well does the existing code work? Is it reliable and relatively defect free?
2. Are the people on my team capable of understanding what this code does with a reasonable degree of effort? If I bring in an experienced developer, will he/she be able to make enough sense of this to become productive in a reasonable timeframe?
3. Do what-should-be-simple defects take geologic time measurements to fix; so much so that we are unable to make real improvements or meet project deadlines?
4. Is the codebase so fragile and the expected lifetime such that the ability of the application to adapt to future anticipated business needs is highly questionable?
5. Did the existing code actually meet the original functionality requirements?
6. Is your organization even receptive to investing in the application, or is someone (especially someone at a higher level on the org chart) going to be handed their own *ss for the problem?
7. Can you provide financial or risk-based justification, backed up by hard facts, to make a business case for a rewrite?
8. If, after a FULL accounting of the time and costs of a rewrite (including developing proper specifications, quality assurance testing, post-production stabilization, and training, does it still make sense to start rewriting code (us developers tend to only think in terms of coding time)?
9. Do you have a choice? Is it even possible for the existing code to meet requirements (because if not, rewriting huge swaths is going to be part of the project and considered an "enhancement" instead of a rewrite)?

---

There's an old adage that says:

There's no such thing as bad code. There's only code that does what you want and code that doesn't.

The key to knowing when to re-write lies in there. Does the system currently does what you want? If the answer is yes, slow, but steady improvements are your best bet. If the answer is no, a re-write is what you want.

Going back to Joel's essay, he talks about code that's messy, but software that is reliable and delivers the expected value. If instead, you have unreliable code full of major bugs and that wasn't covering all your use cases. You had things that were supposed to be there yet don't work, or are just missing. In this case, all the little hairs growing out of it aren't bug fixes, but cancer.

참고URL : https://stackoverflow.com/questions/1064403/when-to-rewrite-a-code-base-from-scratch