17/03/2013: An important part of building robust code is the correct code modularization. I don`t pretent to be an expert, but if you`re interested in my opinion on that, read the new blog called ABAP code modularization: lesson learnt.
Many people are already practicing or at least considering “agile development” on their projects nowadays. The development cycles get shorter, faster and teams must work with the ubiquitous uncertainty and fight it with unprecedented flexibility. Although there are methodologies and tools to cope with the uncertainty on the project level, there are also ways and tricks on “development army of one” level that can help too.
If you think ahead, try to foresee the requests and ideas forcing you to change what you`ve built so far, you can prepare yourself for the change and minimize the impact of the changes that might come. And they always come.
You can also approach the thing statistically. Let`s say that you have ten developers on the team. Let`s say every one of them needs to rewrite something from the past every few days, let`s say 2 hours per week… then you can immediately see the benefit as a project manager (or development lead). I am not implying that you will be able to get rid of this overhead completely or that a developer that must (or simply wants for technical reasons that project managers don`t “get” quite often) go and rewrite things is a bad developer. It`s NOT like that. But one can get ready for the cases and reduce the overhead.
Example #1: Parameters of the calls …example for the lazy
You`re building a skeleton of the application, prepare function and method calls, objects, screens and leave the details of the implementation for later (that is my way, because I believe that the design is the most important thing at the beginning. You don`t have time to change the design of the application on the way and you don`t have time to start over almost never. That means that you can segment the application with the big picture in mind and then assign team members to implement “details” as they have time or their different skill sets are used).
Now let`s say that the customer comes and says something like “we need to build another layer on top of you have here, guys”, which means to go and enrich the application with a set of new attributes and parameters (note that you have to add the new parameters to the calls + populate them in the coding too!). If you have your skeleton with calls and arguments already finished or nearly finished, touching every call again to add the new parameter or two can become a nightmare (and it`s certainly boring and not challenging at all, does not sound fun, right?).
But you could have made yourself “ready” for this. If you had just one parameter narrowing the selection, it was tempting to send that parameter as a string or range table, right? Send it via dedicated parameter. Now think about the situation when you had anticipated this and that’s why you created a –structure dedicated for selection parameters. At the time you created the structure it meant that the structure had just one attribute, the one we mentioned above as being the only one. Now you know you need more so you just go to this definition and add other selection parameters as per the changed requirement. You don`t have to change anything in the coding, except one or two places where the new parameters must get populated and where they must be used for the real selection.
Example #2: Performance considerations …real world example
The first example was something that could spare you the time and clicking around, maybe some testing if you have to add too much and the thing becomes error prone because of that. This second example about performance is much more serious, because you might be forced to rebuild (maybe even from scratch!!) something that you have and works. Unfortunately it does not work for large data volume.
Before I explain the situation and my “trick”, consider this: you do development in the development system and that is rarely “stuffed with data”. You often have “some data” in the DEV system, but the volume, the quality and other aspects are often far from the production data (ok, we can argue here, that you have a tool or a team that gets this right for you, but I have seen this going wrong too many times…). Same applies for quality system (often because somebody declined to make the confidential data available for development or testing). So you can experience something like me: you build your application, everything works fine in DEV and QAS, but in PROD you get dumps and timeouts, because the program is just not optimized for the huge workload. When I first experienced this, I had to rebuild the considerable part of my application and decided to think about the problems more in the future, rather do 5% overhead than 50% reworking.
Now the trick: I did and often see the beginners to create methods (functions) called ADD_DETAILS_FOR_OBJECT. That code gets a structure on the input with one (key/ definition) and then queries various tables for additional details that then get compiled in the same structures fields and sent to output. Now typical scenario: You have a table of the objects you need to get the details for and you run your ADD_DETAILS_FOR_OBJECT function in a LOOP. But the function is full of SELECT SINGLE * things and other “expensive” operations. This is the corporate world; we always do things for more than just one record. This will eventually happen to you too.
Now imagine you thought about this and had built the application the “clever” (the right) way. Instead of implementing the ADD_DETAILS_FOR_MULTIPLE as a LOOP calling the function for one object, you could have implemented it the other way round. That would mean to build a _MULTIPLE code full of SELECTs and JOINs and RANGEs to make the functionality very performing and implement _FOR_OBJECT function as a call to _MULTIPLE passing just one record in the input table.
Maybe this sound naïve to you, you might think that everybody does it this way. No they don`t. It is important to note that the time or effort needed to implement the functionality “in the correct direction” is no different to the bad one.
Example #3: Look at SAP standard authority-check function modules
Take a look at the ways how some of the authority checks are called from within the SAP standard. You know how to code the AUTHORITY-CHECK I hope. You can put the construct anywhere in your code. But SAP is clever and (not in all the cases, but at least in some cases) calls central function modules to check the user authorizations (central = user authorizations for an object is coded once and called many).
The lessons here are two: first is look for these function-modules and call them instead of coding your own authority checks. Often there are multiple objects working together in a complex way and if you just go and copy few lines from that complex logic, you might damage the intended concept. You might never realize that you damaged the concept but your new coding might force the administrators/ security people/ role builders (however you call them) to give very powerful access to all people that need to use the new development, although that access didn`t have to be given when SAP standard coding was in use.
The second lesson is: complex things must be coded once. But in this case I admit I am telling the truly obvious things.
Conclusion
I could go on with my suggestions, but I prefer a discussion than a listing of my ideas (that people don`t necessary share). I was considering adding a ALV field catalog dynamic generation as one of my tricks. I like to create a structure, ask REUSE_ALV_FIELDCATALOG_MERGE to prepare the field catalog for me and then (if needed) I change some lines in the generated definition. That means that when you add a column to your structure, it immediately “works” (user can see the field and the value). But I know so many developers that still create field catalogs statically (you know, those funny screens of copied code with changed column header texts) or do other strange things. But as you can see (or feel) that this is something others might not agree about, so listing more of my “tricks” would not help the message.
I welcome comments about my blogs even if you don`t agree with me. Please comment.
I am also very keen on ideas coming from people all around SCN which I can learn something from. I got some comments about ways I have never used under my last blog about debugging. I would love to learn something again here. Please tell us about your tricks, habits, ways and improvements.
Cheers Otto
- SAP Managed Tags:
37 Comments
| User | Count |
|---|---|
| 3 | |
| 3 | |
| 3 | |
| 2 | |
| 2 | |
| 2 | |
| 2 | |
| 1 | |
| 1 | |
| 1 |
