Hi all,
I just thought making a new blog about some good behavior when getting a ABAP-developer.
Ok, most of the points hit all developers, I think.
First I thought, maybe this is a blog for all the freshers out there, but when I was collecting the facts and what I think, everybody should do, I recognized, that I work through a lot of coding and it is more than just the new developers, which need to know that (again). No, I’m not saying, they don’t do so, but I think, some maybe have to get the focus on such points again, so that they (includes me, of course :razz: ) remember the facts.
Ok, let us have a look at the list.
Of course, everybody is invited to add additional points in the comments. A very cool thing would be, if we get a document in the end. I searched SCN, but all I found, was a lot of good content, but not a big guide or wiki.
1st of all, know your guidelines!
Make yourself familiar with the programming guidelines given you by your customer or company. Don’t mess up with the guidelines. I f there are rules in, follow them. It’s not up to you to change the rules. If there might be a mistake, and yes, there might be some, report them to the person, which is responsible for that. I’m sure, the person will give a hand and explain or change the rule.
The 2nd point is, introduce yourself to the consultants.
Make sure, you and the guys given you input talk on a same level. You can easily achive that, by repeating his concept in your own words and send it to the consultant. It confuses me everytime I see people developing things, which are not that, what the other side imagine. Make sure, that not you are the wrong guy in the chain!
The 3rd point: Be a smart developer and do not start coding as the world collides tomorrow.
Most of our developing will run for more than just a few months. Make sure, if you have to enhance or rebuild something, that you took the correct spots. You can easily prove the spot by searching SCN. If I wasn’t that sure, I found most of the times another, which get answered the question already. If not, be the first asking. By the way, talking to colleagues about things like that always helps and gives another perspective on it. Luckily I’m surrounded by some :lol:
The 4th point is, think about your developing twice.
Before starting, as mentioned above and afterward. It is not wasted time, to work through your coding again and make comments, where comments are missing. It is not a good programming style, to be the only one to understand what it’s going on inside. You will get in trouble if you do so, for sure!
Use variables, that speech to the people and saying things like that:
“Hi, I’m Mr. Table, I store the dataset, which is used for proving the orders”. (Ok, I'm a bit silly at the moment, you know what I mean :razz: )
5th Use good technics inside your written code
Today it is more and more important, that we have to make a cut between the view and the coding itself. Use the Patterns and technics which people teached you. MVC is a big thing right now and it might be more important than ever before. What technics to prefer and stuff like that, I (we) can’t just summarize in such a few sentences here, that’s why I’m not trying it.
6th Use the codeinspector!
This is the easiest way to prove the coding. Back to the 1st point. Use it, if there is a profile in the system. If not, ask the author of the guidelines, why there isn’t one. If there is none, use the default variant, better use that one, than not using it at all.
The Codeinspector helps to make everybody’s development saver and easier. Again, use this awesome feature ➕ . If you got a newer release, there might be the ATC (ABAP Test Cockpit) available. But that would be too much at the moment.
7th Implement unit tests if possible
You know, unit test might be a messie work at the moment :cry: , but there is no program, which is guarded against changes. Most of the developing lives and the customer/users get new ideas, what they want to do with it. So the unit-tests help you right at the moment not that much, but if the object returns,
you needn’t to fight what done earlier, just press the button and see, if all scenarios work fine, after developing new cases with it. (That is another big story to tell, there are a lot out there, perhaps I bring another to the binaries, someday :wink: )
8th Make performance tests.
Don’t just say yourself, it’s working with my data. Think about the scenarios hitting your coding in productive areas. Make sure, that you tested or better told other to test your developing in different scenarios. You are the developer and you know the critical things inside. So do not leave them alone, make it public and tell the people what they have to focus in your eyes.
9th Don’t waste too much time with a technical documentation.
Only waste time with TDs if your're going to make AWESOME ones
Give the result to another developer and just let him look at it for 10 minutes. It just should be a feeling, if it is understandable what you are doing there. It doesn’t matter if he can understand everything, but the feeling should be there. When writing the technical docu remember this blog here:
Stop writing Technical Documentation nobody will ever read
We discussed about it in the office and yes, he is absolutely right.
As usual, a question in the end:
Who knows, when working through the guidelines of your company last time. How often is this document updated? Is there also a styleguide included?
Thanks for reading to the end. If I'm wrong with a point, let me know and I can rethink it.
Regards
Florian
PS: It just popped up in my mind, so I added the Star Wars picture*haha*
18.02.14: Updated point number 9 out of the comments. I agree with mauricio.cruzand bruno.esperancathat the mentioned description gives a better clue, what is meant
- SAP Managed Tags:
104 Comments
| User | Count |
|---|---|
| 5 | |
| 3 | |
| 3 | |
| 2 | |
| 2 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 |
