Massive Refactoring in Spring Java EE_问答_开发者

I'm doing a massive refactoring on a Spring-Java EE business application. However, all the refactoring is going to be within the many static classes that we use as utility classes (validators, algorithms, object processing logic, resource management, nifty utilities etc.), not within controllers and persistance classes.

Also, the critical controllers which use the methods from these static utility classes will not be affected as I'm making the changes as transparent as possible.

Things is, I'm the owner of some controllers, so I can go in and make any changes required to facilitate the changes in my static utility classes. For example, if I changed a method to throw a custom exception, then I can go into the controller as well and handle that exception gracefully.

However, it's a large project and there are many oth开发者_运维技巧er developers working on it, many of whom use those static utility classes day in and day out. So if I throw new Exceptions, create new overloads etc., it's going to break legacy code.

I'm already growing tired of writing compatible (read: crippled) code that is not semantic, wraps around existing ugly logic, and does not allow me to make more flexible designs.

Considering that we do have a decent (precise: 2 months) distance from the production day, is it ok for me to ask all developers to refactor their code as per my new contracts, or do I keep on writing legacy-garbage wrapped code that doesn't really help anything?

Do your new code in a new (clean) package, and possibly even jar.
Change the existing legacy code to 'adapt' and delegate/forward to the new implementation.
Ask the consumers to migrate to the new package.

This way people using the new stuff don't have to see the "legacy-garbage wrapped code that doesn't really help anything", but you do provide a path forward where not all clients have to change all their code at once (and you provide clear documentation what code they should be using instead of the old ways, inside the implementations that use the new code).

BTW many static classes does not sound like the most testable code base. Have you considered using more 'instance' functionality and injecting instances into consumers, that usually makes code easier to test...

Seriously, why are you asking us, not your team? That's your problem right there.

I say change it and break all code that deserves to be broken. Just who are those other developers you have to support? Descendants of Stroustrup/Gosling hacking into the VM? I'll bet not.

I've been where you currently are, and I've had to put up with imbeciles who demanded that I supress all (newly introduced) Arithmetic exceptions inside a function because all his calls to that function did away with a simple exception chewer. His modules would carry along merrily although the semantics would have been screwed up severely already, can you imagine? Got us plenty of bugs to fix.

Don't put up with anything substandard, or a compromise of any form. Break it, now, and build it cleaner, leaner. People will be all stamping their feet at first and will create a fiasco, but if you are writing truly better (more robust and optimized?) code, they will eventually appreciate that. Matter of time.

And I agree with Fried, too many static classes with these "utility" methods is not a good idea. It feels more procedural than 00. Try to model behavior and state based on business aspects.

E.g. If you have an account class and want to write several utility classes to perform tasks like account setup, account deletion, account transfer etc., you're better off walking the instance based road and modeling the true state+behavior way, using objects. More testable, more semantic, more readable, less of static procedural clutter.

Good luck.