Book Review – “The Clean Coder” by Robert Martin
Introduction
I will start and end with a link to the Amazon entry for this book:-
As might be expected I have just finished reading this book and what like to share what I thought about it and how I think it is relevant to the day to day life of an SAP programmer.
As might also be expected I am going to go off on all sorts of tangents…..
Back Story
“Why did you get this book in the first place?” I hear you ask. The answer is simple. I had no idea Robert Martin had written two books with virtually the exact same title, so I ordered the wrong one and only realised when it showed up. At that point I thought “sod it, I’ll read this one instead”.
I was trying to buy “Clean Code” as opposed to “The Clean Coder”. The first is about the code itself, the second is about the person who writes the code, i.e. people like ME. That wasn’t what I wanted, I am a computer programmer, I don’t care about PEOPLE, let alone myself, I only care about MACHINES.
Anyway, why was I trying to buy a book about clean code?
The other day I got an assignment to add a feature to the Monster Munch report (I have changed the exact nature of the program to avoid trade secret type issues). The users had noticed that in the Hula Hoop report you could select several records and then do a “mass change” of several key pieces of data of each record. Everyone thought this was great and the business analyst had determined it would be a huge efficiency boost if this feature was added to the Monster Munch report as well.
I thought to myself “I would not be surprised if once I’ve done this, the next week I’ll get a request to add this feature to the Frazzle report, and then the Wotsits report, and then the Salt’n’Shakereport, and so on…” (To put the vast bulk of the world out of their misery, these are all brands of crisps on sale in the UK).
So despite the fact that the easiest and fastest thing to do would just be to find the code in the existing report that did the desired feature and the just cut and paste it to the new report, that somehow felt wrong. I have learned recently about something called the DRY principle http://en.wikipedia.org/wiki/Don't_repeat_yourself
And it seemed like having the same code in five different places was a recipe for disaster. In ten years’ time you would end up with five wildly different sections of code all trying to do the exact same thing with varying degrees of success and giving different user experiences. I have even seen this within the same program – if you press the ICON then one screen pops up, if you took the same option from the drop down menu a different screen pops up, but both screens take the same data and then do the same thing.
So, I decided to extract the relevant code and put it inside a function module. Oh no! I hear you cry, not a function module. Anything but a function module, not the sonic oscillator! The reason people would get so upset is that surely after all I have said about OO programming I should be making a Z class?
Best Practice – Use Imaginary Tools, not real ones
The “funny” thing is that if I read the official guidelines from SAP I would hear “don’t do this, don’t do that” and yet there is no replacement. The most obvious example is – “don’t use a BDC use a BAPI”. OK, which BAPI do I use – there isn’t one! You see that all the time. Well goes the argument, write your own BAPI – which would involve direct updates to standard SAP tables. That is even worse isn’t it?
Just last week whilst I was having an internet argument with SAP guru Horst Keller – in song – he was saying don’t use SELECTION-SCREENS as they are old fashioned. I said I would be more than willing to use the alternative, what was it? He said there wasn’t one.
It is the same with the ever popular “the SAP GUI transactions will be replaced by WEB DYNPRO eventually”. Sounds fine but this is not a replacement as I define it as WEB DYNPRO runs in a web browser and SAP GUI runs on a desktop. I know, I know, I’m not supposed to be using a desktop - that is so last week.
Henry Ford said “if I had asked my customers what they wanted they would have said ‘faster horses’”. The difference is he did in fact HAVE an alternative, he didn’t just say “stop using horses”.
I suppose the idea of stopping enhancing the DYNPRO graphical screen painter all those years ago was to push people away from writing GUI applications. That was the approach with SAP workflow for a long while also, until the USA workflow user group forced SAP to take workflow out of maintenance mode and add extra features and the modern ABAP editor. I have no such illusions that the DYNPRO graphical editor will ever be improved.
Girls Just Want to Have Function Modules
Anyway, in the same vein, just as there is no replacement for SELECTION-SCREENS there is no replacement for CALL SCREEN either. The recommendation is to wrap the screen in a function module. That way if there ever was a new technology which ran in the SAP GUI – ha ha ha– then you could change the function and the calling program could stay the same.
If my example was more than just an interactive ALV report I would in fact wrap that function module in a class, so I could replace the function module call with a stub when doing unit tests.
Unscrambling an Egg
The next step would be to find the appropriate code in the existing program, and then move it inside a function module. Oh dear! That code just wasn’t in one place; it was evenly distributed throughout the program. This was a typical example of the function being welded into the program, some global variables used in the function at hand were also used for other things, and some routines used by the feature were also called by unrelated features.
That makes things a lot harder. So I left the existing program totally untouched for the moment, and started creating my function modules copying what seemed necessary e.g. the screen, assorted global variables for the screen, PAI / PBO modules etc. Naturally I followed the good old SAP recommendations to have no executable statements within modules, limit my global variables to what was needed for the screen etc.
So, in the end the new function module did not look much like the original code, but it did the same thing. I then called my new function module from the report I was adding the feature to. All was well. That was the easy bit. Now - how to unscramble the egg.
Everything’s going to be OK CODE
At what seems the right place in the original program I call the function module. Now it is time for Sherlock Holmes to find out what invisible things are getting passed to the original screen and what invisible things get passed back and used much later on.
The way this report worked was to put an ALV grid on screen 0100, and then you select one or more records and choose a menu command or ICON and 99% of the time another screen would pop up asking you something else related to what you were about to do. Screens need a global variable for the OK_CODE, so in this program such a variable had indeed been declared, called OK_CODE. It was used in every screen. I am sure you can see the problem coming … especially if you call three different screens one after each other. At least with a function module you are isolated from such things, you can control what gets passed backwards and forwards via the signature.
Just to make things even more funny, in the USER_COMMAND after the main screen, the OK_CODE was stored for posterity in another global variable called SAVE_OK. This I presume because OK_CODE will change after the next screen gets called.
Then we have in the USER_COMMAND
PERFORM call_up_xyz_screen USING SAVE_OK.
…. Which in the FORM definition becomes…
FORM call_up_xyz_screen USING ok_code.
Lovely. A parameter with the same name as one global variable, which actually refers to a different global variable. When the screen gets called the global OK_CODE changes, but not the OK_CODE variable within the subroutine.
In fact, after the call of the screen, which sets OK_CODE the calling subroutine cannot tell what the global OK_CODE has been changed to, as that value is masked by the local (parameter) variable with the same name. So the original programmer had created another global variable GL_CANCEL (I wonder what the L meant?) which gets set inside the PBO of the called screen if the user has cancelled.
This is why, to all the people who say calling variables PUD_OK_CODE or GD_OK_CODE or LD_OK_CODE is pointless, in OO world they are most likely 100% correct, but what about “legacy” programs like this which have to be maintained?
And this, your honour, is why I was up the lamp post with a traffic cone on my head. As I was doing my best to tidy up this indecipherable mess, I remembered the quote from Robert Martin, his “boy scout rule” – “always leave the code cleaner than when you found it”.
At that moment this seemed like the most profound wisdom in the universe, so I determined then and there to get that book. And then I went and ordered the wrong one. At least I got the author right.
The Clean Coder
There is one paragraph half way through this book which neatly summarises the core message. At the start of one chapter “Uncle Bob” wants you to imagine you are able to observe yourself being operated on by a surgeon.
The question is do you want the surgeon to behave like a calm professional, or to shout and scream and throw things and blame management for everything, and generally behave like a software developer?
The author’s position is that over the years programmers have given themselves a terrible image, and he says that generally this image is deserved, and his book is a series of things you can do about it so you end up acting like a professional, doing yourself and the whole trade a favour.
The Dirty Filthy Coder
Can this be true? Are all developers hopelessly unprofessional? Well, it’s a funny thing, but while I was reading this book it occurred to me that ordering the wrong book by mistake was in some senses “serendipity” – a happy accident.
Last Christmas it was the time of year everyone loves, performance review time. I wasn’t worried at all, thinking of all the wonderful new technologies I had introduced to our organisation during the year – ABAP2XLS, shared memory, BRF+ and a raft of other things which would not have seen the light of day if I had not gone investigating.
My boss summed me up as follows:- “technically you are brilliant - no one could argue. However one of the important things in our company is to have a professional attitude, an attitude you appear to totally lack”. Oh dear! Even if Bob Martin is wrong and most developers don’t have a reputation for being unprofessional, it is looking like there is at least one who does.
I’m Starting With The Man In The Mirror
There are lots of ways to deal with criticism. One way is to ignore it and say “it’s not me – it is everybody else, they all take things too seriously”. I didn’t think that strategy was going to work as well as it might.
OK, how to be more professional? The first thing I thought of was to stop calling all my colleagues / superiors and external vendors I came into contact with all the names under the sun. Its lots of fun, but some people get most upset.
After that I ran out of ideas, so it’s a good job I am reading a book on the subject. What can it tell me?
Bob Martin has clearly had an enormously successful career, but for the purposes of this book, he is writing an autobiography will all his successes glossed over, just concentrating on all the times he has stuffed up in the various jobs he has held. As might be imagined that is fascinating stuff, especially since he started programming in 1968 (the year I was born) so all this is mixed in with the history of computing, programming using punch cards and the like.
However as the examples came and went, all too often I thought to myself “oh no – I did that last year, and then blamed X for the project falling behind schedule”. So technology might change, but history is doomed to repeat itself.
An example is I keep forgetting not everyone has a (warped) sense of humour. Once a problem was reported to me whereby seemingly at random SAP transactions were failing during the night shift. While I was investigating the business analyst came to me and asked if I had any luck tracking down the problem. I said, deadpan, that my suspicion was the night shift problems were being caused by Jackie Wilson.
He didn’t get the musical reference, it was pretty obscure I have to admit, and off he went to report to the powers that be that we had found the culprit.
What’s this got to do with SAP?
To quote Edwin Starr – “absolutely nothing”. Or has it? Over forty years of programming he (Robert Martin not Edwin Starr) has worked on myriad different systems and in lots of different programming languages, but it looks like mistakes are “platform independent”.
So the programming language doesn’t matter. Though this book is bang up to date – it came out in 2011 and has reference to the recent Lord of the Rings films - I wonder if Robert Martin has even heard of ABAP - his language of choice is C++.
It is easy to fall into the trap of thinking that because the vast majority of large companies use SAP (e.g. SAP claim 75% of beer produced worldwide is down to SAP using companies e.g. Heineken) but I get the feeling that because the sheer volume of small companies where people program in Java or .NET or what have you, the amount of ABAP code in the world divided by the amount of code written in other languages may be a very small number indeed.
At one point Uncle Bob is talking about when he was a “kid” writing silly little games in interpreted languages. He says in interpreted languages like BASIC or LOGO you just add a line of code and then you don’t have to wait for the system to “build” you can execute the program straight away after adding your new line. That sounds familiar.
To quote from the book “but in real programming languages that kind of cycle time was absurd … in C++ we had build and link times that took minutes, sometimes hours…”
Just last week I had a friend tell me that not so many years ago his IT project took forever as every little change caused a complete recompilation of the entire system (I won’t say what framework but it is very famous) that took forever. So this sort of thing must still be going on. He was amazed when I told him how SAP development worked with everything in the database.
Robert Martin then discovers test driven development where you are forced to add small bits of code repeatedly and so he discovered “using this simple discipline I could code in real languages with the cycle time of LOGO”.
I can only presume ABAP must be an interpreted language as we don’t have to wait hours for the system to build after adding a line of code. However I never knew it wasn’t a “real” language. Still all that beer produced by companies using SAP is real enough, and that’s all that matters to me.
The Fit Ness Monster
Robert Martin and his son have developed a tool called FITNESSE which is described as an automated user acceptance testing framework. That made my brain melt at the start – how can you automate user acceptance testing – don’t you need actual users for that?
My experience of user acceptance testing involves sitting users down in front of the new system and then watching them ***** about it and ask for the legacy system back. In theory I could automate this by recording someone saying “that’s rubbish, get rid of it” and then playing it back whenever we make a change, but somehow I don’t think that is what is trying to be achieved here.
In C++ world they clearly use two different tools – one for unit testing, one for user acceptance testing. So I tried to jam the examples into ABAP world and after a while it all became clear to me.
ABAP Unit can handle both of these things. A unit test involves testing a small unit such as an individual method (or function module or whatever) and verifying that it works. This is aimed at programmers.
A “user acceptance test” is what Dan North would call a “behaviour driven development” test. This is the “given the user wants to do this” / “then when this button is pressed” / “a miracle occurs” format, where you test one large section of the program at once. This is more aimed at business analysts – in the book Robert Martin says that really this sort of test should be designed by the business people, or the business analysts at least, but in reality the developers end up writing these as well.
Tomato Sauce
One things I am going to have a go at from this book is the “PomadoroTechnique”. I have already ordered a wind up tomato online, and it is winging its way to me as I speak.
The idea is you need a device which can time 25 minutes and then make a noise at the end of it. My mobile phone could do that but it does not look REMOTELY like a tomato.
Spot The Difference
You are supposed to pick something to work on uninterrupted for 25 minutes, set your tomato for this time period, switch off your email, and off you go. Instantly your desk phone and mobile phone will start to ring non-stop, and everyone in the office, and even from the bus queue outside, will come to you one after the other, forming a huge line, all insisting they have a problem that you need to fix this very instant or the universe will come to an end.
I once got all the programming team t-shirts which said “let me drop everything and work on your problem” as that is what people expect, but in the tomato game what you are supposed to do is fob the people with problems off, saying you’ll get back to them when the tomato stops, and make a list of everyone you need to see / call back etc.
Then when the tomato ends you have to stop work on whatever it is you aimed for – instantly - (that is if you got round to starting) and then go and see everyone that bothered you straight away. This makes you more productive. Apparently some people measure their success by how many tomatoes they do each week.
Does that sound like fun? I can’t wait for my tomato to arrive, using a mobile phone or some sort of app on your computer seems like cheating to me.
We are all going to be replaced by Robots
The book ends talking about something I have heard of again and again. All throughout my career in IT, and all throughout Robert Martin’s, and he started work as a programmer in 1968 as mentioned before, assorted people have said “shortly you will not need code at all, you will just be able to draw a diagram and the code will be generated for you”.
I was born in 1968, so that claim was being made the day I was born, it was probably the first thing I heard just out of the womb, no wonder I started crying, and that claim is still being made today. Just look at all the adverts in magazines or online – they all say “with our product you can create (whatever it is) in minutes WITHOUT A SINGLE LINE OF CODE”. Hooray! I think the point being made is that if you are a programmer don’t hang up your hat just yet,
It is rather like the various places in SAP – HR & Variant Configuration for example – where someone has the bright idea to create a really cut down programming language so simple that business types can use it. Then customers start asking for extra features and they get added to these cut down languages until they become just as complicated as ABAP but different, and with less features.
Message in a Bottle
After digressing like Jock McDigressing, the digressing Scotsman, winner of the 2012 all Scotland digressing contest, it might be an idea if I mentioned some of the other things I found interesting in this book, in case you want to have a look for yourself:-
· He gave a list of technical terms that all programmers should know e.g. “Parnas Table”, “Conascence:, “Tramp Data” etc. I didn’t know any of them, as mydegree was in economics, and I only started reading up on computer science things after twelve years of programming for a living. Still, I looked those terms up on Wikipedia fast enough….
· An explanation was given for why Yoda said “Do; or do not. There is no trying”. When I first heard that in the film all those years ago I thought it was nonsense. Now I have heard a cast iron reasoning as to why saying to whoever is asking you to meet that impossible deadline “I will try” is a really silly thing to say,
There are also strategies for telling the powers that be when something is impossible in the desired time frame, naturally something they don’t want to hear, tips on doing time estimates (something I am hopeless at) …
…how to avoid meetings if at all possible, how to deal with other people (urrggh) and generally the whole thing is about how to do your job in such a way that people might actually one day start to take programmers seriously instead of just laughing at them. I’m sure that’s an achievable aim, but maybe I should have got a book on how to climb Mount Everest instead, that goal might be easier….
All in all thumbs up - I liked this book a lot; I can’t wait to read the one I actually wanted… then I shall write about that as well, and if it helps me in my day to day work. I am also in the new future going to be writing about how I find some free ABAP development tools you can get from a company called Hovitaga.
That’s All Folks
As I said earlier, I will start and end with a link to the Amazon entry for the Clean Coder book:-
Cheersy Cheers
Paul
20/06/2013 - Stop Press - My tomato arrived in the post today. I will let the world know how effective this is in real life.
21/06/2013 - It's now on my desk - picture below
04/07/2013 - I did my first "tomato" this morning, I think this is going to work really well.....
19/02/2014 - Look what I found in my system th other day. I fine example of what NOT to use comments for.
Further OO Blogs
- SAP Managed Tags:
27 Comments
| User | Count |
|---|---|
| 6 | |
| 5 | |
| 3 | |
| 3 | |
| 2 | |
| 2 | |
| 2 | |
| 2 | |
| 1 | |
| 1 |
