This blog might look like SAP marketing. It is not. It might sound a little pathetic or provocative, ok, might be. But the things I am going to describe are very important for me and should for every developer. This is my opinion and you don`t have to agree.
When I was just an ABAP kid, I used to write ABAP as if it is PHP or Pascal. I had no idea how to use standard, how to debug standard or what treasury is hidden in there. My codes were very talkative and most of things I needed to do I did through SELECTs and LOOPs plus standard types (like I and C and TYPES command). Not the right way how to do ABAP, but this is how I began. Maybe you can even recognize some pieces of your own experience here.
In next weeks I started using some function modules, but only those I had to. READ_TEXT, SAVE_TEXT is just so important and saves so much work. It is also easy to understand how they work, so it was not difficult to start using things like that. Same applies on printing for example, the function modules are well known and the only way how to do the printing.
I didn`t have to use much of the standard. I was not forced to do that. I didn`t have anybody to ask how to do that. I was scared about the complexity. So I was spending time building things by myself. But that`s nonsense. Now I know.
One of the things I regret the most since I started with SAP is that I didn`t care enough about the standard. I didn`t understand how powerful it is and how much work/ time/ effort can one spare this way. That`s why I am writing this blog. To explain the importance of reusing SAP standard and to thank the SAP developers for building the code the way we can reuse their work in most cases.
If you`re young and can spend nights and weekends finishing things you were not able to finish during the work week, you can spend time building things from scratch. In that case you only care about the result – works or does not work. But there is much more to care about:
- Number of custom objects - well this is not a typical concern; it is not a problem when you create few more objects. But what if all the developers create “some more” dictionary objects than are necessary and they keep doing that for weeks? Months? Years? Don`t you feel that this could be wrong? Or that it could cause some problems in the future? Maybe it is not considered best practice, but before creating a data type, why don`t you check SE11 if a similar data type you could reuse, is not there already? My favorite example: you need a table type for a standard structure. In my opinion a good way of building things is to check “where-used list” for the standard structure. You will most like find an existing table type. My point is that we should care more about the customer and his system and understand the big picture. Developer`s responsibility does not end at 5 o`clock.
- Custom code management – the example about numbers is mainly about feeling the problem. That it might cause problems. Most people don`t care because they finish their development and move on (another project). Or they “only build things and that`s it”. You think you only a small fish in a big pond, aren`t you? Some people don`t see the big picture (or they simply ignore it?): system full of custom development becomes insecure, can`t be upgraded (at some point in time, not like tomorrow), code maintenance costs are too high, changes of the custom code cause unpredictable behavior, stuff like that. Who cares about these things, throw a stone. Every one of us adds a small piece to the problem which arises after a longer period of time, but sooner or later it will arise. If we all try to be slightly more precise the big picture could change considerably.
- Team work – when you`re working in a team, why bother your colleagues explaining how is your super great function module working when there is a comparable standard one – stable (tested), documented, part of the standard (already in all the systems), used in standard development (so one can use debug to see how it works, how it is called). I used to bother my colleagues: “hey guys, see what I have built”. I feel so ashamed now, when I realize I caused them extra problems instead of being helpful. Other example: what if two of the team members build their own function modules doing the same? Inconsistency! Or at least a risk. Create similar data dictionary objects? Can you feel how much hassle you add to the development process instead of simplifying?
- Documentation – everything you create you`re supposed to document. The more you create the more you have to document. So you add the amount of work at least twice: you create more and then document more. And if we would discuss the topic carefully we would find even more extra or repetitive work caused by the careless reuse of SAP standard.
- Reusing not only how it “works” but also the “look and feel” – quite often you don`t build something completely new. You don`t build new SAP module like every day, right? You`re trying to build something what you miss in the standard, tweak the standard behavior a little. So every time you build something, there are user expectations (based on the current user experience) about how the new report/ transaction will look like, interact with them etc. My point is that in such cases one could consider the best practice to reuse the existing dialogs (screens + behavior). Ok, let`s do that. How do you reuse them? You copy the screens? Recreate them? No way, you will look for a way, how to call the existing dialog, right? That means you will look for a function module I guess (thanks SAP guys that so many of the dialogs are nicely wrapped up in a function modules). So because of the UI you will most probably reuse “some” functionality behind it. And I could continue like that. If you believe in this way, you can get to 50% of standard code reusability, 60%, 70% etc.
- When the upgrade comes… – well, this point was a part of the custom code management bullet above, but maybe I should emphasize it as a separate point. Example: you copy a function module into a Z-one, change it and happily finish your development. Then the upgrade comes. Then your code must be revised and fixed manually although the upgrade brought the fix for free. Or you handle things the way you found in the standard code, but then adapted the algorithm in your custom code. Then the upgrade comes and the standard table you were reading with your custom code changes. Boom. You have to fix it manually. I am sure you get my point.
One of the reasons for writing this blog is that I think that understanding the concept of reusability made me a better developer. It taught me a lot about SAP builds its software. It taught me about features I didn`t know before. It taught me about additional costs I didn`t realize when I was just an ABAP kid. It made me realize that I was not top efficient. And many other things…
Maybe I am explaining something obvious. Something you know for years. Ok, I am not here to tell the pros how they`re supposed to build their code. But still hope that there are some beginners there or even experienced programmers, who can admit that they could do better, who will follow my advice.
Using /h should be something you do like every day. Call stacks, local and global variables tab in the debugger and much more. It will not take long and you will understand the prefixes of the function groups. You have to start thinking about that and it will come to you.
I was going to end my story here, but realized that I might get some suggestions to learn about BADIs, user exits, enhancement points. I know how they work. I saw some cool nightmares in the customer system caused by these modifications. So not everything is Gold that shines…
