Evolution or revolution to fix badly written code

Question

I have done some work for my personal project, and now I understand why people tell us to plan all our interfaces and design before coding. I have some good classes and some kind of working code already, but overall the organization (architecture) is a bit of a mess, and I already say: “If I did it again, I would do it like that ...” . The question is, should I sketch out a plan for how I want my code to look, and refactor the existing code into a new model, or if I have to accept what works great and write all the new code for the missing parts (basically starting from scratch with enough copies and paste in this project).

I have a git story, I'm not sure I want to lose, but the task of slowly rewriting everything seems complicated. Therefore, the question I ask is this: when you need to reorganize a young project, do you need to use evolution or revolution to understand this a second time?

Answer 1

Refactoring old code (evolution). The rewrite code always introduces problems you did not think about. I am sure there have been updates to existing code, and many of these updates are bug fixes, etc. You may not know why you made the changes at the time, but you needed to, and rewriting the code could eliminate the need for the change.

By taking small steps, you also avoid the "Oh" expletive "scenario, in which you are trying to make massive changes and encounter a situation where it does not behave as you expect. Thanks to evolution, you can undo the changes and still have a working system , since the architecture is somewhat completed.

Answer 2

How do you fix a big, shitty project? Well, how do you clean Augean Stables ...

Stable cleaning methods:

• If you are Hercules, you do it all in once in a big spray, er, screaming path.
• If you are not Hercules, you grab a shovel, and start slowly improving things one corner at a time.

The trick is to find out in advance if you have the strength and ability to solve the rewriting problem. Underestimate yourself and you will spend a lot of time going through the manure. Reevaluate and you will just make a bigger mess ...

Answer 3

Depends on your situation - if you have time to rewrite ... and, less obviously, retest everything ... blow out and start a new life. But be honest with yourself about what it will look like this time.

Evolution works much better - because time is money, and starting from scratch can represent a huge investment ....

Another bit that many people don’t get - evolution can really work VERY good - it just takes more thought ... you need to find out where you can modulate existing things, but as a rule, it is very possible - just extra time on the board.

Answer 4

Find out how you really want to do this. Make a diagram that you put on the wall, try to think about all the details.

When you make changes, try to figure out how each change can bring you closer to your ultimate goal. If you have this goal in your mind when making changes, you can both code and test material that is consistent with where you want to go. Often I find that I can make some of the less radical (but necessary) changes and still make a profit.

Therefore, I stand for evolution, but with a clear perspective on where you (think) want to go. In any case, you will still find yourself somewhere else.

Answer 5

I usually use evolution, but in big steps, so not only that.

Answer 6

You need to compare the task of slowly rewriting everything (which you might be exaggerating mentally) to the task of quickly rewriting everything (which you probably underestimate seriously). Do not underestimate the value of maintaining the working code that you get with gradual refactoring.

Since you are not describing your platform, I do not know what software is available to support refactoring. There is a lot for Java, for example, but a little damn for C ++.

Knowing almost nothing about you and your project, I propose refactoring more evolutionarily, and I do it pretty quickly before you get disgusted with the old code or write too much new code that relies on bad old things. You may well find code that is too ugly for life and needs to be rewritten; in this case, continue.

Answer 7

The problem with the revolution is that it will take a long time, during which the end users do not receive any value. With gradual changes (evolution), you can improve the system and maintain it at any time.

Uncle Bob thinks about this: http://blog.objectmentor.com/articles/2009/01/09/the-big-redesign-in-the-sky

Answer 8

I think it depends on several factors:

• Do you have unit tests? This suggests the need for refactoring.
• How much time has passed? A day or two disputes are written, in a week or two, to refactoring.
• You rely on it daily - do you need it to work? If so, then refactoring. If not, rewrite.
• How bad is that? If really bad, rewrite it.

In all cases, know where you are going before you begin!

(Personally, I do not buy an argument that you should never rewrite. I also do not buy an argument that well-designed systems can arise solely from refactoring ...)

Answer 9

In the (rephrased) words of Fred Brooks , "Plan to throw out the first." If you haven't planned this yet, you will eventually burn it. The question is only after how much work?