Effective tools, gates, and accountability can help ensure your system’s success
any people incorrectly judge Java/J2EE-based systems on problems associated with maintaining the codebase, the number of bugs or inconsistencies in functionality, or poor performance. Fortunately, these problems have less to do with the Java/J2EE technology itself and more to do with the lack of a process focused on the quality of the system. To ensure success of large-scale Java/J2EE projects developed by a sizeable team, or across multiple teams, a team lead must:
- Use tools that can measure quality
- Define a set of gates and artifacts derived from the tools
- Stress accountability to deliver, monitor, and enforce the results
This article explains how incorporating these three tactics into your development strategy can ensure that your team consistently produces quality projects.
Importance of tools
Have you ever heard of a construction company attempting to build a house without a power saw, electric drill, or a tool as fundamental as a hammer? True, a house could be built without today’s new-fangled equipment, however, construction would take much longer, and the same level of quality would prove nearly impossible to achieve. You could build a hut with your bare hands, but you could build a mansion with the right tools.
Today’s developers are no different than a person attempting to build a house. The tools are essential to the developer, both for increasing productivity and for enhancing quality. The tools developers use must enable them to produce the highest quality code possible in the shortest amount of time, which means that today’s IDE is no longer simply a tool used to write, debug, and compile code. Instead, an IDE must help developers identify whether they are following proper coding conventions and known design patterns, if they are in compliance with industry standards such as Web services, if their code adheres to its contract, and if it performs per the requirements. In addition, when developers are not given the environments necessary to achieve continuous builds and automated testing, an IDE’s capabilities become even more important to ensuring the system’s quality.
Enter the Eclipse IDE, which provides built-in capabilities that, when used with several plug-ins, can aid in increasing the quality of both the codebase and the system. Eclipse is an open, extensible IDE built for anything and nothing in particular. Eclipse’s Java development environment is open source, free, and fully customizable. Eclipse both enables and promotes the addition of new capabilities via open source and commercially available custom-built plug-ins. By utilizing Eclipse, along with a key set of plug-ins illustrated in the Eclipse plug-in matrix shown in Figure 1, it is possible for a developer, and a team, to measure the quality of any J2EE- or Java-based system.
Figure 1. Eclipse plug-in matrix |
Controlling the quality of a system is impossible if you cannot measure and monitor it. It is important to understand key areas in a system that warrant measurement. These areas include a system’s maintainability, reliability, and performance. While this list is obviously not all-inclusive, these three items are highly suited as the basic building blocks for ensuring the quality of a system.
Maintainability involves the complexity associated with understanding the code or modifying the code, whether it is a bug fix or an enhancement. Well-documented code that follows known coding standards and industry design standards is easier to maintain than code with sparse documentation that doesn’t follow any known standard development practices. Highly maintainable code allows changes to be introduced more quickly, thereby permitting the business to respond more rapidly to new requirements or change requests, and ultimately reducing the overall cost of both new features and ongoing maintenance.
Reliability indicates whether a method adheres to its contract and can be executed successfully. Unit tests are used to exercise a method’s contract, thus verifying the reliability of the code segment. The quality of the unit tests, in turn, is verified via code coverage analysis. Many approaches are available for measuring code coverage, including, but not limited to, statement, decision, condition, path, and call analysis. The type and amount of coverage necessary to provide absolute reliability of a method is a popular discussion topic. For this article’s purpose, simply note that reliability increases as the amount of code coverage increases.
Method reliability within a system is of the utmost importance as it represents, to some extent, a system’s stability. Other problems, such as performance or scalability issues, could arise, which may not be as readily found even with extensive unit testing and coverage analysis. Thus, unit testing and coverage analysis are by no means a be-all, end-all solution to ensuring system stability; however, the ability to reliably execute methods consistently represents a good measuring stick of the system’s reliability.
Performance is typically measured on a per-unit-of-time basis. A system’s ability to process numerous requests, to the amount of information sent over the wire, to the response time of a particular system call, are all performance criteria measured based on a unit of time. It is important to know, to some extent, how the system will perform. To ensure this understanding, one could measure all major service methods or potential problem areas with expected high usages, long call stacks, or those pieces that represent the most common paths through the core architecture. Each approach provides a varying level of comfort with regard to performance. For large-scale systems, performance should be continually maintained and monitored during development to identify snags early and avoid unforeseen problems in production environments.
Let’s now examine how the use of Eclipse and its plug-ins can help a development team, measure the maintainability, reliability, and performance of any Java- or J2EE-based system.
Code generation: Maintainability
Code generation is one of the best ways to ensure consistency and quality for repeatable code that differs based on type. XDoclet is currently the industry standard for generating Java source code. XDoclet is an open source, free library that parses the codebase, looking for custom Javadoc tags (metadata) that it then uses to generate other Java source files. XDoclet contains a set of Javadoc tags that may be used to generate most of the repeatable code found in the majority of Java/J2EE-based systems, such as JavaBeans and home and remote classes for Enterprise JavaBeans, even providing specific information for Borland Enterprise Server, JBoss, Orion, Resin, Sun Java System Application Server, WebLogic, and WebSphere. It also supports many other technologies such as Hibernate, JDO (Java Data Objects), and Castor. If that isn’t enough, XDoclet is extensible, allowing developers to create their own custom tags for generating homegrown code. By employing XDoclet and letting it generate code for you, you can reduce unnecessary coding errors and bugs found in repetitive code.
Code metrics: Maintainability
Due to the large size of codebases, visually monitoring the entire codebase is unachievable. Instead of walking through every line of code, metrics may be used to identify both existing and potential problems. The Metrics plug-in for Eclipse is an open source, free tool that can generate metrics on a per-class, per-package, or per-project level. The results may be exported to an XML file for historical purposes. It also contains an Ant task that can be used to generate the XML file at build time.
The Metrics Eclipse plug-in provides more than 23 types of metrics. Some of the most important metrics include number of interfaces, depth inheritance tree, number of overridden methods, McCabe’s cyclomatic complexity, afferent coupling, efferent coupling, and abstractness. By default, the Metrics view displays the compliant metrics in blue and the outliers in red. Anything in red represents a possible problem in the code that should be reviewed. The plug-in has its own view and runs in the background; thus, it can not only be used by a team lead at the end of an iteration, but also by developers as they code.
Code reviews: Maintainability
A code review is a useful exercise that helps ensure code quality, while also training and mentoring developers on coding style and coding best practices. Jupiter is an open source, free tool that allows team-based code reviews. Jupiter uses XML files to track individual team member reviews with a review ID and a reviewer ID (the review ID is shared for team-based reviews). These files are then checked into source control and made available to other developers, allowing for multiple reviews to occur simultaneously, without a server managing the reviews.
Each team member uses an XML file to check in and out of source control and see what needs fixing as well as what has been fixed by other team members. The use of Jupiter is a great way to tag required fixes without enduring the rigor that normally surrounds bug-tracking policies during new development. Jupiter frees team members to review code at their convenience, instead of forcing them to stop development at a time when they might be solving a problem to attend a code review meeting.
Standards adherence: Maintainability
Development standards exist to ensure past mistakes are not repeated. In addition, they ensure the code is consistent and more readable for the developer who must later maintain the code. Eclipse comes with a built-in code formatter that adheres to Java coding conventions. While this is a great feature, a code formatter is not enough to ensure the production of quality code.
Checkstyle builds upon Eclipse’s code-formatting capabilities, adding more than syntactical checks. It can identify noncompliant code blocks, coding problems, duplicate code, and some metrics violations. Even better, Checkstyle is extremely customizable, allowing the user to tailor the types of checks and their level of severity per the development standards within the organization. The default configuration file that comes with the Checkstyle plug-in is extremely comprehensive. Even so, I suggest developers invest their own time to customize this plug-in to match their organization’s development needs. Once customized, the Checkstyle configurations may be exported and used from project to project. The results of Checkstyle are displayed in the Problems view, which may be filtered and sorted. Results may be viewed at the folder, working-set, or resource (file) level, allowing developers to understand the quality of the overall codebase, subsystem, or individual class.
If your team is engaged in Web services development, then WSVT (Web Services Validation Tools) is a must-have plug-in. WSVT can determine if a Web service conforms to the guidelines and requirements defined in the WS-I (Web Services Interoperability) Basic Profile. Developers can right-click on a WSDL (Web Services Description Language) file, and it validates the WSDL and generates a report in a custom view that displays any violations. As an added bonus, the WSVT plug-in monitors TCP/IP traffic and observes, captures, and validates SOAP messages. The WSVT plug-in thus ensures compliance both at the interface and message level.
Functional testing: Reliability
Eclipse ships with both Ant and JUnit. Ant is the de facto industry standard for building Java-based applications. JUnit is a Java-based framework for creating unit tests.
Developers can set up individual JUnit tests to run in Eclipse, which provides a special view for the JUnit results, or use the Ant JUnit or JUnitReport task. The JUnitReport Ant task generates an HTML viewable report that may be used to represent the entire system’s tests, or specific tests, depending upon the customization. The HTML report is an excellent report to save for historical purposes as it can be used to gauge the project’s quality. By using JUnit for unit testing, developers can ensure their methods adhere to their contract, thus avoiding bugs that arise due to noncompliance.
Code coverage: Reliability
When developers write unit tests, they should understand how much codebase coverage their unit tests provide. GroboCodeCoverage is an open source coverage tool that integrates with Ant by providing an Ant task that can generate coverage reports. Individual reports may be generated, such as the Line Count Report and Function Count Report, which provide coverage percentages at the line and method level, respectively. However, the cornerstone of the tool is its Source Summary Coverage Report. This report mimics the Javadoc structure and provides a quality professional report that may be stored for historical purposes. As the project progresses, the report can be referenced to understand whether code coverage increases or decreases over time. By using GroboCodeCoverage, developers can ensure their most critical code pieces are fully exercised and pinpoint areas that lack coverage. Using this information, they may add or update existing JUnit tests, thus increasing system reliability.
Profiler: Performance
As projects near the end of the construction phase, developers tend to start thinking more about performance. Profiler for Eclipse is an open source, free profiler that provides many of the features that a developer needs for solving common performance issues. It shows the threads, the heap size, heap dump, method calls, method times, calls per package, and thread call-trees that allow a developer to see where time was spent through the flow of a call. Profiler for Eclipse helps developers understand where the application’s bottlenecks are occurring, allowing them to correct problems before releasing the application to the QA (quality assurance) department or production.
Next page >
is a visual modelling tool for 
订阅
阅读列表
