ABAP Mentor

Watch My New Pluralsight Course

How to Make Your Life Difficult in Three Different Ways?

As an ABAP developer, writing ABAP programs is easy as 1 + 1. First, we learn the basic syntax, then - as a next step - we try to modify code written by other developers, and finally we write our first ABAP program independently. That’s it!

There is no difference, even if we talk about ABAP Dictionary: we learn the basic features of ABAP Dictionary – we learn how to create domains, data elements, or database tables – then we try to modify objects created by others, and finally we build our very first structure, database tables, or view. This is the learning curve that a beginner ABAP Developer usually follows.

It’s obvious that our first few ABAP or ABAP Dictionary implementations won’t be a mature development, actually we will give thanks that we could finally done our job, nothing else.

Let’s be honest, these implementations suffer from a lack transparency, consistency, and contains a tons of meaningless identifiers – so no one can understand what our intent was when we built it in this way.

It’s okay, don’t worry about that! All ABAP developers – me, you and other ABAP developers – have their dark past, we all did things that we are not really proud of, but the point is you have to be open-minded for the further improvements, the best practices, and you have to learn and improve yourself.

The mistakes that ABAP Developers usually commit during their carrier:

#1 Use Meaningless Identifiers

“Mike: In the field, Field 1 we store GL Accounts, and you can find their related Chart of Accounts in the field, Field 2.”

Choosing meaningful identifier is a really tough work, you have to work for it hardly, you have to find the one that describes it the most. Identifiers like Field 1, Field 2, Field 3 usually born at the time when we just want to overcome our tasks, when we want to “get the job done”.

At the first sight, we feel “Ohh, finally I’m ready..”, but it does not end here. From now on, we are responsible for this implementation, and we have to explain it every time whenever someone connected to the objects developed by us, since no one can understand – sometimes we neither – what our intent was when we built it in this way.

#2 Mix Business Data in a Single Field

“Mike: If the field, Type contains ‘CC’, then in the field, Field 3 we store Cost Centers, but if the field, Type contains ‘CE’, then in the field, Field 3 we store Cost Elements.”

It was years ago, when I first heard about the SRP – Single Responsibility Principle – and from that moment, I try to apply this concept to all areas of my life. It works, and during this time I have experienced that a few simple things is always better, than a complex one. Why would you store Cost Centers and Cost Elements in a single field depending on a “Type” field? I saw this many times…

To build a table like this above is very simple, but to explain to your colleagues is tough, to modify is painful, and to simply work with it is a nightmare.

#3 Define Tables with Hard-Coded Predefined Types

“John: ZTECH_CODES-FIELD1 and ZTECH_CODES_STR-FIELD1 are similar fields?” “Mike: Yes, of course. They both contains GL Accounts.” “John: Then, why ZTECH_CODES-FIELD1 is CHAR10, and ZTECH_CODES_STR-FIELD1 is CHAR12? What happened?”

Of course, there are many anti-patterns that you should avoid, but my last one is the usage of the hard-coded predefined types. Defining your tables with predefined types is the easiest approach, no need to develop any domains or data elements, you only need to list your fields and their corresponding definitions. That’s it! But as you know, every cheap solution has its drawbacks also.

I say three words: maintenance costs, consistency, and reusability.

If you have a field to modify that is included at least in three tables and two structures – of course defined with predefined types, then

• maintenance costs: you have to modify that field five different times,
• consistency: you can easily make typos and mistakes – it’s really hard to perform something five different times in the same way,
• reusability: you have no chance to reuse your building blocks, you need to build these definitions multiple times.
  

Watch My New Pluralsight Course

Avoiding this three mistakes above in your ABAP Dictionary implementations, helps you to

• eliminate the unnecessary explanation rounds,
• minimize the probability of making typos and mistakes,
• improve your productivity by reusing your existing building blocks.

How you can avoid these mistakes? This is what I answer in my new Pluralsight course, called Understanding ABAP Dictionary!