Skip to content


We are Obsessed With Quality

As mentioned in our previous article, Are You Buying Quality Software, we aim to deliver features at fast pace while maintaining the highest possible code quality. Our last article about our code quality has been written more than one year ago, how are we doing today? The following sections get you an insight about the code quality of our backend server written in Java.

So you’re saying you have no bugs?

We're not saying our software doesn't have bugs. Every single piece of software has glitches or bugs. But, it's quite usual for us to fix a bug and release a patch the same day. We thoroughly test our software entirely to make sure most of the bugs get caught before going into production.

Ask one of our competitors reports about their code quality. We are pretty sure no one will ever give you that information. We think you must know what you pay for.

Sonarqube Analysis

Quality Profile

Our code quality analysis is based on Sonarqube, using a custom quality profile with more than 750 rules enabled.

Sonarqube Quality Profile

Our profile used last year had a little over 700 rules enabled. We try to slowly increase the number of rules checking the code to further improve code quality. Feel free to use our own quality profile inside your company to check their code against our coding rules. I'm pretty sure you will be surprised by the results.

Upgrade to AngularJs 1.6

When we started developing our load testing solution we had to choose a technology to create the UI. Most of us had previous experiences with GWT or Vaadin but we were not satisfied with it. It took us too much effort to create a sketch of the application and it didn't even look good.

So, we gave a try to AngularJS, even though none of us knew a bit of JavaScript. It felt really productive and a few weeks later we had a nice first version of OctoPerf that could start performance tests and display reports.

Three years later we added lots of features to our load testing solution and the code base reaches almost 10K lines of JS. In the meantime, Angular2 came out and AngularJS evolved to close the gap.

So, during the past months we took some time to upgrade our frontend to AngularJS 1.6 and to prepare the ground for Angular2:

Impl classes are evil

Like Martin Fowler said in TwoHardThings:

There are only two hard things in Computer Science: cache invalidation and naming things.

I've just seen too many times developers using Dependency Injection frameworks like Spring or Guice or Dagger the wrong way. Naming classes with Impl suffix is an Anti-pattern and i'm going to explain why.

Why Impl is Bad

ServiceImpl is a common practice

Many developers, including myself years ago, are using the Interface + Impl pattern to create services which are injected by their interface. This usually looks like this:

Impl pattern

The builder pattern

The builder software design pattern is an object creation one. It's a great building block for classes with optional fields. It provides a maintainable and readable way to instantiate immutable classes with more than 3 or 4 fields. It greatly reduces the time developers needs to understand how to instantiate the class properly.

You have surely faced one day or another a code similar to the one below.

public class Person {
  private final String firstname;
  private final String lastname;
  private final String address;
  private final String zipCode;

  public Person(final String firstname, final String lastname) {
    this(firstname, lastname, "");

  public Person(final String firstname, final String lastname, final String address) {
    this(firstname, lastname, address, "");

  public Person(final String firstname, final String lastname, final String address, final String zipCode) {
    this.firstname = Preconditions.nonNull(firstname);
    this.lastname = Preconditions.nonNull(lastname);
    this.address = Preconditions.nonNull(address);
    this.zipCode = Preconditions.nonNull(zipCode);