Skip to content

viadee/sonarIssueScoring

Repository files navigation

SonarIssueScoring

Build Status Coverage

This is a tool for prioritizing SonarQube issues, to fix the most important technical debt first. It is mainly intended to be used with SonarQuest, but can be used standalone as well.

This tool incorporates a prediction of which files in a repository will change, this is usable without SonarQuest as well.

Getting started

Quality Evaluation

Evaluate the quality of the repo prediction vs the actual future

curl -O http://h2o-release.s3.amazonaws.com/h2o/rel-yates/4/h2o-3.24.0.4.zip && unzip h2o-3.24.0.4.zip && cd h2o-3.24.0.4 && java -Xmx4G -jar h2o.jar &
git clone https://github.com/viadee/sonarIssueScoring.git && cd sonarIssueScoring
mvn compile exec:java -Dexec.args="--evaluate --repo=https://github.com/apache/commons-lang.git"

Rest API

Clone the repository, and execute mvn compile exec:java in a command line. Additionally, a running H2O-Server (version 3.26.0.10 or greater) is required.

This is all required setup for SonarQuest, alternatively the REST-API can be used directly:

Ordering issues by their desirability to be solved (entry point: IssueController):

curl -sSd '{"sonarServer":{"url":"https://sonarcloud.io"},"sonarProjectId":"commons-io_180410","predictionHorizon": 256,"gitServer": {"url":"https://github.com/apache/commons-io"},"h2oUrl":"http://localhost:54321"}' -H "Content-Type: application/json" -X POST http://localhost:5432/issues/desirability

Alternatively, only the change count can be predicted (entry point: FileController):

curl -sSd '{"predictionHorizon": 256,"gitServer": {"url":"https://github.com/apache/commons-io"},"h2oUrl":"http://localhost:54321"}' -H "Content-Type: application/json" -X POST http://localhost:5432/files/predict

Both endpoints support text/plain and JSON via the accept header. It is also possible to specify an absolute path (like "url":"C:\\Users\\Any\\Projects\\EvaluatedProject" or "url":"/home/Any/Projects/EvaluatedProject") instead of an git server url.

Evaluation

To evaluate the prediction quality, run the main class / maven call above with the argument --evaluate. This will predict the future for a default project, and compare it with the real, unseen future. This process does not start the REST api.

This evaluation can further be customized with the arguments --repo=, --user=, --password= and --horizon=

Functionality

This tool consists of two major parts, the first one being the Desirability-Score for calculating the importance / desire for a fix of a specific issue. An issue can be made more important by a lot of different criteria, such as a high SonarQube-Severity rating. Additionally, an issue is more important if the containing file is edited soon - therefore the second large part is the prediction of whether a file changes.

Desirability Score

The Desirability-Score of an issue consists of a number of different Ratings for different aspects. Each rating represents the importance of an issue with this specific aspect in contrast to the same issue without this aspect. For instance, an issue regarding security is 1.5 times more important than an issue not regarding security.

Thus, the final Desirability-Score is the product of all ratings, and expresses the importance of an issue over a hypothetical issue with no interesting properties except its existence.

A number of different Ratings are used:

  • Age: An issue is more important if it is younger, to promote fixing the leak. Additionally, younger issues are more likely to be still in the developers head, and therefore faster to fix.
  • Effort: This is used to deprioritize issues with a very high required effort for fixing them, as they leave less room for other refactoring
  • Severity: Issues with a high severity by SonarQube are naturally more pressing to fix.
  • RuleType: Bugs are more important than code smells.
  • Tags: Different tags have different assigned ratings - for instance security issues are more pressing to fix.
  • Number of issues in a file: A file which has a lot of issues should be refactored soon, as otherwise the problem could worsen, as the class is "bad anyways".
  • Centrality: If a file is used by a lot of other files, it should be fixed sooner, to avoid spreading bad design decisions.
  • Directory / Package: Directories can manually be set as more important, to focus on specific parts of the application.
  • ChangePrediction: Most issues are way less relevant if the file is not going to be edited again. As this is information from the future, it can only be predicted.

The Desirability-Score is primarily implemented in de.viadee.sonarissuescoring.service.desirability, the entry point is DesirabilitySource.java

Change Prediction

The Change Prediction uses a number of different features, which are extracted out of the git-history of the predicted project. For this, the git history is linearized, only changes to the master branch are used. All changes to any side branch are only considered on merging.

These features are created for different times in the past - all this data is used to train a H2O model.

This model is then used to predict the actual future - the result is fed into the Desirability-Score.

This is primarily implemented in de.viadee.sonarissuescoring.service.prediction, the entry point is PredictionService.java.

Development setup

This is a standard maven project.

License

This project is licensed under the BSD 3-Clause "New" or "Revised" License - see the LICENSE file for details.

The licenses of the reused components can be found in the dependency overview.

Additionally, DependencyVisitor.java is mostly a copy of CBO.java from the Apache2-Licensed ck library

About

Where do we refactor next? A predictive maintenance approach to java code smells.

Topics

Resources

License

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published

Languages