Hello. I'm Jason from SPEEDA's development team
A developer's work (and even life) revolves around writing and testing codes. As a developer, I, like many others, take pride in my codes which are clean, elegant, and bug-free. And so we do our best to achieve this.
I must admit, though, that even as a seasoned developer, I do have some shortcomings. SonarQube classifies these shortcomings as the "Seven Deadly Sins" which are considered as capital sins committed by developers everyday.
- Bugs and potential bugs
- Coding standards breach
- Duplicates
- Lack of unit tests
- Bad distribution of complexity
- Spaghetti design
- Not enough / too many comments
For more description you can visit the SonarQube: Developers' Seven Deadly Sins - SonarQube - Confluence
One way to avoid these pitfalls is through peer review. We should not be afraid to ask others to review our codes so we can be aware of our weaknesses. Similarly, we should also take the time to review other's work. This helps ensure that we deliver quality but this does not guarantee 100% error-proof codes (after all, reviewers are also humans who commit errors). They may improve 90% of the code but will still miss the remaining 10%.
Some people claim that the practice of peer review is a waste of precious human resource. They argue that more experienced developer can contribute more to a project through other means other than reviewing their colleagues' codes. While they may have a point, in my experience, review improves everybody's coding skills because of the reviewers give correct solutions and tips. Meanwhile, the reviewee (or the developer receiving the feedback) learns from the more-experienced colleague. This exercise becomes an avenue for knowledge sharing in the company.
From the project management perspective, one would like to measure or quantify the developers' improvements in the peer review practice. But since we don't really count how many feedbacks a developer has for his code, we can't really give a number to the project managers.
But I believe that these problems can be managed through a platform to manage code quality called SonarQube.
What is SonarQube?
"SonarQube is the central place to manage code quality, offering visual reporting on and across projects and enabling to replay the past to follow metrics evolution."
It is open source, extensible with custom plugins (and we can even create one ourselves), we can integrate this with other systems (such as Jenkins), and supports 20+ programming language (In our case we will just use Java).
I've actually implemented this with our current codebase and there were, indeed, some simple misses in the codes (it might have been overlooked by the reviewers). But due to confidentiality, I chose to hide the numbers and the source codes here in this entry.
This is a screenshot of the dashboard of SonarQube's demo: SonarQube
We can see the technical debt (what the developers have to "pay" to fix the issues) is set to 82,176 days. Assuming that 1 person will work in 8 hours a day, it will take that developer to fix everything in 82,176 days. (And also assuming that it won't increase anymore). There are 14,937,000 lines of codes there, and 2,714,682 issues. Issues are categorized as Blocker, Critical, Major, Minor, Info. Depending on your company, you will need to determine how they should be dealt with.
In the code below, you can see SonarQube gives suggestions as to the best approach for this case. Of course, SonarQube will not always be correct since we may be following the company's coding standard. We can actually adjust the rules of SonarQube to fit our company's coding standard.
This is another example of a code that doesn't follow JavaBean's Naming convention and the complexity of this code is quite high based from SonarQube's calculation.
You can also assign the technical debt tasks to your teammates (You can integrate this to your JIRA or Redmine so it creates tickets which the Project Leader could also manage)
Here we can customized the rules SonarQube is following
We can also see which codes got duplicated (or copy paste instead of refactoring and reusing the same code)
And here is from another file with the same codes
There are still tons of functionalities which SonarQube has but I haven't explored yet.
Regarding installation, setup is a breeze so I highly recommend you try it on your codebase.
To sum up,
SonarQube is not just for developers, but for everyone involved in the project:
- For developers, it helps them check if their code is correct and follows the correct coding standard.
- For QA, it helps them check the test coverage of unit test (they make sure that every code is tested on unit level)
- For Architects, it helps them check if the architecture of the system is correct, and that no codes are having a spaghetti code design.
- For Managers, it helps them see if developers are actually improving (they can monitor if technical debt actually decreases) and can use this for future decisions (i.e. they can delay the release of a functionality because it's technical debt is too high).
"Quality is everyone's responsibility" - Deming, W. Edwards
If you are the type of developer who takes pride in your skills and values code quality, or if you are interested in learning new and interesting technologies, then we want you!
You can try checking this link 株式会社ユーザベースの最新情報 - Wantedly and give us a contact!
