August 5, 2020

How We Do IT: Achieving High-Quality Code


The way code is written can either make or break the success of launching a new software solution. At the same time, the coding practices which define what good coding is are subjective — they differ from one developer to another, so companies often set their own standards on how to meet them. That is why, as a part of our How We Do It series, this article would like to introduce you to the efforts Scalefocus takes to make our code quality stand out from the rest, with the promise to deliver only the best to our clients.

The three main pillars which push our code quality to keep improving are:

  • Consistency: Writing good code starts with taking sole responsibility for formatting code correctly and the same way each time. On the other hand, collective consistency means to follow proper code style when collaborating, and applying the same formatting for new features as with previous. Together, individual and collective consistency allow for easier error spotting and faster releases.
  • Testability: Unit testing involves taking apart individual components of a software and testing that they perform in accordance to its initial design. By validating the smallest units during the development stage, we ensure that the final product is up to par. We usually require a minimum of 80% unit test coverage for a module to be accepted.
  • The Human Aspect: Peer code review is critical. We believe in the power of collective thinking, thus our coding standards are not only stored in Git, but are open for anyone on the team to challenge by simply opening a pull request with a proposed change and providing solid argumentation behind it.

Let’s delve in deeper to explore the automated quality checks we use, our approach to unit testing, the role of DevOps and the technologies Scalefocus relies on.

Code Checking on Autopilot

In order to catch the maximum number of code discrepancies in real-time, we analyze the code automatically. We automate styling-related part of review by combining technology specific solutions such as Swiftlint, ESLint and Checkstyle in aggregated SonarQube reporting.

We use Swiftlint to analyze Swift source code for programming and stylistic errors as well as bugs. Similar to the function of a lint roller removing fuzz off our clothes, when it runs, Swiftlint also identifies and removes any strange constructs that may lead to errors. ESLint is the linter we use to review our JavaScript code. Meanwhile, Checkstyle is able to review and locate any problems in code layout and formatting of Java code.

SonarQube implements Continuous Code Inspection by detecting tricky issues reported as bugs, code smells and security vulnerabilities. SonarQube reports make recommendations on design, code formatting and whether it responds to the standards set by Scalefocus, as well as provides custom metrics that give a numerical value to a property of the software. We set specific thresholds, Unit Test coverage and Unit & Automation Test pass/fail criteria which defines the automatic gatekeepers for allowing a code merge. The integration pipelines are built in a way, that if any of the reports indicate a failure to meet the set deviation, or minimum number of peer reviews are not met, the code cannot be merged.

Test Coverage and Usability Go Hand in Hand

Test coverage is a percentage that illustrates how much of a software’s code is covered by automated testing, with the aim being to reach a figure which covers all major components. It is calculated by dividing the total lines of code being tested (X), by the total number of lines of code in the software (Y), multiplied by one hundred. Test Coverage = X/Y * 100. For example, if a mobile app was written in 30,000 lines of code and 24,000 of them were tested, an 80% code coverage would be reached.

It should be noted however, that test coverage does not directly assess quality. Just picture testing out a kitchen knife. Sure, the blade might be sharp enough to cut straight through any raw meat, but how about the curve of the handle and overall feel? That is where usability and true craftsmanship come in, when shaping the product to fit the customer’s needs.

We write user stories in Gherkin syntax, in order to fully benefit from behaviour-driven development (BDD). This step is highly beneficial, as it allows for non-technical participants to share their understanding on how a software should behave and rate its usability. Further, this allows us for single reporting within Jira dashboards, regardless if the test cases are run automatically by Jenkins or manually by quality assurance specialists.

Although we set a minimum of 80% code coverage before modules are accepted, it’s important for us to continuously build automation and integration tests on top of that, to reap the full benefits of predictable and maintainable code.

Encouraging Collaboration in Real-time

DevOps can be viewed as the combined efforts of developers and IT experts to deliver quality with speed. We achieve that by enabling real-time changes to be made in both the software and its infrastructure through collaborative tools and test automation.

Our DevOps team plays a crucial role in the development process by building and maintaining Continuous Integration pipelines, and ensuring everyone has visibility on their current state. It also ensures that gatekeepers are in place and checks are being made before integrating any piece of code with the master version. This role is also crucial in balancing running quick automated checks like unit tests, with more time-consuming ones such as Integration Tests, before engaging in a peer review and wasting a developer’s valuable time.

We believe that future of high-quality code relies on the automation of repetitive tasks and providing as much data as possible to peer reviewers. With that in mind, we use Jira story points as a metric to estimate difficulty level, which could either be issues, risks, time or effort involved to implement a task. In cases when a Jira user story is estimated as a 4 out of 5, it is then addressed with a quick and brief pull request, and it serves as an early signal for the reviewer to be extra analytical when performing the code review.

Get to Know Us Better

We hope this post gave you a closer glimpse on our approach to ensuring high coding quality when engineering new software solutions and services. Want to get to know us better? Follow us on social media, and you’ll be able to stay in the know on exciting new partnerships, take part in virtual events, get a sneak peek on our current projects, and get introduced to the great minds that work with us.

Keep your eyes peeled for our upcoming How We Do It topic, which will shine the light on talent management at Scalefocus. We’ll discuss our onboarding experience, HR team structure, upskilling and knowledge transfer among our departments.