in reply to
How to deal with old OO code that mixes instance methods with class methods
In the third post on this thread, you listed a cook’s recipe of things that could be addressed. All of them ideally should be, and this is an excellent priorities-list, but you can’t do them all. (As all of us know.) So, I would start with adding use strict; use warnings; to each module at a time and cleaning-up (under version control, of course) each issue. I use git and would commit after each meaningful group of changes. Basically, if there are things which would qualify as “source-code errors,” these deserve the highest attention. I would also use a ticket-system such as Trac or Unfuddle, even “just for myself.” Don’t trust your memory, and do have a system that links tickets to (git) changesets. Going back, even in a sheer panic and with your bos breathing down your neck, to the known initial state of the system, is a mere git checkout away. (“Priceless.™”)
Then, I would turn to a fairly large series of tests ... starting with, say, LWP and/or Selenium-based tests of what the application visibly does, treating it as a black-box and mapping functionality right or wrong. This will give you an objective way of determining what your code-changes actually did to the system.
In fact, in retrospect, let me change my mind here. I
just might definitely would put the tests first of all, knowing that some of the things which cause some tests to “pass” are actually “erroneous behavior.” Right or wrong, they are the present-state. What I want is for the computer to objectively and automatically tell me when the behavior of the system has changed from its present-state. Some of those changes will be for the good; others are unwanted. In both cases, I want the computer to tell me this.
Another reason for this is that the present-state, business-supporting(!), behavior of the system is known (or presumed) to be based on errors, including source-code errors, yet the system is in production and therefore must continue to do what it does for the business, without unheralded changes. Your tests therefore serve to express that present-state behavior so that any and all deviations from the same will be detected by the computer, which is always known to be more thorough and more detail-oriented than any of us could be.