Maintainable code

Context

Synetec’s approach starts and ends with exceptional customer service and accelerating delivery of high-quality solutions. We are hands-on, proactive, and collaborative. We aim for happy clients who will engage us repeatedly to deliver new and upgraded solutions for their customers, many do. However, part of our quality is that we build our code and deliver it in a state where any similarly skilled developer to those on our team can understand the code and the design decisions we have made and continue to develop the product.

Coding principals

In developing applications, we always aim for them to be:

• Secure
• Usable
• Testable
• Economic
• Easily maintainable

Secure

Security for web-based applications requires multiple layers of defences. From the networking controls like firewalls, the application code through to the hardware it runs on.

At the application code level, we base our defences on the OWASP (Open Web Application Security Project) Top 10 Web Application Security Risks - these are recognised worldwide and referenced in guidance from the National Cyber Security Centre on secure development and design and the payment card industry security standards (PCI DSS) amongst others.

The problem with security is that we must get it right every single time, an attacker must only find the one time in a thousand that we don’t to create an exploit on the application.

For this reason, we advocate a defensive coding style which always assumes malicious intent for any data from an untrusted source – anything supplied by a user, API, database, browser, etc – and using built-in defences in programming languages, wherever possible, to prevent harm.

Usable

We aim for our applications to be usable in four ways:

• User experience
  What the user needs to do to accomplish their top tasks should be self-evident and, wherever possible, delightful.
• Accessible
  Web-based applications should meet the WCAG2.1 accessibility standard at the AA level of conformance.
• Available
  The application is ready to perform its functions when needed on the intended devices.
• Performance
  We aim to target performance to match the business requirements and user expectations, including ensuring we can scale the application appropriately based on the volume of transactions.

Testable

Unfortunately, bugs will be introduced in code, however, there are some techniques we use to minimise this and to ensure they aren’t repeated. Key to this is writing tests which can be executed automatically when the application is built and completed within a few seconds. The optimum approach is to use test-driven-development (TDD) in which the developer writes the tests first and then writes the code to pass the test.

If a bug does get into the system, a new test is written which covers the bug and it is then fixed. This ensures that it is fixed first time and avoids later re-introduction. The final benefit of tests is that they can prevent unintended consequences: changing code to solve one use-case and missing others which introduces bugs into the system.

Economic

The cost to build, operate and change and application is minimised without compromising its business value or any of its other qualities. We support the use of established third-party libraries and integration of tools over always creating bespoke components.

Components/modules of the product should be loosely coupled, wherever possible, to enable the swapping of one component for an updated component without substantial rework. It should also be efficient in the way it uses resources: time, effort, CPU, memory, computation power, network bandwidth, files, databases, etc.

Easily maintainable

Deployment

It should be possible to setup and deploy to a new hosting/development environment or deploy an update to an existing environment without it taking excessively long or require complex manual steps.

Adaptable

Another appropriately skilled developer can understand the code and how to modify it safely within a short space of time. This can be achieved by:

• Documenting and following coding standards – a consistent style of coding is more easily understood than one which frequently changes.
• The use of up-to-date technologies and patterns – to reduce technical debt and increase the availability of developers
• Documentation of the code and features it supports
  • Architectural design records to document key design decisions or processes
  • Self-documenting code – by following our coding standards
  • Public classes and methods using code comments to document the purpose, parameters, and any return object.

Flexible

It should be easy and safe for multiple developers to work on the code simultaneously without causing conflict. Designing our code with clear separation of concerns and a loosely coupled architecture are key elements in achieving this.