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.
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.
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.
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.
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:
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.