JavaWorld
addict
Reged: 06/20/03
Posts: 482
|
|
Improve the quality of your J2EE-based projects
|
Anonymous
Unregistered
|
|
Good Article.
-Nitin Bhavsar
|
David Rappoport
Unregistered
|
|
Great article!
Our project is currently in a refactoring phase, with a focus on quality improvement. This article has been very helpful! Thanks!
|
Anonymous
Unregistered
|
|
Great Stuff! I learnt some quality measuring tools from your article.
TC 
|
Anonymous
Unregistered
|
|
This article amounts to telling a child where to purchase a gun, showing him how to load it, and walking away as he shoots blindly.
How is a project manager supposed to interpret the metric results?
How is a project manager supposed to interpret the code coverage results?
The data one could obtain from using the tools in this article is at best useless and at worst harmful because of misinterpretation.
|
Jimmy Jarrett
Unregistered
|
|
The data from the tools is very specific. All of the tools used to increase the quality of the code itself identify both the problem and the exact line of code where it can be found.
You are correct regarding the interpretation of the information obtained from the plug-ins. Interpretation of the results, and what to consider or not to consider important for a project was not discussed. It was left out intentionally as interpretation of the results is extremely dependent upon varying factors such as the configuration of the plug-ins, the size of the system being developed, the design of the system, the seniority of developers, and the overall code quality that you wish to achieve.
Interpretation of the results and the reasoning behind what each result means and the actions necessary to address the problems, as well as the risks associated with not taking action, would be extremely entailed and worthy of another article in and of itself.
With that being said, lets see if I can provide you with information to aid you in determining how you want to interpret the results.
Interpretation of the metric results will depend on a fundamental knowledge of the types of metrics that are gathered. Information on the various data types gathered with the Metric plug-in can be found on the metrics plug-in page (http://metrics.sourceforge.net/).
Interpretation of the code coverage results will depend on how your system is designed and the goals you are attempting to achieve. For example, do you wish to have complete code coverage, or only partial code coverage? Full code coverage is extremely difficult to achieve. Per the article, I suggest you use the Source Summary Report to ensure the most critical code pieces are fully exercised. At a minimum I suggest identifying the classes that contain the core business logic and setting a level of coverage that you expect your team to maintain.
|
Anonymous
Unregistered
|
|
While your convictions are noble, my original argument is unanswered.
I assert that blindy using measurement tools is worse that no measuring at all. Why? Because people try and invevitably fail at the measurement process. Then they blame the results on the tools when the problem lies in the process itself.
For example, you mention obtaining information about the metrics in question. What does that information provide me? Software measurement is a process that, IMHO, should only be performed by trained statisticians. That means ye humble developer is probably excluded from that pool.
You then mention code coverage tools. Your two suggestions are attempt to cover everything or attempt to cover what you think is important. I could easily show that blindy selecting core components would result in equivalent coverage. What is needed is a way to qualify the critical paths in the sofware. Guessing at those paths is synonymous with guessing where the performance bottlenecks are in a system. Neither leads to success.
This isn't meant to be rant. I'm simply tired of seeing people try and fail day-after-day at software measurement.
|
Jimmy Jarrett
Unregistered
|
|
There was no argument towards your assessment that the article did not provide information regarding interpretation of the information obtained from the tools. That information was simply not within the scope of the article. I believe the level of detail you are looking for would be extremely entailed and take at least one article, if not more, in order to properly convey the information. Would you like to read a follow up article (or series of articles), that discusses how to interpret the results for each Plug-in?
It should be noted that using any tool, product, language, or yes, measurement tool as in the case with the plug-ins, without a fundamental understanding of how to use it has a high probability of leading to failure.
In the case of the metrics tool, understanding the meaning of each metric is the first step into determining the metrics you will gather (you may not want all metrics), the importance you place on each one, and the success/failure criteria you deem necessary for your project.
I advise against full code coverage as it is a lofty goal that is nigh impossible to achieve. As you mentioned, you could select any number of components in a system, and the code coverage percentage would be the same, however, while blindly selecting the components would lead to the same percentage of code coverage, it would not lead to the same quality of code coverage. As I indicated in my initial reply, system designs vary, in the extreme at times, however, I believe that most developers will have a fundamental understanding of where the core business logic of a system resides. In a J2EE system, I would want to make sure all of business methods in my service classes are fully tested (StatelessSessionEJBs). This means that 100% of the lines of code should be tested in these classes.
You mention the following Software measurement is a process that, IMHO, should only be performed by trained statisticians. Throughout my career, I can honestly say that I have never had the luxury of an additional resource, such as a trained statistician, to measure the quality of the system. Most of the time development teams are short on the resources necessary to provide a solution within a given time window, and team members find themselves wearing many hats, from change management, to quality assessor, to performance engineer, and the list could go on.
A fundamental understanding of the tools is necessary in order to understand how to interpret the results. By taking the time to research the tools, and learning how to use them, you will be better equipped to determine how to interpret the results.
To Summarize:
1) Research the Tools
2) Understand the Data Points They Provide
3) Identify the Data Points you consider necessary
4) Identify failure/success ratios for each Data Point
|
Vlad
Unregistered
|
|
http://emma.sourceforge.net
|
Alexei Ledenev
Unregistered
|
|
I will not agree with you. We are successfully use tools mentioned in this article in several projects. I will try to explain benefits for most tools in current article.
Common coding convention is a good thing, makes your code easier to read and maintain. We use Checkstyle to check coding conventions rules. We use the same configuration both in automatic Ant reports and IDE. Using some code formatter tool (integrated into IDE) can make task writing according to code conventions much easier. As code formatter we use Jalopy.
Unit testing is essential part of development, I will not drill down into why it is good there are a lot of articles and books for this subject. All I can say we saw a real value using JUnit over last year. Coverage report generated from unit tests run will give you a nice picture what areas of your code are covered by your tests.
Everyone knows that code review is a valuable but hard process. Trying to simplify this process is a good thing that Jupiter is targeted to do. We do not use Jupiter (I saw it first time in current article). We use other tools to do an automatic code review: PMD for static analysis, JDepend for architecture and Simian for finding duplicate code.
Now if you will take all generated reports and put them on timeline for every nightly build, you will get a nice dashboard reporting different quality metrics for build you produce.
|
Anonymous
Unregistered
|
|
If you're a project manager, then earn your pay and read the documentation of each tool. You're paid to solve problems, right?
|
Paul Laborte
Unregistered
|
|
Great article. Can't wait to give these tools a try.
|
Previous
Index
Next
Threaded
Edit
Reply
Quote
