How to improve SAP UI5 ​​app code quality and maintainability

In this blog, I briefly describe some of the things I do to address this issue and how to do the same. These are practically common practices throughout software development, including some UI5-specific examples.



Using Git

Git is the industry standard for version control. You're trying to improve your UI5 application, and this often means removing code, moving code around, or rewriting code. If you don't understand the importance of version control, you should learn Git and read how it works. Change. The only way I'm used to removing files, functions, and rewriting code from a legacy project is knowing that there is some form of copy of the code at every step. If there's one takeaway from this blog, it's that every project should use Git.

Delete unused functions / dead code

This is really easy! Check the title of the individual function and look for its references throughout the application. Note that it should only search the entire project structure, as it can be called from other controllers or directly from views. Found something invisible being used somewhere? erase. All projects need to use Git, and there will always be a copy of this functionality, so removing it doesn't mean it's gone forever. You could write the name of the deleted function in the commit message for easy retrieval later, but often people are afraid to delete it, so legacy projects have a lot of dead Code exists.

Use clear and descriptive names for functions and variables

Functions and variables should be named appropriately. Always use a function named "returnUserNameFromSettingsModel" instead of saying "returnUN". This is because "UN" may make sense in context, but the former is more specific and less ambiguous. I realize this example is a bit contrived, but it's a common pattern that hurts applications.

Please provide complete and unambiguous function and variable names. You might know someone's name today, even if you can't remember it a week from now.

Don't Repeat Yourself

Don't Repeat Yourself (also known as DRY) is a common software engineering principle that is easy to implement. look at your function. Is there a common, repetitive sequence of steps? Suppose you have a step that updates table data.

Can this step be performed when removing items from this table, adding items, or updating items? Can the table be updated with the click of a button? Whatever the case you will probably have repeated that same 'refresh table' code multiple times throughout your application so you need to extract this method into a single function and call that rather than repeat the same code over and over again.

Not only will this improve your code quality, maintainability and readability it will also reduce the number of lines of code and make our life easier.

Make use of your base controller

Larger applications (multiple views and controllers) should make use of a base controller, this is commonly found inside of the larger SAP template applications and so shouldn't be that hard to introduce if you're missing one. (let me know if you'd like a blog on this subject)

The base controller can then be used to store common functions which are used across your application.

This is essentially an extension of DRY but making use of our tools at our disposal such as the basecontroller as this is common among our applications. This tip/tip can easily get out of hand and leave you with 2K rows in your base controller, so use it only when appropriate.

Refactoring

Refactoring is the process of taking existing code and improving it by rewriting the existing code to produce the same functionality. In software development, this is often written as "change the internal structure without changing the external behavior". This is what I do all the time in my code and projects, and you should too.

Don't just sit down and do one refactor. Refactoring is a discipline, a continuous process of looking at something and thinking, "Can I do this better?" It's something we all strive for. There are many blogs, books and videos about refactoring, so I won't repeat everything that has been said elsewhere.

Refactoring is one of the most important processes a software developer can incorporate into their workflow, regardless of the programming language or framework they use.

Creating a utility file

You may create a utility file. A utility file extracts a common process and puts all its functionality into a single file. There are examples like instantiating a fragment and putting it in a "fragmentManager" file. Then you can use this file as a place to instantiate your fragment. To access the functionality, simply import the fragment manager into your controller.

This goes a long way in reducing your controller or base controller code to almost "boilerplate" and putting it in a nice little box that you can call upon as needed. This has the same benefits as moving items to the base controller, but is more specific and helps reduce base controller bloat when things get unwieldy.

Direct model binding

Although I recognize and use JSON forms a lot, and their use is unavoidable at times, you should use direct form binding whenever possible.

The direct form binding is where the function/service collection is called in your XML, without any JavaScript. This is typically achieved by controls such as search wizards, as they typically only return lists of data without dynamic filters.

This can free up drivers a lot if you have a lot of calls that can easily exist in XML and automatically update your gateway service.

 

 


Previous
Next Post »