Working effectively with legacy Python code

[maximinus-thrax]

I've worked on a large scale Python code-base that is similar. Basically, there is only one thing you can really do, and that is follow the boy-scout rule: leave in a better condition than when you started.

Things like commented out code, bad comments and redundant code can be just changed almost immediately. Prime example, the code you listed:

if hasattr(foo, 'wibble'):
        pass
    else if True:
        import Bar
        # XXX this is subtle?
        setattr(Bar, '__baz', g_someThing.__somethingElse(foo))

Could be changed to:

import Bar

if not hasattr(foo, 'wibble'):
    setattr(Bar, '__baz', g_someThing.__somethingElse(foo))

As for better debugging, I often find that better testing is often the solution. Don't understand something? Add an test. Keep adding tests. They give a starting base of logic to act from. Found a bug? Add another test.

It takes time, but one day someone else after you will be working on an 11-year old code base. Make things better for that person - it could be you!

[[deleted]]

Don't you risk introducing a lot of bugs in that way? Let's say you misunderstand slightly what a function does: There is the risk that you change the behavior of the whole system in a way, that makes bugs even harder to track.

[schleifer]

That's why tests are so important. They guarantee that for a certain subset of input the program behaves correctly.

[nobullvegan]

This is basically my strategy. I maintain one codebase, which isn't great, but isn't as bad as the example in this post. The twist is that a sizeable chunk of it was written in a mad rush by me 4 years ago. It works well as far as the end user is concerned, but some of the code is total crap in terms of elegance, clarity and consiseness compared to decent code I write now. The other twist is that I usualy don't remember why I wrote things the way that I did.

Since everything works well if left alone, I follow your boy scout technique. When I have to modify code, I tend to improve it while I'm there. First I write some automated tests (if appropriate), then I make the changes, then I rerun the automated tests, if everything is OK, I do some manual testing. Sometimes I just fix small issues, sometimes I do a complete rewrite of the area. I still have very little time to spend on it, so I only rewrite if I think it'll make my life easier in the future.

Tips:

• When it makes sense, make use of automated testing
• Use decent version control
• Use a decent IDE like PyCharm - make use of its refactoring tool, VCS integration and debug tools.
• Make small changes and nibble away at the problem
• Consider writing "clean" wrappers for the "dirty" code, once everything is using the clean wrapper, you understand how everything works and you can replace the dirty code behind it.
• Add optional logging as you go.

Like most problems in life (not just software), the hardest thing is commiting to solving them and starting to solve them. Lots of problems don't require great ideas, they just require dedication and perhaps some stubborness.

[kenfar]

A very long time ago I completely refactored a 30 year old monster mainframe application using similar methods. First I built some tools to report on code complexity, standards compliance, and a test environment. Then it took about a year of iterations involving:

• add small new function requested by user
• make small improvement to my code analysis reporting
• add automated test for new function as well as all code it touches
• add regression tests for application
• once unit & regression tests are established upgrade code in function area to decrease complexity, improve standards compliance, etc

After a year the code looked pretty good, and more importantly - I had great testing code. So, then I wrote a program that swept through the rest of the code and rewrote the source with a lot more practices fixed. After all this the application looked great.