In this final installment of my clean SAPUI5 series, we’ll explore refactoring as an element of clean SAPUI5 code.
So far, we’ve explored what clean code is, conventions used in clean code, and testing as a component of clean code. In short, clean code supports our goal of quickly creating robust, quality code.
Of course, every developer works hard to create, test, and release code that has the least technical debt possible, but the drive to innovate as rapidly as possible can mean making hard choices to get working code “out the door.” It turns out that refactoring is an excellent way to reduce technical debt, and a straightforward way to do that is to review the application after each release with respect to the clean code leading practices described in Robert Martin’s clean code book.
Let’s highlight some of the more effective leading practices for refactoring SAPUI5 code.
How to Refactor Code
In his book, Robert suggests the practices below can be used like a checklist. Applying these one by one can incrementally improve the readability of the code. Note that, because we’ve added automated testing (see "Clean Code for SAP: Ensuring Quality for SAPUI5 Apps") we can simply run the testing suite to ensure that our refactoring has not caused any errors; refactoring without an automated test suite, however, is very much like working without a net.
Remove Obsolete Comments
Comments that are no longer relevant can confuse a reader at a minimum and make the code less readable. Remember, one goal of clean code is to create code that can be read by humans.
Remove Obsolete Code
Eliminating code that is commented out is a particularly easy way to make code more readable. Functions that are never called (which is very conveniently highlighted by my IDE of choice, Visual Studio Code) should also be culled. Remember, if the code is ever needed again, the source control system can be leveraged.
Too Many Arguments
While it’s not possible to know how many arguments a function should have a priori, generally, fewer arguments are better. Why is that? Specifically, the number of automated tests will grow in proportion to the number of arguments. To achieve having fewer arguments, try moving arguments into object instance variables.
Repetition
Repeated code, especially in the same source code file, introduces risk, and violates the DRY (Don’t Repeat Yourself) principal. Convert the code into a function; in that case any changes that need to be made to what would have been repeated code are made in one place. Moving the code to a single place can eliminate a hard-to-trace source of errors.
Replace Numbers with Named Constants
Not only will replacing potentially obscure numbers with an easy-to-read name make the code, well, more readable, any changes to the number can be made in one place.
Use Descriptive Names
Clean code conventions are the subject of the second post in this series. In fact, this practice is so common, that many IDEs feature capabilities that will assist with renaming variables and functions.
Use A Coverage Tool
Given the need for testing, a legitimate question will be: how much testing is enough testing? Earlier in this series of posts, we mention the use of a coverage tool to show how much of the source code is tested.
Conclusion
Refactoring presents an opportunity to improve the readability and quality of the code. If the original source isn’t clean code, refactoring can be the chance to get it right the second time. When coupled with automated testing, clean source code enables rapid troubleshooting, deployment, and controlled change (i.e. refactoring).
As I close this series, recall my intent was to be an introduction to clean code for JavaScript and SAPUI5, in particular. I drew on my great sources of information. I recommend Robert Martin’s book, of course, but there are others, including books written for specific programming languages (like SAP PRESS’ Clean ABAP: A Style Guide for Developers). The Coding Sans site also has a great post on the practical implications of clean code.
Ultimately, it is my hope that this series will serve as an entryway into all of the topics that contribute to creating quality code. Thanks for reading.
Comments