Code less, reuse more: Rebels, rejoin!
We must resist and fight against the stakeholders empire. Let’s make our world (code) better to live!
This is a prologue to a series of episodes about applying current tools available on ABAP Stack to lead code into maintainability track. This side project is sponsored by your likes, the first episode is guaranteed but the next ones depends on community reaction.
Maintainability is one of important foundations to have a good codebase. Recapping its definition from Wikipedia,
Maintainability is the ease with which a product can be maintained in order to:
- correct defects or their cause,
- repair or replace faulty or worn-out components without having to replace still working parts,
- prevent unexpected working condition,
- maximize a product’s useful life,
- maximize efficiency, reliability, and safety,
- meet new requirements,
- make future maintenance easier, or
- cope with a changed environment.
Why maintainability is important?
Requirements changes, arises, bugs are found, performance problems are identified, new technologies / 3rd party software must be integrated. Time passes and codebase grows. If you don’t keep it tidy and clean, you are asking for trouble, even for your future self.
bombcode has been planted!
Reusability is one path to achieve better maintainability, because the reusable part is extensively test edin a multitude of scenarios, and when you fix or improve this reusable part, you are fixing /improving the same situation in all others scenarios that use it. Not only that, you write new code faster, because this reusable part is assumed to be working as expected, you just need to test and validate your new lines.
Code duplication, for example, is something everyone wants to avoid, and one good example of how things can be done better when you have reusability in mind. You, as a developer, don’t want to rewrite everything every time. On the same thread you have decoupling, a piece of code that does only one specific task. Something decoupled can be easily reused.
Let’s take a car, for example, to visualize these concepts (or recap them):
- A manufacturer reuse the same engine, transmission, chassis, and almost every piece in a multitude of vehicles, with some adjustments (classes/function modules and its parameters).
- Those pieces are decoupled and are built to execute a specific task: engine turns fuel into mechanical energy, transmission adapts the output of the engine to the drive wheels, chassis is a solid support for every major part of a car, and hold everything together.
- If something breaks or wears out, you can simple change it. You don’t buy a new car when the tires are worn out.
- With fuel evolution, first adapted cars replaced only engine/drive train (rewrite to work in HANA / integrate with external software) and kept all others components, because they still works fine for now. There is room for improvements, body were designed for keep fossil fuel engine cool and this is not required in electric engine, so a new body with lower drag coefficient can be designed (take HANA / external software capabilities to build features unthinkable in old scenario).
- The driver (end-user) still know how to drive the car, even if every internal component is changed, because the throttle, brake pedal, wheel is the same (user interface). Fancy features like radio controls can be added (Fiori, Flutter, Angular, Xamarin, any other UI technology, there are plenty), and only minor changes are required in the car internal components (OData/REST/Cloud Connector/API Management).
Because manufacturers don’t reinvent the wheel every time they need to build a new car model, they save money, and less expenses turns into a bigger profit margins.
The empire is ruling over us
These principles are used almost everywhere, because they are not new. Somehow they don’t landed properly in ABAP world (or landed pretty late). If the system you works only use a plain packages layout based on standard modules name (ZFI, ZSD,…), which simply hides everything almost barely related in the package related to module/team responsible to develop it, the empire already took the power. They can even exist inside those generic containers, but you are on your own to identify what is written to be reused or not. You must resist and fight back to make this information public!
Take your weapons and join us in the battlefield
Packages are simple but a powerful weapon in this war. You only reuse something if you know it exists, and you ensure everyone reuses it when you lock down the internal objects and exposes only the ones which should be used.
Stay tuned for more instructions to win this war. Next episode is about packages and how Package Check is used to blame who violates reusable objects and collaborates with the empire in this fight. If you want some spoiler just search for them in blog posts.
Dear Thales, this is indeed, a war! I've always wondered why reusability was so scarce in so many systems I've worked in. All objects which might be useful to reuse are tucked away in one of the dozens of packages usually, and how could I find them or even know that they already exist?
I myself built many reusable objects and tools which are probably somewhere forgotten and not used by the developers that came after myself, simply because they probably didn't care to find them or simply didn't know about them.
Maybe using a specific naming convention might help, or organizing reusables in relevant packages in order to make a separation between reusable modules/objects and the ones which contain logic that's very specific to just a certain application. But rarely do we get the big picture from the very beginning, in order to be able to properly plan some kind of framework. New SAP implementations have a chance though.
I never gave this aspect too much thought, and I'm very curious about your next posts. I'm hoping for some practical tips and advice!
Your firsts words is the first impression for a majority of coders who programmed in others languages before even knowing what ABAP is (including me). The SAPGUI editor didn’t help either, “find a needle in a haystack” seemed that was wrote for the occasion.
We are also in a paradox, that impression make us lost hope and think: “why should I spend time trying to find reusable things if no one one is writing them?”. And the vicious cycle goes on “Why I should bother to write them if no one will uses except me?”.
New implementations are easier to keep on track because every code is new, but everyone have a chance with refactoring. Business must understand that code is also a valuable asset, because it brings medium to long term benefits.
I should stop here or I’ll give spoilers from episodes that I did not even begin to write. There are so many topics to be discussed…
Thanks for passing by!
In regard to packages that start with ZFI_ or ZSD_. At my company we did that for years. Back in 1999 the consultants told us that is the way it is done and we never questioned it until recently.
Even for standard SAP objects the naming conventions are all over the place, making them difficult to find. Even BAPIs do not have consistent naming.
Oddly enough the only thing I could ever be sure SAP intended to be re-used all over the place was function module REUSE_ALV_GRID_DISPLAY, the clue being in the name.
Talking to my friends I found that this same scenario repeats for systems implemented in 90's, 00's: same package names and who questioned it received similars answers to "that is the way it is done". No one bothered to understand more why he did it or how to improve it because a consultant title means someone with a good knowledge about something, so "he/she must know something that we don't" was the implicit conclusion for who questioned it.
Yet SAP provides a special place to GUI Control reuse complenents in menu, they should list on that menu (or a special transaction lika a ABAPREUSE) a new documentation describing all objects intended for reuse. Some of them we learn by life because are the default solution: ALV for data display in tabular/tree format, SAPScript/SmartForms/AdobeForms for spool generation (we could build the spool using only GOF/OTF commands, but no one have time for that), others are also documented on Help Pages, but if you don't know what to type on search engine you don't find them. I once implemented a REST service using only CL_HTTP classes to just after discover that there was ABAP REST Framework to speed up development. There was also SPTA framework that I discovered by accident, which speed up parallel processing implementation that respects RFC server group configurations.
I mainly rely on two points to consider something was made to be reusable: a demo report provided with it as a main object or the it being listed in a Package Interface.
Just one funny fact on REUSE_ALV_GRID_DISPLAY :
While to you - as you pointed out - the intention of "re-use" was clear, it might have been confusing for German-speakers: in German "Reuse" ist the word for a fish trap. !
Wow!!! Now this is a very hard thing to do - find and use reusable code. There are so many reasons not to do it. BUT over the long term - yes, yes, yes....
After saying that. It is hard to do. We all have deadlines, so sometimes we just write a quick object/method to do what we want it to.
My next observation.... Moving to HANA? Maybe just a version of netweaver tools. I used to be semi-good at finding things I could reuse. Now I'm trying to get used to a whole new way of searching for things..... CDS - can still kind of find it with the data dictionary, AMDP - still kind of find it in class/method, procedures - sorry you are stuck with the Eclipse search. (And yes I find myself going back and fourth between Eclipse and GUI. That is probably another topic by itself.
I really like this blog - please do continue forward!
Our deadliest nemesis and also the only reason to sometimes break the good coding rules: deadlines.
As you said, the entire change is fulfilled only in the medium / long term, due existing codebase, and with the team really working as a team. You have to do a dirty little thing on code due the deadline, the next one who need to change something in that same class/function and notice that hack can be helpful and replace it with a reusable object if already exists or move it to a class and declare "now is this reusable for all". Brick by brick we build a better
The challenges to find reusable things... yes, this can span to another episode, even with a spin-off trying to figure out why a task that should be easy is not that easy in this side of galaxy. I'll try to give some glimpse about that matter (it is indirect related but I can make a link to this topic) on my next post for this series, maybe a deep dive later.
Thanks for the feedback
I found this series via the featured Blogs ( https://blogs.sap.com/2019/09/30/featured-blog-contributors-july-august-2019/ ) and started with this first part.
I really like where this seems to be going and look forward to reading more.
Some time ago I tried to dive into ABAP-Packages: https://blogs.sap.com/2017/01/11/whats-to-know-about-abap-package-concepts-se21-today/ .
So I hope you might be the person that not only knows about all the features of ABAP Packages, but also actually utilizes them?! Looking forward to reading more (I'll look at the next part night now!) very much!
I saw your blog post about packages when I was deciding what contents should I put on mine, and like you have stated, the simple act to acitvate it is not documented on documentation, but on a KBA note. Terminology on help pages also leads to think that one should bother with packages concept only if it is developing an addon to sell it (transporting layer, server/client), but is a much simpler thing that eveyone can use and have direct benefits.
This theme always bothered me since month-1 with ABAP, but today I can use it the way it's meant to be used.