Code refactoring on bad system design

Question

I am a junior software engineer who've been given a task to take over a old system. This system has several problems, based on my preliminary assessment.

1. spaghetti code
2. repetitive code
3. classes with 10k lines and above
4. misuse and over-logging using log4j
5. bad database table design
6. Missing source control -> I have setup Subversion for this
7. Missing documents -> I have no idea of the business rule, except to read the codes

How should I go about it to enhance the quality of the system and resolve such issues? I can think of using static code analysis software to resolve any bad coding practice.

However, it can't detect any bad design issues or problems. How should I go about resolving these issues step by step?

Answer 1

Focus on stability first. You can't enhance or refactor until you have some kind of stable environment in-place around the application.

Some thoughts:

1. Revision control. You've made a start by setting-up subversion. Now make sure that your database schemas, stored procedures, scripts, third-party components, etc. are under revision control too. Have a version labelling system, make sure you label versions and can accurately access old versions in the future.
2. Build and release. Have a way to build stable releases on a machine other than your dev machine. You may want to use ant/nant, make, msbuild, or even a batch file or shell script. You may need deployment scripts / installers too if they don't exist.
3. Get it under test. Do not change the app until you have a way to know whether your change has broken it. For this you need tests. You should hopefully be able to write xunit unit tests for some of the simpler, stand-alone classes, but try to build some system/integration tests that exercise the application as a whole. Without high code coverage (which you won't have to begin with) integration tests are your best bet. Get into the habit of running the tests as often as possible. Take every opportunity to extend them.
4. Make small, focussed changes. Try to identify systems/subsystems within the application, and improve the boundaries between them. This reduces the knock-on effects of changes you may make. Beware the temptation to "pretty-up" the code by reformatting it or imposing the latest fashionable design pattern. Turning-around a system like this takes time.
5. Documentation. Its necessary, but don't worry too much about it. System documentation is rarely used in my experience. Good tests are usually better than good documentation. Concentrate on documenting the interfaces between the application and the system context that it runs in (inputs, outputs, file structures, db schemas, etc).
6. Manage expectations. If its in bad shape then it will probably resist your efforts to make changes and timescales may be harder than usual to estimate. Make sure management and stakeholders understand that.

At all costs, beware the temptation to just rewrite the whole thing. Its almost never the right thing to do in this situation. If it works, concentrate on keeping it working.

As a junior developer, don't be afraid to ask for help. As others have said, Working Effectively With Legacy Code is a good book to read, as is Martin Fowler's Refactoring.

Good luck!

Answer 2

A good book on this subject is Working Effectively with Legacy Code By Michael Feathers (2004). It goes through the process of making small changes, while working towards a bigger clean up.

1. Write unit test & Find and remove duplicate code.
2. Write unit test & Break long methods into a series of short methods.
3. Write unit test & Find and remove duplicate method.
4. Write unit test & Break apart classes so that the follow the single responsibility principle.