When you’re building a web or mobile application, there are tens of things you need to think of: what problem it solves, who will use it, how to market and monetise and many more. In addition to these strategic business challenges, there are those connected with coding. Even if you’re not a developer, you want to release a product that is maintainable and coded in a rational and predictable way.
How to check if you’re keeping the quality of software development process?
As much as every project is individual, the process of development doesn’t have to be. A solid team has a well worked-through approach to code quality and a set of monitoring tools in place.
The most important ones are:
Continuous Integration (CI)
A practice allowing the team to regularly integrate the code to a common repository. Each integration is verified, which results in keeping the updated version in one place. Thanks to CI, all completed tasks are merged into the application. A consistent integration process has a direct impact on a dextrous application development and on decreasing the project cost.
The biggest advantage of continuous integration is the immediate feedback the development team receives about the functionality, quality and overall impact of their code.
An experienced software house will have the practice in place and will ask their partners for the same.
We set up continuous integration with SemaphoreCI early in our days, and it turned out to be one of the best quality-driven decisions about our process.
There are many ways to test the code and it’s not my intention to dig deep into this topic. Some people write their PhD theses about testing, so for now let’s stick to a very simplified division of tests:
- Tests written by developers, aka automated tests. Developers write scripts checking whether a specific functionality is working as expected, for example, integration tests, unit tests.
- Tests performed by manual testers. Manual tests help the team see whether the code actually does what it’s supposed to do. Manual testers click through the application and check it against the business requirements and make sure it is compatible with the browser or device.
Thanks to testing, we know that the code works as it should when it comes to business logic (and syntax, too), and that the user can do exactly what we wanted and how we wanted. Depending on the test coverage (and type), testing can take different amount of the entire development time. For example, manual tests take usually 10%-15% of development time. When it comes to automated tests, it can be much longer and expensive.
Before it is accepted, each line of code goes through a mandatory review and acceptance by another pair of eyes. This way, the team members watch one another to ensure they are constantly using the good practices. Code review is also a great learning tool that leverages the skills of the entire development team.
The code should not only be guarded by tests and code reviews but also documented in a transparent way.
- Code standard – at Briisk we have our own standard based on community-driven style guide to keep the code consistent,
- Name convention – all names of variants, methods, modules and any other components are descriptive and clear.
- Project documentation – the documentation of the project should be kept in one central place and regularly updated.
- API documentation – so it’s clear how to use the service. It helps new developers to understand the application or external teams to connect to your application. We use Postman to document our APIs.
- Tests – like them or not, but they are also one of the ways to document the code.
A good practice is to separate the code the team is working on from the one that’s already been accepted. This way, there’s a coding playground, testing playground and production environment.
The first one (usually called workspace or development) is the place where new features are added. One can call it a working environment with unit tests and code reviews. Thanks to continuous integration, accepted pieces of code are automatically merged to workspace.
The next one (staging) is the environment for the manual tester. The release from workspace to staging happens when a set of features is developed and ready for manual and compatibility tests. While testers do their job, the developers can continue working on new features and preparing for a new release.
In the last step, tested and approved work from staging can be safely pushed to production server where your users enjoy new updates and can share feedback.
Developing an application is much more than just coding. If you want to give your users a high-quality product, you need to make sure that people who write the code also follow good practices. A good way to do it is to ask questions about strategies and standards the team uses. Continuous integration, code reviews, testing and documenting the work are the foundations of a solid development process. Take time to talk about them with your development partner, and you’ll be surprised how much they can affect the quality of your product.