Introduction
In this post, I'm going to write about "Why & How to measure your code of software project. And improve it."
I am going to mainly write about this topic from the static code analysis point.
Why Measure?
There are number of reasons to measure your code.
For me especially following reasons (or intentions).
- Daily Health Check
- Keep code base clean
- See impact on entire code base by your code change
- Detect problems as soon as possible
- Feel improvement!
- Let every team members show what happens
- Monitor test result status
- Follow coding standard
Especially in team based software development, a lot of people change code for different task.
And each developer is hard to know what each developer change the code for what purpose.
If the source code measurement is public for everyone, it helps everyone to know affect of entire project which the other developers make.
What to Measure?
There are a lot of measurement is proposed but from static code analysis point, I think following covers enough for software project.- Lines of Code (LOC)
- Copy and Paste
- Code Complexity: Cyclomatic Complexity, Npath Complexity
- Compliant of Coding Standard
- Test Success Rate
- Test Coverage
- Elapsed time of Build/Test Running
- Number of Slow Query
- Technical Debt: Introduced by SonarQube. It calculates technical debt, whose unit is time, from code complexity or compliant rate of coding standard, etc. based on configured rules
Measurement Principles for Team Based Software Development
Before going into introduction to concrete software tools, I will show you my own principle for measuring code.
- Automated
- Continuously Measured
- Public = Shared with everyone
Hope you agree with above points. Let me explain a bit about above points.
Automated - needless to say if you are a software developer having common-sense :)
Continuously Measured - Measure every small change is quite important because you can detect the change (doesn't matter bad or good) as early as possible.
In current software development world, project requires quicker and more frequent changes than before, and much more in the future.
This means measurement process should also follow with this trend.
Public = Shared with everyone - You can also use plugins on private IDE. But this is not recommended for software development based on team. Because ONLY you can run the tools and see the result.
Tools
PMD (Program Mess Detector)
This tool can calculate cyclomatic complexity or NPath complexity and aggregate by method or class or file. Then show alerts if the calculated value is higher than configured threshold.
It also show us unused variables and (private) methods.
This tool covers almost all major programming languages except PHP :P
If you would like to use it for PHP, use PHPMD.
I suggest use this with CPD (Copy & Paste Detector). Somehow CPD supports PHP.
Checkstyle
This checks written code is compliant for configured coding standard rule.
If the code violated rule, it show us an alert.
Findbugs
This tool can detect the code which is bug or may introduce bug.
SonarQube
Most powerful tool for tracking the source code or project analysis result. It introduces "Continuous Inspection"
You can analyze almost everything - LOC, Compliance of coding standard, Complexity which is a kind of PMD provides, Code Duplication, percentage of comments, test coverage rates etc.
It provides "Time machine;" functionality - you can check time change of measurement on visualized graph.
It covers all major programming languages and provides a lot of plugins.
It also calculates "Technical Debt", whose unit is time, based on your configuration.
I highly recommend SonarQube!
Build Tools
Build tools are not directly involved with source code analysis but these are so important to achieve "Automated", "Continuously Measured" process.
The major tools I can think of in 2015 are below:
Testing Tools
If you would like to analyze testing result or measure test coverage, you should use test automation tools.
This post is not aimed for introducing testing tools so I just only give you some tools.
- xUnit: JUnit, PHPUnit, Nunit, etc.
- Coverage: clover, emma(Java)
- Mock tools: Mockito, JMock, Easy Mock
- Web Testing: Selenium, JsTestDriver
By contrast to Java, for example PHP, PHPUnit provides all mock, test coverage functionalities.
Continuous Integration Server
So far I introduced a bunch of tools which analyze source code itself.
Of course you can run these tools independently but this doesn't meet my principles - "Automated", "Continuously Measured", "Public"
In order to meet the principles, we should use continuous integration server
I think Jenkins is the most popular one but there are good commercial CI servers, too. Such as TeamCity or Bamboo.
If you have a money or budget, I think you should consider these commercial CI servers.
For example for Jenkins, there is a plugin for visualizing PMD, CPD, Checkstyle, Test coverage result more human readable format like Violation Plugin.
You can also track time changes of number of test cases and elapse of test running.
How to Evaluate?
Now you can get and see bunch of source code measurement.
But the next step, evaluation of the measurement is as important as measuring itself.
Let me show you my evaluation standards.
- Number of Test cases: Doesn’t matter
- Test Coverage: Higher is better. But should NOT achieve 100%! It's waste of time!
- Duration of Test Running: Faster is much better
- Code Duplication Percentage: Lower is better – DRY principle
- PMD (complexity, unused variables and methods etc.): Lower is better
- Lines of Code: Less is better
Another important evaluation point is tracking time change.
You can compare measurement between any software projects. But for me this is not so important because the background of project is so different.
Rather than comparing between projects, I think comparing measurement result between same project is much important.
Pitfall of Measurement
The trap someone usually falls into is "Measurement and improve measurement itself becomes the purpose".
For example, trying to achieving 100% test coverage is very good attitude.
But this doesn't mean test quality is good.
And also Achieving 100% test coverage costs a lot of time (=money).
In the real software development world, we work for project success in the first place.
For each project, you should carefully choose what kind of tests should be done and what kind of tests should be skipped.
I think a good (business oriented) software developer knows this kind of cost-benefit performance and can balance test granularity properly.
Final Words
Before Blaming "What a crappy code!", you should measure, improve the code and show the improved evidence!
Measurement result should be public for every team mates.
Measurement is measurement, Not itself is the purpose.
Good Luck! Hope this post help your software development ;)
コメント