ABAP code modularization: lesson learnt

Topic for today is how to structure the ABAP program code to suit best some important needs. Before you even start reading, please consider I am not a hardcore ABAP Objects guy. Not that I don`t know how to do Objects, I was originally a JAVA programmer years ago and there object-oriented programming is nearly the only way how to build readable and maintainable code. But I am also pragmatic and have met many smart people that helped me shape this pragmatism.

Maybe the most important of these lessons came from my colleague from SAP, who is SAP Platinum Consultant  BTW, who complained about some junior, who was supposed to build a simple report for him. When he asked what`s the status after two days, the junior said he is “almost there”. But it took him 5 days at the end to finish very simple FI-CA report just because he used ABAP Objects instead of the imperative way in the report. The senior consultant could have done it in half a day himself and when he reviewed the work, it was obvious the Objects caused the delay.

Lesson learnt (1): When it is an overkill to do it in Objects, well, don`t do it in Objects.

I don`t say Objects are not great or it is a general rule that using ABAP Objects makes the project twice as long (so it also costs twice that much). Not at all. What I am saying is that you must not use Objects everywhere, just because you`re “hardcore ABAP Objects guy”. This is not a holy war (please don`t start a classical SDN flame-war because of this blog, really, I am trying to be pragmatic and share something I find useful). So just because you think Objects are great or (like in my case BTW) you were taught Objects (meaning not necessarily ABAP Objects), you don`t HAVE TO use it everywhere.

Lesson learnt (2): For long time maintainability and your own sanity build at least two types of methods (code “blocks”): those that do low level things (do “machine things”) and those that are there for the developer (help with “reading” and orientation of a human).

If that`s possible, I try to stick to this rule all the time. What I mean to say is that there must be some methods (sections of code, FORMs or just report code, whatever) that you read like a story. You don`t have to deal with too much comments there, because they`re not necessary (code modules are named smartly), you don`t deal with too many variables, because the variables exchange is somewhat smart too etc.

Example (simplified): lr_redhood = initialize_red_riding_hood( ), lr_redhood->load_basket( ), DO 10 TIMES. Lr_redhood->Go_through_forest( ). ENDDO. Meet_the_wolf( ), free( lr_wolf).

I am trying to be amusing here, but hope the message comes through as well. You need code that provides an overview over complicated things so when you need to debug the thing, when you need to maintain it or develop further, this method (“story-like” piece of code) tells you where to go (which lower level method to change/ debug) or where to add the new functionality.

Lesson learnt (3): Build your code with someone else in mind. Do not be selfish. Imagine you get hit by a bus. Or something nicer: you get promoted and your colleagues need to take over your work on the code. Or something from the everyday practice: Imagine that there is a stranger that needs to interface with your code.

It would be ideal to build code that is well-structured, well-commented and all that even if you know you will be maintaining the code for next years. But people don`t do that. They think: hmmm, I know what this thing is doing, I don`t need to beautify it for myself. They also don`t think about someone else. Why would they? That would create just more work for them now and it is rather theoretical that it will cause lots more problems to someone else in future. It is like with the debts. Stupid thing, but people still do it.

Let me focus on the last remark about the interfaces. I want to say two things here.

First is that I am very happy that SAP provides many interfaces. Thanks a ton guys.

Second one is that many of these interfaces are not released, they`re not stable and for whatever reason they`re maybe interfaces only because the developer modularized his (her) code well. Then it is rather a side-effect I can tap into the functionality than a purpose (assumption).

Lesson learnt (3a): Build your code so it can be used by a stranger from outside. Not because you want people to interface with you but it can happen sooner or later, that you want to lift some of your low level functionality and offer it via interfaces.

No one does all these things right the first time. Especially when it is not 100% certain what must be developed. I don`t encourage you, dear developers, to accept work which is not well-defined, but this world is fast and we have to deal with it. There is no other way than accept only briefly described task time to time. No one does all these things right, because small project can be promoted to a big beast in the next week or other things no one can foresee in 100% of the cases. It is the same thing like with bugs: no matter how good you are, no matter what you do, you will always have bugs (maybe not that many, but no one is perfect, right?).

Remember this for your coding and think about clear interfaces that can come later. Please. Not just you, gurus at SIs or partners or at customers, also you – SAP ladies and gentlemen. When you`re asked to do something later to help the world become better, you say NO NO, OSS note #11, we don`t want that (means we don`t understand that) or it is consulting (pay us for that).

Side note: Although it may sound like a complain, please take it the other way round: If you build your code well at SAP and you`re open to improvements (because there are tons of use cases that you`ve never thought of, I can assure you, I am always surprised how customers use my software), hats off and thank you. Unfortunately one cannot contact OSS to say “please pass my regards to Mr./Mrs. Developer(ette) for that super-cool class/ INCLUDE/ FUNCTION”. This is my way to say thank you. You know who you are!

