Metrics

This week our task was to have a look at some metrics of our code. Therefore we set up a SonarQube instance to scan our project every time we push something to GitLab. Then a pipeline will run and do the actual check.
You can find our SonarQube here and an example pipeline checking the metrics here (Sadly it doesn’t runes trough at the moment but the pipeline is configured).

Unfortunately the basic SonarQube version has only a very limited amount of metrics which were useful for us. Therefore we could only use the Security Hotspot metric from SonarQube for this post. This metric shows you parts in your code where you should pay more attention to keep everything secure, based on known risks from other projects.
We had 4 Security Hotspots and one Vulnerability. Some of those problems could be fixed easily. The first was that CORS was enabled for every origin, which would allow foreign pages to use our API without trusting them. The next was that the API documentation was accessible with different HTTP methods, which allows a wrong usage.
But there were also some problems we couldn’t solve. For example: it is not secure to use the command-line arguments without any validation, but as we don’t use them for custom configuration but SpringBoot requires some args, we ignored the warning. Also there were some warnings concerning authentication, but we could ignore them too because we use Keycloak to manage the users which is secure enough on its own.
This merge request shows these changes.

Before refactoring
After refactoring

To generate some more metrics we also used the MetricsReloaded plugin for IntelliJ.
From that plugin we used the complexity metric to analyze our code. This calculates the cyclomatic complexity for your methods, classes, packages, modules and the whole project. But we only concentrate on the methods. The value represents the number of independent paths which exist trough your function. Before the refactoring we had some methods with a very high value from 9 – 14. But it turned out that this code was a leftover from the static test data we put directly into our code. Therefore this might be a good chance to remove those old lines and put everything into the correct place. This WIP merge request shows the beginning of this refactoring. Also these changes could reduce the values to 4 – 7.

Before refactoring
After refactoring

Join the Conversation

3 Comments

  1. Hey,
    great work you did there.
    Get your productive SonarQube pipeline running through then its perfect.

    Kind Regards,
    GCW

  2. Hey,
    we really like your this weeks post!
    It is very detailed and we can get everything we want from it :b
    We are also pretty sure, that you will be alright as soon as your SonarQube pipe is working.

    Well an CORS is a thing which everyone has to fight with.
    We hope you the best for your project!

    Greetings
    Team Cozy

  3. Hey guys,

    your plans and post look great, I hope you can integrate them soon.
    Please think about fulfilling the grading criteria for the final version: 2 refactored code pieces.
    Do you want to add some more metric tools, maybe for different usecases like encrypting, vulnerabilities,…?

    Keep it up, just a few weeks to go.

    Cheers,

    -RawBean-
    (Foody, B4)

Leave a comment

Leave a Reply to RawBean Cancel reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.