This question already has an answer here:
I have inherited a legacy web application many years which:
- Does not make use of Object Oriented principles, even though the language would permit it
- Has no unit tests, nor any sort of test suite, automated or not
- Generally ignores various general best practices making the code very hard to read and maintain
- Splits its workings (including code for business rules) across the web application, database views and stored procedures. Some of the code is even externalized in that outside applications (not under me or my team's control) often read or write directly into the database
- Has only the barest documentation (including some I've created)
- No documented technical or functional specs to speak of either
- Has changed rules so many times and so fast that no one truly knows how it's supposed to work anymore. Rules are stacked on as missing features or specific cases are discovered on a daily basis.
- Happens to be the most business-critical application of the company
- Is still constantly evolving
Refactoring almost always comes with the main suggestion of adding unit tests to make sure you don't break anything. How do you do this when you do not even know how the thing is supposed to work (and no one else can tell you for sure)?
Is this a case where you'd need to go back to square 1 and slowly, iteratively, as new features are requested, ask for specs focused on the modified section and then refactor what's there? Is there any other way to deal with this situation?
This question focuses mostly on the lack of specs in opposition the refactor safety rule of creating unit tests to ensure the rules are respected throughout refactoring.
That said, a few more bits on the situation beyond lack of specs:
- The "best" programming structure found in the code so far is the function. They tend to not be self-contained and call on many global variables (even local variables were erroneously set as global variables risking unexpected behaviors). I get the feeling the first step might be to refactor this to even allow unit testing.
- The issues mentioned apply to the whole application, the database procedures and even sister applications. Everything is intermingled together and almost never through interfaces. It's still possible to find
- Code tends to be duplicated in various places. It happens with business-rules code, meaning you may get different results depending on where in the application you call up a feature. Obvious maintenance complexity and risk.