Skip to Content
Personal Insights

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.

The bomb code 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.

A smart ostrich from a famous comedy cartoon laughing about this lame but yet precise joke

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.

2 Comments
You must be Logged on to comment or reply to a post.
  • 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!

    Cheers!

    • 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!