JBuilder 2008 comes with LiveSource™ functionality that will reverse and forward engineer Java code. This means that if you inherited a large amount of Java code, JBuilder can reverse engineer the code and produce a series of UML diagrams. This alone would be great, but since it uses the LiveSource™ functionality, it means that any changes made to the generated diagrams will result in the code being changed and vise-versa. So the code and diagrams are always in-sync. This is a huge advantage when trying to understand what has been inherited. The old saying "a picture is worth a thousand words" is correct because most development teams have never seen a high-level picture of what they have been developing, and this gives them that capability, plus a whole lot more. Many things can be learned from the high-level Object diagram, but even more can be learned with Sequence and Communication diagrams, which will be used later in the analysis phase for a better understanding of the code.

It is extremely important to get an understanding of the health of the object code. One of the fastest ways to accomplish this is to run software Metrics on the code, which will give a wealth of information back on the code's construction and strength, the weak or problematic spots, and much more general information. JBuilder 2008 includes over 80+ software metrics to fill this need; things like the simple metric of Lines of Code (LOC), the more in-depth metric Cyclomatic Complexity (CC), the more advanced metric Instability (I) and many others, help to report on the health of the code. Once the metrics have been generated for the code, a great tool that helps to visualize this information is called a Kiviat graph. This graph shows where the metrics stand with regards to other metrics in the system, thus allowing users to have a very quick visual understanding of the health of the code.

Once the health of the code from a structural standpoint is better understood, then the focus can move more towards issues of style. The use of the word "style" usually catches developers a little off-guard because code-style can be very subjective and most developers do not like to conform to a specific set of code-writing rules. However, the use of "Style" in our context is really looking for blatant issues that should be fixed because most likely they will cause errors, bugs, or misunderstanding going forward. JBuilder 2008 includes over 200+ code audits. These include everything from possible performance issues, possible errors, duplication of code, and many more. Some of the newer code audits use the above metrics in new ways to highlight various areas of concern with the code.

Both the code metrics and audits come with ways of reviewing test cases or lack of test cases. One of the most important things that are needed in today's complex systems is good testing. Ironically, most code that goes through the process of Software Archeology has very limited or no real testing included. This is almost a game changer in many respects; if you don't have simple testing established, it will be very hard to harvest patterns, change the code in any meaningful way, or integrate with other systems because the confidence level of what the code is supposed to do... is just not there. If the metrics and audits show that there is no unit testing, the question should be raised immediately "What is next?" If the code were considered to be working and "right" then most likely the best approach would be creating "Characterization" tests. For more information on Characterization tests, review this Wikipedia page: http://en.wikipedia.org/wiki/Characterization_Test. It is nice to know that JBuilder 2008 fully supports JUnit and many other great testing tools to help in this area.

As with Business Logic Reviews, the performance review is usually just as important. What is great about going through this process is that JBuilder 2008 will help point you to where the code is going to be slow or not perform well. You will get a fairly good idea from the metrics and audit phase of where those locations are. JBuilder comes with the Optimzeit technology, which includes both a Java Profiler and a Web Java Profiler that can find the exact line or location of the code that is causing the performance issues. The general rule is that less than 5% of the code causes 80% of the slow down, so having the ability to find and fix that 5% is crucial.

It is important that any diagrams, tests, metrics, audits and performance data can become part of the overall documentation set. One of the great features of JBuilder 2008 is the fact that it comes with Documentation Generation that does exactly that. When you generate a UML diagram it becomes part of the overall documentation, as well as when you run a metric or audit, those become part of the documentation. This feature allows future developers to have a better understanding of the code, and also have the added benefit of giving all of the developers on the team the ability to share the information.