Lesson learnt (4): Modularize your code so you can support it easily.

This is often less important for developers on the customer side (from experience, not a general rule, no offense) because they themselves are the only people dealing with the code. For partner developers building add-ons and SAP ladies and gentlemen, this is crucial. Imagine: you have a customer on the phone or you`ve just got an OSS message that something does not work. Let’s put aside the fact that first thing SAP support does is to ask you to open a connection to the system. Not everyone is ready to do that. It will also help us to build our case in a more general way: partners cannot always access customers` systems remotely at that very second when a customer calls.

Now when you see the situation, what do you do? Do you provide test reports that the customer can run without fear even in the production system and the output will tell you everything you need to explain or fix the issue? Well, that would be really cool. Or do you tell the customer to start debugging your code? Unlikely. Do you drive to the customer to take a look? When you have someone on-site or it`s in the block next to yours, that`s fine, but fly to other countries or drive some hours because of a support case? Expensive, slow etc. So it is essential to think about the obstacles that might or might not come before they arrive. Design problem is cheap to fix compared to the production code fix, isn`t it so. They teach it in every school.

Lesson learnt (5): Since you want to keep your support costs and effort on minimum, you need to test more/ better to prevent the support need. Modularize your code so you can test it easily.

This is a no-brainer, you don`t have to be a rocket scientist to figure it out. But there are some aspects that are not so easy.

Let`s discuss the “old way” or the “often-seen way” first. If the developer tests, then a) using the debugger and that`s it, or b) using some test programs (quality of programs varies, also the coverage). What`s wrong with that? Nothing, I would say, but there must be something better… So I started searching and found ABAP Unit time ago. I can`t say how widely spread Unit is. Can someone tell me? Anyway the point here is that to be able to use Unit, you often need to change the way you modularize your code – some must change more, some less.

I can recommend the following article I found very cool, not just about ABAP Unit but also Test-Driven Development methodology: Adopting Test Driven Development using ABAP Unit.

Even if you don`t adopt this or another methodology in its entirety, when you start thinking about testing more as an opportunity than a burden, it can help you change the way you segment and modularize your code for good.

Side-note: I am a big fan of SAP-runs-SAP type of information. If there is any SAP employee who can tell us how SAP uses ABAP Unit internally, I would love to read such a story and appreciate it a lot. I have checked the where-used list for the main test class (what was the name?) and found very little hits in SAP standard code. Is that because you don`t use it? Is that because you use it, but don`t send it to customers? More information would help the Unit to spread faster, I say.

P.S.: If you`re on EHP3 or higher, you can benefit from the new ABAP Unit support described in this blog: New ABAP Unit and Coverage Analyzer Features in SAP NetWeaver 7.0 EhP3.

Lesson learnt (6): Remember the MVC (model-view-controller). You can be pragmatic with little reports, but when you build something larger or with potential to grow, build it MVC from the beginning.

You can be asking yourself why this one is number six and not number one or two (did I say it is from the most important lessons to least important? No I didn`t…). Well, as I`ve mentioned before, I am a pragmatic developer and I don`t do everything in Objects or the way they teach it in school. For simple reports I couldn`t justify the costs of MVC approach (maybe I am not that good as I think, but MVC takes me more than a simple imperative report in case of small simple reports).

I build software that is here to stay and that dozens of customers are using, so it would be good for me to do everything the right way (assuming the “right way they teach at schools would lower my support costs etc.). But… if I did everything that way (including the small simple reports – that`s the point here), I would offer my customers half the functionality they are able use now. You can decide for yourself: to be holier than the Pope or to be pragmatic.

Lesson learnt (7): Think about modularization during the maintenance and support too.

Code is a dynamic thing. You don`t write the code once and that`s it, you work on it iteratively, adding features, removing things, fixing bugs. You cannot say that the app was designed well and now you can just keep changing and adding things. Well, ideally, you could say that, if the skeleton, the strong design would be so great and so visionary that all your improvements you only do now were planned by the app designer long time ago.

But that happens very seldom, when you have great architects on board or out of pure luck. Again, no offense, maybe you`re the lucky one and you are the guru or ninja that does not make mistakes. But then think about another aspect of building software: you never build software alone. It is a team work. If you think about good design and modularization when the design changes, it is both signal to your colleagues and leading by example that you do it. It is ideal when it becomes a part of the team culture to think design and re-think design too.

Some people could call these fundamental design and structure changes a beautification. Yes, it is like that for the outside world. Better readability is one of the side-effects, but one must see beyond that. If you want to build further on something that was meant as a little nice-to-have feature, but now the customers love it and want that heavily improved, you must re-design it to be able to build sky-high towers on top of hard stable rock and not find yourself sitting on a rotten branch in the future.

If you got here, thanks for reading the piece, please leave a comment. Discussion is typically more fruitful than a dry blog. Cheers Otto