Re^3: How to deal with old OO code that mixes instance methods with class methods

[AnomalousMonk]

[The module has] a number of reported bugs.

Ok, so it's broke.

[The module has] no unit tests.

This is the first problem I would address: Nobody touch nothin' until you figure out a way to test what you 'fix'.

Only after you can test any changes should you address the reported bugs. After resolving any code changes necessitated by these bugs, I would consider relapsing into "no broke, no fix" mode. Of course, if you're a programmer worth your salt, the list of 'problems' you have presented will greatly tempt your intervention. The issues most likely to draw my attention would be those bearing on maintainability. You must recognize, however, that you are venturing upon a slippery slope and may, willy-nilly, find yourself in full-on "can't fix just one" mode. Caveat programmor.

[davido]

This!

Oh, and Skimmable Code (pdf)

It's a big PITA, but figure out what one giant function takes as inputs (included those absorbed through global osmosis), and what it excretes through returns and global manipulations. Figure out its side effects (opening of filehandles, etc). Then write regression tests for the function.

Next, follow Schwern's skimmable code techniques to break the big functions into smaller testable units, while writing unit tests to verify the functionality of these smaller units. Throughout the process, keep running the original regression tests.

Finally you'll be left with something that you can look at and understand how to fix. Most likely the fixes won't involve removing my $self = shift; -- that's just a red herring. The elephant in the corner is the humongous functions that probably don't strictly adhere to simple parameter passing.