Frankenstein has Risen from the Grave
Writing another Book for SAP Press – Part One
Table of Contents
Background
What’s changed in two years?
The “myth” of Self Describing Code
Unit Testing, why is this “new”?
Background
My SAP Press book “ABAP to the Future” came out April 2015. I had expected that they would get back in touch with me about 2018 to write the second edition. Instead, the book had not even been out a year when they asked me to start writing another one.
That’s crazy isn’t it? Surely things can’t have changed that much? Oh dear, in fact they have. Since the original book took about a year to write, there had been two years of innovation by SAP at the point I started on the second edition. And when in January 2016 I got access to a brand spanking new ABAP 7.5 system it was just scary how much had changed…..
What’s New Pussycat? Oh Oh Oh Oh Oh Oh!
I had to knock out some of the “older” technology like the enhancement framework, and debugger scripting; as that is not really “new” any more, and no matter how good it is (and it is very good) it had to make way for some actual new things. At least the enhancement framework can rest easy in its bed that at least it got mentioned in one book about new ABAP things.
There was one new technology that merited a new chapter – namely ABAP channels. I have been giving speeches about this at assorted SAP conferences, including SAP TechEd in Las Vegas in October 2015, and it is a corker of a new feature, enabling you to replace polling with a publish and subscribe mechanism.
Two chapters got violent overhauls – HANA programming, due to the advent of the CDS view moving from a cameo role to being the star of the show, and good old UI5 due to radical overhauls in the SAP Web IDE and the monkey based BUILD tool arriving.
It still took me six months however (in the pub after work) to update the book. Every remaining chapter was updated to a medium to large extent, as there have just been so many changes, and what I want to focus on in this blog is why I felt he burning need to totally change every single one of the hundreds of code samples in the book. Why would I need to do such a thing? Surely ABAP hasn’t changed that much in two years I needed to change every line of code? Read on….
Breaking the Enigma Code
The original book had code samples that generally would compile on a 7.02 system, following the ever-popular SAP principle of downwards compatibility. This time I made sure that the new (7.4+) syntax was followed in all cases, which more or less halves the lines of code needed, as you can use inline declarations instead of lots of data declarations at the start of each procedure.
In addition imperative programming languages like ABAP and Java are so ten minutes ago, the latest fashion is to be a functional programming language like JavaScript. To this end Java has been enabled with lots of functional language features, like the so called “Larry the Lambda”, and ABAP is heading down that route also. A lot of the new ABAP features fall into the “functional programming” basket, you cannot pass functions as parameters (as yet) would I would not drop down dead with shock if one day soon that will be the case.
This is not the most interesting part to me though – whilst it is great the programming language is improving, at the end of the day this is just syntax. Every so often in one’s career you have to shift to a different programming language – for me it was BASIC to Pascal to ABAP, and now JavaScript for any UI5 work I do. That sort of shift is not that difficult to do, it is a lot easier than learning to speak German, I can tell you. In case you are interested I used “Rocket German” which is fantastic.
However whilst the technical syntax of your programs may change, there are some underlying philosophical aspects to writing programs which never alter. I can’t talk about such matters in an SAP Press book, I tried, but got slapped around the face with a wet fish and told it had to be a “how to” sort of book, not a “why do we do this” sort of book. I can talk about them in a blog, however.
A long time ago (01/09/2016) in a galaxy far, far, away (SCN) this blog was published:-
http://scn.sap.com/community/abap/blog/2016/09/01/how-to-fetch-nicely-2-values-from-itab-row
This was all about how to achieve the same task using one line of code, instead of three lines of code, using the new ABAP features. The problem was solved, all well and good, but for some reason the comments descended into an argument of whether or not the new features in ABAP were good or not.
I happen to think they are – I was flabbergasted when one of my colleagues the other day started sounding off about how much he hated inline declarations, which he had been forced to use at one of his clients – but as I just mentioned this is all by the by.
In the comments section of that blog you will see be saying that the aim of the game is to make the code as readable as possible. The reason being is that creating new programs is 5% of your time, enhancing and fixing existing programs is 95% of your time. So the more obvious it is what the code does, the easier time you have with the 95%.
In one blog I read someone said that please could they have an example of “self-describing code” because they had never seen any in fifteen years. I don’t know if such a thing is possible or not, but I strive for it….
If the clearest code can be achieved by using the new “functional” ABAP statements then hooray. If, to use a term in the above blog, the clearest code can be achieved by using “eighties” programming style, then hooray as well.
If you asked 100 people at random who the secret identity of Spiderman was, they would all say “Peter Parker”. However that is just Hollywood and Marvel Comics taking liberties with the truth in order to make the story more entertaining. In real life Spiderman was Donald Knuth, inventor of the concept of “literate programming”.
He invented a programming language where you wrote the program like a book, and it compiled into a tangled web that executed on the computer. People who think ABAP is verbose should take a look at his language. After he finished writing such programs he would swing through the skyscrapers of the city in order to fight Doctor Octopus.
Another programming Guru is Robert Martin (Uncle Bob). I am not sure which super-villains he would fight, but in his books (e.g. Clean Code) he would advocate writing a program like a newspaper, you have a headline saying the genera idea, and then paragraph headings describing each step in the process. He wrote a blog called “extract till you drop” where virtually the whole program was comprised of calls to really small methods. Inside those small methods was a line or two of code doing technically whatever was required. The method names were as meaningful as he could make them, and in Java you don’t have the 30 character restriction imposed by SAP, so the bulk of the code ended up being long descriptions of what was going on. I have to mention that a lot of people did not think much of this.
Taking a specific example in my day job I have to maintain every so often a program that is vital to our company, that is written in one giant great block of code with no routines whatsoever i.e. it is not even procedural, let alone OO.
I would get in trouble if I attempted wholesale surgery, so I restrict myself to the “boy scout rule” and leave the program a little better each time I change something. First of all I abstract whatever I am changing into its own routine (preferable a local/global class method for reasons which will become clear in the next section).
I can and will use the new syntax where it helps but mostly I will change the names so they mean something. In this example I found a global internal table called GT_LIPS and I had no idea what it was for. I found out that it got filled by reading from VBAP, so the name made no sense at all. As a first step I change its name to GT_ALL_ORDER_ITEMS_FOR_DELIVERY or some such as that is what it got filled with, all the order line items for a specific delivery.
Much later I found out its actual purpose, which was to amalgamate delivered quantities for different order lines that ended up going to the same place. Then I changed the name of the table to reflect its actual purpose.
This brings up another common programming principle called “make wrong code look wrong”.
http://www.joelonsoftware.com/articles/Wrong.html
If you have meaningful names for everything, then logical errors in the code just jump out at you, like DB.
Another recent change I have made in my programming style relates to variable names.
http://scn.sap.com/people/uwe.schieferstein/blog/2009/08/30/nomen-est-omen--abap-naming-conventions
When that blog came out I thought it was great, as you can see by my comments. As time goes by though, I have come to the conclusion that the so called (and really, really, mis-named) “Hungarian Notation” has no place in OO methods. I think it is still needed when maintaining monstrous procedural programs, where I found the same variable name is used for a global variable, a form routine parameter and a local variable, and put prefixes on the front to tell them apart.
In the second edition of my book, in the code samples, you will see the “LD_” and “LT_” prefixes have vanished. As it turns out that improved the code a lot more than you might think, as it forced me to make it really obvious what was a table, what was a structure and what was a single value from the name alone. I could just feel the code getting better with every such change and that made me dance around the room, singing with joy. Inline declarations helped a lot here, following another famous maxim that methods should be really short, so halving the length by ditching the data declarations at the top helped heaps.
To summarise, I would say that your usage (or not) of the new ABAP functional statements, or the urge to replace three lines of code with one line, is a bit beside the point.
If you have a really short concise block of code doing something important, but you have used so many new features that code is impossible to read/understand, the you can put that line in a method which says what is happening. This separates the “what” from the “how”. It would be good to put a “why” in the comment for that method as well. The “why” rarely changes, the “what” changes more often, and the “how” changes all the time, so they need to be separated.
I am now going to seem to do a total no sequitur and branch off in an unexpected direction, but hopefully I can explain how two seemingly different topics are connected. The “bizarre” topic I want to talk about now is unit testing.
Holistic on My Collar
In the papers here in Australia the other day was a story about how one of the big banks got a huge fine, and had to pay billions – yes billions – of dollars back to customers because they had been overcharged due to a “programming error”.
Let us be charitable for a second and say that the bank did not deliberately tell the programmers to write things in such a way as to rip off the customers. Let us say it really was a programming error. If that really was the case, and I was the programmer, and my mistake had cost the bank billions, I imagine things would not go that well for me.
It could be even worse – what if my programming error gave people the wrong dosage of a drug, and killed them, or made a plane fall out of the sky?
This is why I keep on and on, like a broken record, about unit testing, and specifically (in SAP world) ABAP Unit.
Follow the “missing link” at the bottom of the blog and download the “reading sample” chapter from the second edition of my book, which comes out 19/09/2016.
There is no need for me to regurgitate the entire contents here, but the point I am trying to make is that well written unit tests read exactly like English sentences. In fact they should read almost exactly like the specification, at the highest levels, saying what is trying to be achieved. The next lower level methods should have names that describe what is going on to fulfil that goal, and the “how” code is blank.
Blank? This is because you write the tests before you write the code. You should start with the aims of the program and have tests that clearly state those aims, and what the program will do in order to achieve those aims, and how you can tell success from failure.
Only then can you get down to the “how” where you can use the new functional statements as much or as little as you like. It just has to be obvious to anyone who looks what is going on, and worded in such a way that any mistake stands out.
You then fill out the classes/methods that you had to create in order to get the tests to compile. I keep on about this so much because it will make your life so much easier. I spent a year writing the most complicated program I have ever written, and probably ever will write, I can’t say what it is, but our competitors aren’t going to like it when it goes live in a few months’ time.
All through that process I did the “test driven development” thing, and in the yearlong pilot have there been any “real” errors? (A real error is a programming bug; a lot of actual “errors” reported are “we gave you the wrong specification”). No. Not a single one. As long as I have the specification correct, it literally cannot go wrong, as the unit test would fail before the code even got out of development.
I have an existing program that I inherited, and maintain, and that has errors all the time, and as soon as I fix something, something else breaks. This is because it has no unit tests, and I am trying to introduce them, which is a bit more difficult in a procedural program, but not impossible.
Summary Execution
I would summarise this blog as follows:-
- · The new features in ABAP are great, but that is beside the point
- · The point is to try and make the code as readable as possible
- · If you follow a test driven development approach you are pretty much forced to follow a “make it readable” standard
I have no doubt many people will disagree with some/all of what I have said above. If so, please feel free to have a go in the comments section. I hope I am not so set in my ways I cannot change my mind if presented with a compelling argument against my current way of doing things.
Sadly I cannot make it to TechEd this year, I had a whale of a time last year - it is a wonderful event. If anyone reading this is going to TechEd in Las Vegas next week, I wonder if I could ask a favour.
If my book is featured on one of the walls of the SAP Press booth, could you take a picture and put that in the comments section of this blog? It’s called “ABAP To The Future” and is blue with a cartoon of a rocket on the front.
Cheersy Cheers
Paul
Missing Link
- SAP Managed Tags:
7 Comments
| User | Count |
|---|---|
| 3 | |
| 3 | |
| 3 | |
| 2 | |
| 2 | |
| 2 | |
| 2 | |
| 1 | |
| 1 | |
| 1 |
