Refactoring Plan for 17+ years of un-testable Delphi Code

Question

You've all heard it before, classic Delphi application.

With 3rd party libraries we're at 1.5 million lines of code, probably 200,000 of our own (Dev Express, NexusDB, etc etc)

One huge Datamodule that I've been slowly splitting into 5 (and likely need more). Moving some business logic to these datamodules slowly but surely as methods of the module.

Everything coded 'under the button', no classes of our own. A few forms have 20k lines of code.

I need a reasonable plan to get this in a better place. Right now you can't really test ANY of it, minor changes could introduce an army of bugs, etc.

I was thinking, to start, get a unit going for each major form and extract business logic in the form to this class/unit. Something like TMyForm has a TMyFormClass.pas so that TmyForm ends up with nothing but UI. Continue to modularize the datamodules, write tests asap. Only refactor where we're working on.

Sound sane, addition suggestions, somebody please send me liqour....

Answer 1

In the end, this is a business decision, and should be made as such. What would give your business the most value. Identify that, and refactor that area first, where you can demonstrate (prove) that the benefits to the business are high at least, if not the highest possible value.

I believe that any plan that starts with an implementation idea (MVC rules! Split all the things!) without business-value assessment, is going to be a largely wasted effort.

Example: My application prints and helps me mail my invoices to my customers. Most valuable area of the application to refactor is that I've never been able to handle customer priority and make batching work properly. This improvement has a clear business value, and refactoring it will take me (I estimate) 10 days. During this time, I also hope to decouple my database access code, from my business rules, and decouple my business rules from my UI, for just the area of the code that has to do with the Priority and Batching elements of my UI, which means it hits only 10% of my UI code, and this refactoring effort takes me (I estimate) another 10 days. That means a total of 20 days effort, and the code will be able to do something new. I also intend to make some unit tests (my first ever) that will rely on the ability to mock my database layer away.

Answer 2

Adding features? Treat the legacy code like a 3rd party library and write a layer on top of it, then keep your code separate.

Fixing or Modifying? Figure out the easiest way to test. A mixture of unit and hand tests, perhaps faking out some service layer.

Clean up the parts of the code you frequently visit. Don't spend lots of time with the parts you never use. Over time an ideal architecture will become clear as you start to evolve towards it. Only plan when you have to.