Application Development Blog Posts
Learn and share on deeper, cross technology development topics such as integration and connectivity, automation, cloud extensibility, developing at scale, and security.
cancel
Showing results for 
Search instead for 
Did you mean: 
Former Member
7,928
Code optimization is something all of us programmers learn before we even get past our first year in any programming course of study. It's the meat of the matter, the bones of the animal, the long and short of our lives as code-monkeys. However, among the first things we learn in those courses is that there is no ONE way to do something. There's always more than one way to skin a cat. Despite this, optimized code is a very elusive target and as much as you could optimize code to a certain point, there's no way you could make it completely perfect. Here are a few ways you can try to make your ABAP code more responsive and cut down on the amount of stress you cause to your clients’ devices and their connected databases.

Get Rid of your Unused Code Snippets


Just like anything that's fluid, if too much gunk starts gathering in a particular area, it's going to clog up the pipes. The same can be said for custom ABAP code that just isn't used. Instead of just leaving that code to get into trouble or to cause you undue trouble, you should consider getting rid of it. I know us programmers sometimes see code as something we made and have an irrational attachment to certain snippets. But trust me on this, getting rid of that useless code can enable your system to be far more efficient.

Database Calls should be Precise


Everyone who works in ABAP has done "SELECT *" calls as part of their custom code. It's one of the most-used bits of code for coders like us, and it’s something all of us tend to have in common. We love how efficient it is at querying the database for information. But is it really that efficient? "SELECT *" tends to be shorter to write, but looking at what's going on under the hood, maybe it might be more efficient from a data perspective to manually select individual columns containing the data we want? Not only is it inefficient data handling to just broadly select columns, but as data is expanded and we get new columns tacked on to the end of the database you start drawing even more unnecessary information out of the database, bogging it down with your numerous "SELECT *" calls and making your resulting code unreadable. Before you write that "SELECT *" snippet, please, think of the future of your code and the poor guys who have to be working on it when you're not around.

Include Code Inspection into your Governance Models


Inefficient code doesn't affect the daily running of a system all that much. Because of this obvious flaw, we tend to let inefficient code slide past because it's not really harming anyone, right? Wrong. Code inefficiency adds up over time and this leads to a slower execution and overly long processing times for clients. Incorporating regular code checks to remove inefficient snippets will do a lot over the long term, even though chances are you won't appreciate it unless you left that inefficient code in there and have to wonder later down the line why your code's taking such a long time to execute. Don't let past you lead to suffering for future you. Inspect your code for efficiency when you can.

Don't be Afraid of Code Rewrites for Non-Critical Helpers


The thing with ABAP coding is that what might seem like a great workaround or patch today will have someone coming in later down the line five or even just two years later looking at that code and saying, "You know, we could have done this a lot better by using new tools..." Rewriting non-critical code sections in order to take advantage of new technology and development in the ABAP language makes for a good paradigm to keep code efficient. Upgrades to the language can be used to make workarounds more efficient. What would have needed twenty lines of code a few years ago might only need a couple lines today, utilizing new methods. The long-term benefits of this sort of optimization is something you can definitely feel.

Reusable Code doesn't mean Cloning


Calling methods and libraries allows us to access functions that have been designed with the intention of being "plug-and-play". We call them, pass them parameters and we get results. However, when we copy code from somewhere else as opposed to calling it, we introduce cloned statements. These can lead to slowdowns over time, especially if there are code snippets that are copies of copies lying around on the system after the involvement of a business plan writer. Best practice would indicate that we should find and terminate these snippets anywhere we can to ensure that our processing power isn't being abused.

Keep Efficiency in Mind While Coding


There's no way to code something perfectly from the first pass. There are always changes to be done to code, bugs to be worked out and sometimes your code just doesn't work the way you want it to. That’s fine, it's all part of being a programmer. However, when you're doing that debugging or inspecting an old code snippet for an idea of how it works, you should keep in mind how these small changes can affect your system's overall performance. Sometimes, all it needs is a little cleaning for your code to stop working like a jalopy and start working like a finely-tuned race car.
3 Comments
Labels in this area