To allow customers to introduce, deploy, and update applications quickly and easily, SAP introduced SAP Cloud Platform, as well as SAPUI5 and SAP Fiori.
Because these technologies include many industry standards, SAP customers can use these technologies in their Agile and DevOps toolchains. With the speed of deployment established, the next component of Agile and DevOps is to make the applications, which are often business-critical, robust, and reliable. Enter application quality processes and technologies.
Application quality management (also known as software quality management) supports developer productivity in the creation of error-free code and applications. While it’s likely not possible to guarantee the application will be faultless a priori, the number and severity of the errors can be reduced incrementally by combining different quality management technologies like automated (and manual) testing and automated syntax checking.
Too many times, even if automated testing is added, it is after the code is written. As long as the developer adds test code before the release of the application, the effect is still positive and can ensure the code behaves correctly. In this case, errors may result in a rewrite of some of the code which can be costly (to find and correct the defects). A better approach is to proactively discover errors and streamline the development process.
There are three common methods for proactively improving the quality of the code (and we explore the first two in our book Testing SAPUI5 Applications available from SAP PRESS)
Test-Driven Development (TDD)
In TDD, tests are written before any application code is written. Of course, the tests will fail (or be “red”) at first since the application code has not yet been written, leading to the “Red-Green-Refactor” paradigm. After the first, or “red” phase, the application code is added and the tests run until the test is passed, which known as the “green” phase. Following that, code can be changed as long as the test continues to pass. While there is some debate about the precise effectiveness of TDD, the improvements in code quality, measured in terms of defects ranges from 8% to 15%.
Static Code Checks (Linting)
In performing a static code check, code is run through a program that examines the structure of the code itself. Many integrated development environments (IDEs) have a plug-in that allows the evaluation to be performed in the IDE itself. Lint-like tools have also evolved to detect an even wider variety of suspicious constructs. According to Wikipedia, lint program (or plug-in) results include:
“warnings about syntax errors, uses of undeclared variables, calls to deprecated functions, spacing and formatting conventions, misuse of scope, implicit fall through in switch statements,...[and] dangerous language features. Lint-like tools are especially useful for interpreted languages like JavaScript and Python.”
The Web IDE used to develop SAPUI5 applications includes a lint plug-in (that runs automatically, highlighting issues in real-time).
Writing “Clean Code”
While TDD and linting both provide a lot of value by finding errors before deployment, and thus reduce the cost of remediation, code has already been written, and some effort has already been expended. Robert C. Martin, in his book Clean Code: A Handbook of Agile Software Craftsmanship, suggests that it’s better to spend time up front writing code that is easily readable and changeable, than it is to breeze through development only to have to go through troubleshooting down the road. He calls this “clean code.”
There is no succinct, pre-meditated definition of clean code, but like great art, you will know it when you see it—this post serves to introduce the concept and help you develop your sense as to what clean code is. To start, let’s say that clean code is elegant, focused, readable, and testable.
While writing code is arguably more exciting than reading code, most developers spend their time reading other people’s code and trying to understand the intent of that code. Here are some things to consider:
- Conventions: A collection of techniques for naming and structuring code that generally lead to better practices. The better practices, in turn, improve developer productivity.
- Error Handling: In many cases, dealing with errors is the root cause of code complexity. Using techniques for robust-yet-clean error handing supports our primary goal of increasing developer productivity.
- Testing: The proliferation of continuous development practices has, in turn, driven interest in automated testing (a practice that I endorse greatly, as you might imagine). Unit tests, which are code, are an alternative means to discover the intent of the code, so keeping the test code clean supports easy modification.
- Refactoring: The ultimate goal of a developer should be to create code that can be seamlessly changed in the future as user stories evolve, or more effective approaches are discovered. Clean code supports refactoring because the intent is clear.
Conclusion
To summarize, bad or messy code changes can introduce unexpected errors in other areas. As the errors multiply, productivity will decrease, ultimately stalling the ability to rapidly fix, change, or extend a business-critical application deployed on SAP Cloud Platform. Clean code is easier to understand, change, and extend those applications, and better supports SAP’s customer’s business objectives.
Read more about clean SAPUI5 from my other posts:
Comments