Code Quality
Although there are coding standards put in place which include CheckStyle, PMD, and FindBugs rules, these rules are not used with their respective Maven plugins and the M2E code quality plugin. The code quality is validated using SonarQube instead of Maven or M2E.
The main reason for this choice is purely technical for the most part.
- There were inconsistency and difficulty of getting Maven to generate the site correctly with the proper rules loaded and the exceptions of ignoring generated sources getting applied correctly.
- It has issues running on M2E environment and the exclusion configurations do not always load up correctly.
- In certain instances, we get build loops on M2E.
- Using SonarQube allows the enterprise to manage the quality rules separately from the project.
For the non-technical reason, the Maven core plugins had changed their defect reporting policy making it difficult to report and have defects with their plugins addressed. Although this is relatively the same policy that SonarQube also has, there are less technical problems to deal with on SonarQube. The enterprise policy may change this later, however as of this time SonarQube is chosen.
Issues with the approach
The problem with this approach is the lack of local and build-time testing as it now requires access to a SonarQube server to perform the tests rather than the IDE.
However, the reality of enterprise projects is technical debt is a norm and keeping that debt at zero may cause the business to miss the market.
In addition, the most of the bad practices are mitigated by:
- using m2e-codestyle-maven-plugin which will configure the IDE to perform the necessary coding cleanups.
- The Eclipse JDT already provides several errors/warnings for marking potential coding problems on the IDE.
Thereby reducing the need to have the extra analysis being performed by the IDE itself.