Maintaining Code Quality at DADI

DADI's web services have been in development for over four years. It all started with DADI API, the RESTful backbone of the API-first, Create Once Publish Everywhere approach that was the founding thought behind the platform.

We realized very early on in the development process that DADI API would be playing a big part in many of our internal and external projects. To that end we had to ensure that any software we used in-house or published to NPM was well-tested and easy to maintain.

This post describes some of the ways we achieve this across our (now significantly larger!) development team.

Coding style

During the first iteration of API development, when the team was super small, we had no real need to implement a coding style for the project. With only two developers, one generally followed the style of the other and the style in the codebase was kept largely the same. As more developers began to contribute to the functionality of API, it was obvious we needed to make some decisions about style.

We ultimately chose to use JavaScript Standard Style throughout the platform, ensuring all developers adhere to a set of rules that includes both those for visual style (such as indentation), and code structure (such as always handling the err argument in a Node.js callback).

With no editor configuration files required, it's incredibly easy to implement across a distributed team.

In the beginning I think we all had issues with a style being imposed on us, as every engineer has their own personal style which they've developed over many years of coding. Not having to type a semicolon at the end of a statement was the hardest part for most of us!

Using a StandardJS linter in our editing software - and adding a precommit step to double-check code that was being committed to the repository - has helped us develop faster and with fewer bugs. Being able to open any file for editing in the platform and read the code without having to adjust to a previous developer's style is an enormous timesaver.

Unit and acceptance testing

Automated testing of the code written for the platform has been integral to our development process. The first developers on DADI API added a test suite and a testing process right at the beginning of its development. That test suite has now grown to over 560 individual unit and acceptance tests and the process has been replicated across each of DADI's web services.