Since I started doing software for a living, I have been part of different teams. As you can imagine, different teams mean different ways of working. But they all had one thing in common: and that is the fact that at some point throughout the development of a product, it was time to ship for production.

So, how to ensure the quality of that final product?

Most people think that after a long time of development, then you should spend time reviewing and fixing errors. I don't disagree with having a test plan that helps you find some use cases not being covered, or maybe some last-hour unexpected behaviors.

But to ensure the highest quality throughout the process, it is necessary to have a good code review system involving automatic tools and effort on the part of every team member.

Let's see how!

Unit Testing

Having unit tests for every feature is one of the most beneficial approaches a software development team can take. Doing this ensures that the new features are properly working before merging into the main branches of your product.

Not only that! It also ensures that all the previous features are still working properly. Which is exactly what your product needs. In the ideal case, the new feature needs to add value to the product without compromising all the work that was done previously.

This is easier to ensure when unit testing is implemented.

A good and natural way to start with unit testing is to take the test-driven development approach:

1. Write tests for the new feature. They should fail until the feature is properly implemented.

2. Implement the new feature. The tests should pass once the feature is implemented correctly.

3. Refactor your code. This way you take care of putting all the pieces in the right place without making the tests fail again.

This approach takes extra effort in the beginning because it is hard to start a new feature by writing the tests for it. But the great benefit of it is that it makes the developer think about all the aspects of the feature before diving right into coding. This might seem obvious, but not everyone does it.

Once the feature is implemented and all the tests pass, the developer can request a deeper review from the team members. But now your team can rest assured that your changes are more likely to work as expected and that all the previous work done has not been affected.

Additional checks

What I call "additional checks" here are mainly necessary checks that need to be run in the codebase and are not related to the functionality itself. These kinds of checks usually help to standardize the way the team does certain things during the development process.

Let's see two examples that I use in my everyday work.

Code styling

Code styling is, in my opinion, one of the more underestimated aspects of software development. The fact that several developers are going to be working on the same project, making changes to the same codebase, each of them with their coding style, can make a project look like a mess after a sufficiently large amount of changes.

Over time, it will become harder for new developers to understand the code that was written by others before them. And this will certainly act as a drawback when adding new features or debugging.

What to do, then?

Usually, there is a standard way of coding for every language. The developers of the languages work hard in creating these standards because they understand the flaws of a poor coding style. And some tools called linters can be run in a project to detect when the code doesn't comply with certain rules defined by the standards.

Make these linters run as part of the automated processes of code checking. It will return the list of faults that are present in the project and the developer can go and fix them. Usually doesn't take much time to fix these suggestions manually, but my recommendation is to use a code formatter that makes that work for you.

Once the code complies with all the coding style guidelines, your team can proceed to make manual reviews on a very much more familiar code this time.

Spell checks

Spell checking is as important for a team as a very thorough code review. The fact that many teams nowadays have members from multiple countries has made it a standard of having a primary language of communication inside every team.

This goes from the language they speak to communicate ideas and have discussions, to the names they set for variables in the code. Also, writing documentation is part of the daily work of software developers, and this documentation is usually written in the same agreed language.

Having an automated process for spell-checking can reduce the number of typos that the team has on their daily tasks. This will lead to a higher understanding of the overall code and documentation written and will make easier the process of explaining details to the developers from other teams or even people that has nothing to do with the software development industry.

Reviewers

Once all the automated tests and checks pass it is time for manual reviews. This means that the feature will be read by other team members apart from the one making the feature. If they consider something needs to be changed, then changes are requested. Otherwise, they approve the feature.

For the feature to be merged, all the reviewers need to approve it. As long as one of them requests changes, the feature should not be merged.

Of course, this can lead to a discussion between the team members, analyzing if the requested changes are needed or if the current implementation is good enough. Don't be afraid of these discussions, they will only make your team closer and everyone will learn a lot in the process.

In my experience, having two reviewers approve a feature is usually good enough. But in any case, the reviewers should be active. This means that they not only should read the code but run it, test it, ask questions, and understand everything that has been put for review.

If these criteria are met, then your team is good to go and your product will almost certainly have a new feature that adds value while keeping everything else working properly.

Conclusions

We have seen some methods to ensure the quality of a product throughout the entire process of development. From unit testing to manual reviews, checking for code style and spelling mistakes.

Taking care of these details for every new feature has proven to be effective in all the teams I have been a part of, and it continues to be. Ensuring good testing and reviewing practices more often than not will make your products more reliable and easier to maintain.

In the beginning, some of these practices might seem like a waste of time, since they can delay the process of shipping new features for production. Nevertheless, using them will make the team more comfortable every time and the development times will start to decrease again. Only that this time you will be a much better team: one that delivers fast and safely.

---

👋 Hello, I'm Alberto, Software Developer at doWhile, Competitive Programmer, Teacher, and Fitness Enthusiast.

🧡 If you liked this article, consider sharing it.

🔗 All links | Twitter | LinkedIn