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 it, 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 the software development process?
As much as every project is individual, the process of software 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 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:
aka automated tests. Developers write scripts checking whether a specific functionality is working as expected, for example, integration tests, unit tests.
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 a 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 in order to ensure they are constantly using 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.
standard based on a community-driven style guide to keep the code consistent
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 the 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 a 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 the strategies and standards the team uses.
Continuous integration, code reviews, testing and documenting the work are the foundations of a solid software development process. Take time to talk about them with your development partner. You won’t be able to get over how much they can affect the quality of your product.