In this post I’d like to outline some topics, strategies and practices that, in my opinion, help with improving code quality and developing more stable code in the future. Some of these topics are very subjective and I outline my personal opinion here.
Test Driven Design (TDD)
TDD has the aim to first focus on writing tests that covers the requirement before implementing the requirement itself. This has the big advantage that tests are written against the requirement and not the implementation, reducing the risk of missing certain cases in the requirement because the implementation didn’t cover them in the first place.
TDD can be viewed from two points: Either from a unit-testing- or from a functional testing-perspective. The idea remains the same, and it makes sense to try and use this approach in both kinds of testing. While the developer can usually work alone while using TDD in unit tests, a good communication between development and testing is required if TDD is implemented for functional testing as well.
Another challenge for TDD in functional testing is the timeline and planning. Testing ressources for a new feature need to be allocated before any development has started, meaning that the traditional parallel work of testing the latest feature while already developing a new one at the same time has to be changed so that development and testing ressources can be allocated at the same time.
Unit Testing
Unit Testing goes hand in hand with the TDD-approach and is another technique that a developer can utilize to improve code quality. It is quite common to have a testing team that executes functional and regression testing, but one level below the functional testing is unit testing, the smallest possible testable unit. This is what a developer can already test during implementation, reducing the risk of bugs when the code hits a test environment.
Certain languages, like Java or Python, that come with first-grade testing-frameworks (JUnit and unittest respectively) make unittesting very easy to implement. Another advantage of unit tests is that if you ever want to rewrite portions of your application from scratch, for example in another language, and you have good unit test coverage, you can easily verify that both the new and old implementation adhere to the same specification.
Code Review
Code Review is the process of giving your implemented feature to one or more people, which had no interaction with that feature, to look over your code and spot bugs or other things that are not compliant with coding guidelines. Code Review can either be done manually or with a tool like Github, Gitlab, etc.
The big advantage of code review is that a person is looking at the code that has never seen it before. Because of this, it is highly likely that it will spot obvious errors or other problems.
Tools like Gitlab make it really easy to do code review. It gives you the opportunity to assign a request to a person, this person can then comment either on the whole request or on specific lines. As soon as you fix all the commented lines or parts of your code, the other person sees what you have done and can do the review process again, eventually approving your request. This way, you not only had an additional set of eyes that looked over your code, but you also have proof that it was reviewed in the form of the request in Gitlab.
Documentation
Documentation is a crucial part in improving code quality and keeping it at a high standard. When new developers get into an application and try to implement their first feature, it can be really hard to know which functionality should go where in the application, how the application is structured and what the architecture or design of it looks like. Also for seasoned developers it can become hard to keep an overview of what features are implemented in which places. Due to this intransparency, it can become hard to identify areas for improvement.
A good documentation and collaboration plattform like Confluence or Notion can help with that. Both plattforms offer a lot of tools that help you in keeping the documentation organized and accessible. Documentation is hard if you have to start from scratch and will require a lot of time and ressources. As soon as you have a good basis that matches the current software, documentation can be included in various processes that happen during the software lifecycle. This way, you update it as soon as the software changes and don’t have these big gaps in documentation that have to be filled one day.