Refactoring Atrocious Java Code [duplicate]

Question

So I recently started a new job for a small software company. They've got some old technology which I was aware of during the interview process.

However, I've been digging into their code-base, and I'm kind of horrified by what I'm seeing:

• Swallowed exceptions
• Servlets generating HTML instead of sending data to JSP for view
• Repeated code
• Passwords being stored as plaintext in database instead of hashes
• No unit tests
• No build tooling

The guy who wrote most of the code is my boss. We've got a good working relationship so I'm in a position to effect a lot of change, but not sure where to start.

Just wanted to get some opinions from others who've been in my situation and what your game plan was to improve the quality of the software.

Answer 1

If the code base was in perfect shape you wouldn't have a job there. I've seen enough developer turn over to notice the usual trend is to rewrite everything because it is a mess and rewriting it would result in textbook supportable and extendable code.... Only to end up with a slightly newer mess. That being said, I'd start by simply stopping the bleeding. Anything touched to fix whatever bug or extend whatever feature also gets cleaned up and put under test coverage. Do that while recognizing the risk is that attempts to clean up might induce breaks. Manage that risk well and you are golden. If you don't, you can't even think about blaming the last developer.

Answer 2

I'd be more patient than Thomas. While you are doing your initial bug fixes and feature adds, take notes of the problems (as you have started) and also, as you learn how things work and what is "most important", consider approaches to fix them.

Then, go to your boss and present the ideas and ask "what should I tackle first"? For all you know, he will say something like "I always wanted to try that JSP library" or "I never had a chance to add better exception handling" and you can proceed on fixing parts of the code. Or "we are going to dump XML for JSON, don't bother fixing that code". So you don't fix stuff that doesn't matter.

Assuming that is successful, you will have gained credit as a good programmer and can propose further design improvements.

Answer 3

I've upvoted two good answers but here's a bit of extra advice.

1) You said the magic words "Small Software Company". This is a double edged sword. There is a lot of opportunity to change things and learn all sorts of useful skills if you go about it the right way but there will also be a lot of pressure to get quick results to keep the cash flowing. Remember that.

2) You have to build credibility before you can change the world. That means achieving things that directly and obviously make money for your company. Diving into a 6 month refactoring that leaves the code working pretty much as you found it will not earn you much credit. In fact, being too critical of your Boss' programming could be a very career limiting move.

3) Start small as Thomas suggests and make the world better one unit test at a time.

4) If you haven't already, read "Clean Code" and "Clean Coder" by Bob Martin. Leave them on your desk and see if you can engage your Boss. Chances are, they've been too busy getting the company off of the ground to self-educate. If you can interest your Boss in the benefits of doing things the right way you will get more latitude, if your Boss is more "Get it done - quickly - and move on to the next Job" learn what you can, improve what you can and if the Boss remains unreceptive you should consider moving somewhere more receptive before your soul is consumed by the Black Hole of Codefail.