Process, Tools, Management Techniques Required For Re-engineering A Java Software Project [closed]_问答_开发者

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.

We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.

Closed 3 years ago.

Improve this question

I am part of a new team attempting to develop a new Java software system out of a legacy code base (also written in Java) that's rotten to the core. For company political reasons we can't ditch the old Java code and start from fresh. A rewrite would be tantamount to an admission that the system they spent 2 years developing is complete rubbish. This would lead to head rolling at the top of the team (i.e. Development managers, project managers, Architects etc...). A very strong sense of self preservation has therefore kicked in at the top of the team meaning that any ideas which hint at a rewrite are dismissed out of hand.

This has lead to ask the following question: What w开发者_JAVA百科ould you say are the key processes, tools and software development techniques, a team would need to implement in order to successfully re-engineer/refactor a very rotten legacy code base into a good stable system? This must surely be possible. Are there any good books/websites on the matter?

Thanks

define a clear plan of what you're trying to achieve and where you're going
write tests for as much new and old code as you can to ensure you're preserving behaviour and creating a good test suite going forward
refactor small chunks at a time, it adds up eventually
work with discrete vertical slices of functionality if you can to prevent breaking changes cascading through the code
make sure you build regularly
use source control

basically, all the accepted good practice you should have used from the start ;)

Start with the classics:

Automated builds & deploy manager Unit tests Fitness tests

Once you have those things in place.. when ever you ar ready to refactor/rewrite the whole mess.. it will be much much easier.. and it is very easy to ask for this iniciatives without rasing any suspicions of your re-write intentions.

I speak with the voice of experience ;)

I really got a lot out of this series of articles. While it is about ASP.Net specifically, I think that the concepts discussed in at least the first couple of articles would pertain to a Java brownfield application. Such as:

"There are some fundamental software engineering principles that every project should adopt, regardless of the particular methodology to which you might subscribe. They are:

Version control

Issue tracking

Automated, self-contained builds

Automated testing"

That might help you get oriented and establish a starting point for your unenviable endeavor.

I have successfully used Enterprise Architect (EA) to reverse engineer large source code bases.

If you don't have a good model of the current state, that tool can give you great insight into the current state. It also provides a framework to discuss what parts must change, what parts can be rescued, and what parts don't need to be touched.

Eclipse - it's refactoring capabilities are very powerful
Patience
Skills. It appears to me that almost every 'legacy' system is 'bloated', 'rubbish', 'rotten' or 'crap'. While this is generally true, the non-legacy applications are the same, because the developers writing them are not skilled enough. So have in mind, that if you want to achieve something more than yet-another-rotten system, you have to be very careful with the team skills.

You're probably best off by simply thinking of this as a new project, but with an existing code base. Sit down with everyone involved and figure out exactly what's wrong with the system: Is is architected poorly, designed poorly, coded poorly, doesn't meet requirements, etc (or all of the above). Revise the architecture and design of the pieces as needed and come up with a plan to refactor/rewrite the pieces to get them in good working order.

All of the best-practices that you'd apply to a new project definitely apply here: source control, automated unit and functional tests, continuous integration, nightly builds, peer reviews, etc.