Smart Strategies to Deliver Quality Code: Part 1 Maintainability
The quality of your code can make or break a product. The question is … who is responsible for testing? Conventional thought creates distinct, separate roles for a developer and a tester. Developers … well, they write code. And testers are responsible for quality assurance. Right?
Sure. Developers write the code that testers verify works correctly. But is anything ever simply black-and-white? In this regard, responsibility for testing has been relegated to the grey zone.
Now, we’ll tell you how to break out of that grey zone by suggesting code maintainability techniques developers can use to enhance quality.
I can read my code, why can’t you?
Have you ever said this to another developer? What about to a tester who comments on your coding ability?
Simple code is always better because it is easier for someone else to understand right away. Even if you don’t work in a team, build your code with the perspective that you’re not the only one who will touch the code. Other people may need to read, understand and support it down the road.
Readable code saves a lot of time and effort to provide support, fix bugs, handle change requests, and implement new enhancements. Bad code is expensive! A task that needs only one line of change (which can be done quickly) could end up taking hours or even days to read through and figure out.
Software with poorly written code is difficult to maintain and extend, shortening the lifespan of the product. Do you really want your hard work to be scrapped so new code can be built? No? We didn’t think so.
Suggestions:
- Use descriptive naming
- Keep style and structure consistent
- Separation of Concerns principle keeps code cohesive with a single responsibility
- Be clear, direct and to-the-point with transparent intention
Keep It Simple, Sam
Have you heard the phrase “Keep It Simple, Sam?” This design principle urges products be made as simple as possible so that even someone with limited knowledge can operate or repair the product. If your code is not maintained properly, how will that affect the application as a whole?
Create code that is self-explanatory so that someone without your knowledge of the code can read it easily. If you think extra documentation is necessary to explain what the code is doing, then the code is too complex.
Avoid using inline comments and separate documentation as they are expensive to update in the business where requirements are constantly changing. For example, if you made comments in the code to explain something but the code is then changed, you must also make sure to change the comment to reflect the new code. This can be time-consuming and, if the comments are not updated, confusing.
Quality > quantity! Keep code and relevant documentation simple to save a lot of time and effort on support and integration of various sub-systems.
Suggestions:
- Use straightforward logic to minimize need for extra in-code documentation
- Keep sections modular to reduce complexity and maximize reusability
- Ensure all team members understand the best practices and standards that apply to your code base
Consider Future Growth
To succeed in a competitive marketplace, software products must continually add new features without introducing bugs. Quality code takes future growth and extensibility into consideration.
As a developer, you know that your code will need to be refactored and enhanced over time. But did you know that the best way to protect your code quality and enable you to refactor confidently is to ensure that your core functionality is continuously tested at the unit and integration level?
Let’s put it this way. If you fail to continuously test working functionality, hidden bugs can crawl into your code while it is being refactored. This can cause serious problems down the road and can lead to costly changes in core product quality. We shudder at that thought.
Use automated unit and integration tests to catch bugs before they can eat away at the structure. These tests provide the first line of quality assurance for delivered outputs. More importantly, they can be executed automatically in build cycles to quickly make sure bugs haven’t taken residence. Turn on that No Vacancy sign!
Suggestions:
- Ensure your automated tests cover all documented acceptance criteria, as well as common sense scenarios, that may not be fully documented.
- Run a full suite of unit and integration tests on your local build before you commit your code to the common repository.
- You must use Continuous Integration Pipeline tools (like Jenkins and GitLab) to run your unit and integration tests for each build.
Take Pride in Your Work!
Do you like showing off your code to other developers? Do you have confidence that your code will stand up to rigorous testing?
We challenge you to have pride in your work by spending a little more time finding bugs before sending it to a tester. In turn, you can challenge the tester to find problems with your code. After all, quality is not only a tester’s job. Developers are responsible for the quality of the code they deliver.
The World Quality Report 2018-19 backs up our claim that quality is not only a tester’s responsibility but also other departments:
“Today, the way QA and testing activities are executed has changed. On the one hand, the adoption of new frameworks and technologies has broadened the number of skills required for testing, while on the other, testing activities too have spilled over to other domains and functions such as Development and Business Analysis. Thus, today, everyone has a role to play when it comes to QA and testing.”
Experience has taught us that using these practices help developers build better code. It also improves relationships between developers and testers. Ultimately, if the developer thinks of the potential issues to begin with, the whole process can run smoother and the product can be released to market much faster.
Are you still not convinced you would be able to fit quality checks into your schedule? We have a solution for that too! Stay tuned for the next part of the series when we discuss the topic of team collaboration to improve quality. In particular, we will draw references from SmartBear’s 2018 State of Code Review and an interview with Marketing Manager Patrick Londa. Collaboration has never been easier with today’s technology advances!
Looking for a software development or testing partner?
Reference:
World Quality Report – https://www.capgemini.com/service/world-quality-report-2018-19/
