SONARQUBE IS THE WORLD STANDARD FOR STATIC CODE ANALYSIS
POLICIES AND METRICS: GUARANTEE A SMALLER TECHNICAL DEBT
We uphold the standards of quality expected by your company using SonarQube. One of our jobs is to define the quality policy and metrics for your quality process, and automate your code quality assurance in your DevOps. In this way, we can lower your technical debts and increase the scale of your economy.
Policy
The number of duplicate lines may be up to 3% of the total lines.
Metric
The number of duplicated lines exceeded the quality policy.
Metric
Build not approved!
KNOW WHICH ARE THE BEST (OR WORST) DEVELOPERS
We work to create dashboards to reflect the quality of the code produced in your company’s software factories. Our qualifiable reports will detail duplicate lines, test coverage, code complexity, code alignment in relation to your architecture, who has the lowest technical debt, etc.
DELIVER TRUSTED CODE
In our code quality assurance work with SonarQube, we guarantee that what will be published is the best code possible. We evaluate your code in +25 programming languages, catching complex and difficult to detect bugs and preventing unexpected behavior.
TECHNICAL DEBT
Technical debt is a well-known concept invented by Ward Cunningham in 1992. Since then it has been discussed numerous times in blogs and articles. I will not describe it in great detail here, I prefer to recommend that you read what is considered the reference article on the subject, by Martin Fowler. Below is a part of this article that has a synthetic metaphorical view:
Making projects the "fast and dirty" way places us with a technical debt, which is similar to a financial debt. As with a financial debt, technical debt incurs interest payments, which come in the form of an extra effort we have to make in future development because of the choice to create the "quick and dirty project". We can choose to continue paying the interest, or we can pay the principal by choosing to refactoring the "quick and dirty project" to the best design. Although it costs to pay the principal, we benefit on reduced interest payments in the future.
This metaphor seems to be accepted by many developers since every day someone complains or "tweets" about the urgent need to pay the technical debt. But beyond the concept, when it comes time to assess the amount to be repaid, there is simply no literature on how to calculate the debt or, at least, address it. It is like borrowing money to buy a house, but 2 years later there is no way to know what the remaining debt is and how much interest is being paid each month.
As stated by Martin Fowler, developers are good and sometimes make the deliberate choice to borrow in order to save time. This is true when starting a new development, as you know exactly the amount of the technical debt... That is, 0 (zero). But when extending or maintaining a legacy application, that is another story that no one knows exactly how bad it is. You may not even be aware that you are asking for money when a developer simply does not follow best practices. That is why is very useful to approximately evaluate the technical debt beforehand.
Before introducing this policy and metrics, here are some funny and relevant quotes about the concept:
-
Maintaining an application without any test units is like asking for money each time you add or change a line of code;
-
Ignoring the design phase of a project is like borrowing money to get a very "fast" and "predictable" return on investment;
-
Refactoring is like taking the main debt down little by little;
-
Development productivity decreases when interest rates rise;
-
Managers don't care about code quality, just ask them to pay the debt upfront in order to get their attention;
-
Bankruptcy is the logical extension of uncontrolled technical debt ...we call it a system rewrite.
