The process of Software Archeology can really save a significant amount of work, or in many cases, rework. So what challenges do all developers face when asked to do these kinds of projects?

• What have I just inherited?
• What pieces should be saved?
• Where are the scary sections of the code?
• What kind of development team created this?
• Where are the performance spots I should worry about?
• What's missing that will most likely cause me significant problems downstream in the development process?

• Visualization: a visual representation of the application's design.
• Design Violations: an understanding of the health of the object model.
• Style Violations: an understanding of the state the code is currently in.
• Business Logic Review: the ability to test the existing source.
• Performance Review: where are the bottlenecks in the source code?
• Documentation: does the code have adequate documentation for people to understand what they're working on?

So if it really can't be done by hand, what tools do I need to get the job done? Let's break down the process step-by-step and look at the tools that could be used to complete the task. Some advanced IDEs exist that include all of these tools and there are open source-based tools that may be able to do some parts of the job.

Visualization is the first step to understanding what kind of code the developer will be working with. It always amazes me how many developers have never looked at a visualization of the code they've written. Many times key architecture issues can be discovered just by looking at an object diagram of the system. Things like relationships between objects and level of inheritance can be a real eye opener. The old adage is true: a picture can be worth a 1,000 lines of code. When thinking about visualization in an object-oriented language like Java, UML diagrams seems to be widely used and understood. Being able to reverse-engineer the code into a class diagram is the first tool that's needed. Later in the process it will be important to be able to reverse-engineer methods into sequence or communication diagrams for a better understanding of extremely complex classes and methods.

Once visualization of the system is done and reviewed, the next step is reviewing the system from a design violation standpoint. This can be done by using static code metrics. Using metrics gives the developer or team a way to check the health of the object design. Basic system knowledge like lines of code (LOC) or the ever-important cyclomatic complexity (CC) can give a lot of information to the reviewer.

Many developers have no idea how big or small the application they're working on is or where the most complex parts of the application are located. Using a select number of metrics, developers can pinpoint "trouble" areas; these should be marked for further review, because normally those areas are the ones that are asking to be modified. Further analysis can also be done on methods that have been marked as overly complex by generating sequence diagrams. These diagrams offer a condensed graphical representation and make it much easier for developers and management to understand the task of updating or changing the methods. Another valuable metric is JUnit testing Coverage (JUC). In many cases when code is being inherited a low or non-existent number around JUnit tests exists and should raise major concerns about making changes to the system. The biggest concern will most likely become how to ensure that changes made to the code or the fixes implemented are correct and don't break other parts of the system. By using the information generated by the metrics tools developers get a better understanding of what's been inherited and some of the complications around the product.

Style violations help complete the picture of the inherited code. Many developers argue that static code audits should be run first, and this is true from a new project perspective. However, when inheriting massive amounts of code, running metrics first usually gives more object health-based information. Once the health of the object design is determined and can point to various areas of the code that need significant work, the audits can further refine that knowledge.

Static code audits include all kind of rules checking that look for code consistency, standards, and bad practices. Audit tools like ours include 200+ audits and will help in understanding the complexity of the application under review. Advanced audit tools include rules for finding things like god classes, god methods, feature envy, and shotgun surgery. These advanced audits actually use some of the metrics to give the reviewers more information. Take god methods for example. This is a method in a class that gets called from everywhere, meaning from an object design standpoint that method has too much responsibility so making changes to that one method could have a dramatic effect on the entire system. Look at feature envy. This is almost the exact opposite of a god class; this is a class that doesn't do much and maybe should be re-factored back to its calling class. When estimating the amount of time to give to a particular enhancement or determine what kind of code has been inherited this kind of low-level understanding is worth a lot.

Business logic review focuses on the testability of an application. By using advanced metrics the amount of testing available can be determined in a few minutes. Inheriting a large amount of code and finding that no unit test exists for it is going to have a dramatic effect on estimates for enhancements, or make the developers realize they probably don't have a way to verify that any changes to the system are correct. The tools needed for testing business logic should include a code coverage product and an integrated unit testing product like JUnit. Having one of the two is okay, but having both opens a lot of new testing possibilities. First, by running the unit test with a code coverage tool, the code to be tested can be verified. Code coverage can also be used when you don't have the advanced audit tools discussed above, plus a good code coverage tool will show all class and methods included in the run of the test. Using an advanced audit like shotgun surgery will highlight a method that has a lot of dependencies but using unit testing and code coverage together ensures that changes to these types of methods can be fully tested and verified. Another advantage to a code coverage tool is found in QA, which runs the product testing scripts while code coverage is turned on. This will tell them two things: whether the test script is complete and whether there's test coverage for all of the applications code. The good thing about this piece of Software Archeology is that usually it can only get better. By adding additional tests, the end result should be a better running system.

The need for a good profiler is key to performance review. Using the tools and results from the business logic review, performance issues can be uncovered and fixed. A key metric to remember is that only around 5% of the code causes most performance issues. So having a handle on where code is complex makes ongoing maintenance faster and easier.

The last step is documentation. Doing all this work is great for the developer, reviewer, or team trying to understand the system. It would be great if that work could be captured and used going forward. Having an automatic documentation generator saves time, reduces overhead, and helps ensure the documentation is up-to-date. This will make it easier for new members joining a team or for the application to be passed to another team.

The ideas around Software Archeology are fairly straightforward; this article took an approach of inheriting a large amount of code and then being responsible for that code. Other expeditions into the code could produce useful design patterns, great algorithms to reuse, or major things to avoid. We all know that software is an asset so using Software Archeology can ensure we get the most out of that investment.