Reviewing a large OO system can be tedious job. Of course, there various sources of documented experience available, e.g. patterns, heuristics, etc. However, given a particular program or model, it can be hard to detect actual problems. Where are the "badd smells" in the code? Where should we start to look and improve?
To facilitate reviews and reorganizations tools could be useful. This page provides some pointers to background techniques and tools that help in reviews and improvement of (OO) software. It is an initial list. Send me email if you have any suggestions or additions.
Code duplication is a thing to avoid. But how to detect it? Here are some pointers:
Metrics provide quantiative information about a certain property of a design or process. They could be used to find the things that need improvement most.
Visualising program structures (perhaps based on metrics) provides insight about the system as a whole.
Critics signal potential problems in a model or a piece of code. Typically they check for correct use of idioms and heuristics, and detect bad-smells.They might also be used to check situational rules like
A specific case of critics are tools that create, maintain, detect or check patterns in software. Some work that is/has been done in this area:
Once you found the problems, you want to improve it. Refactoring is an approach to do this in a systematic way. Refactoring tools can provide help. Keeping your software working requires continuous testing. The unit family of programs provide a framework for this.
Fully automated improvement of programs is of course very interesting. Here are some pointers.
Gert Florijn - Last modifed: 06/02/03