What to do before changing Code

[Florian]

Hi all,

Today I want to write about a theme everybody of us (the developers) gone through.

Creating and changing code. To be more specific, the part we are thinking that it drives us crazy while trying to refactor it.

Not because we are not having a transport or a technical documentation on hand. No, because our initial changes influenced further developing and now it is again on our turn, because we build the first things. If you took part in a developing (You thought: “Please, do never show up in my todo-list again”) it always returns a time to you.

That is an unwritten rule, is it?

But now, what can you do to improve it and reduce such messy work as a developer.

1^st point Do not be just a recipient

Might be a lot are now thinking: I’m a developer, so what, it is my job and if someone said it, I’ll get it done!

This is an argument and yes, I agree with you in a way, but not at all.

Of course, there is always this stuff which is really unnecessary and it has to be done. It remains in every project the same. People love doing things the same way they did before. So that is the reason for it and if it doesn’t affect SAP-Code I just let it happen. In these cases I see the great opportunities to develop from the very beginning and I can do it my way (the developing, the result is given from others :razz: )

But when it affects SAP or established source I always talk to the consultants and ask questions about it. It's not the goal to argue with the consultants, I want to understand what they are trying to have in the end and why the available stuff in the system doesn't match. You know, nobody knows everything.

2^nd point Bring people together

What does that mean?

If you got a concept in front, just read the given task. Take a minute to remember similar requests. You remember one, let both know each other (of course, they should work for your company). That’s it.

I got it more than one time, that similar request got different solutions. And most of the time, one solution is the better one. And if it is not better, it might be easier to implement…  Got the point :wink:

3^rd point Take your time to prove the concept

You passed the second point and it is something new, so most of our request start with a pre-technical concept (if not, there might be something wrong). This is a very important point to me. Take your time to prove the concept, of course the points above implement that in a way, but you have to develop it and you are the last one in the row. If you say ok, it is written in stone and it is a heavy lift to change the requesters (customers) mind again.

4^th point Expect the unexpected

A big problem is that some developers fear to ask questions. You know, you got the concept proved and now the developing starts and there it is. New questions appear out of it. Now it is not the point to hide behind your computer. Contact the relevant persons and tell them what’s going on. Nobody will kill you for asking the questions right now, but perhaps they will if you don't :smile:

5^th point Update the documents

A lot of requests doesn't match the concept in the end. You know, the consultant cross your way and during a coffee break another point is added to the request. Most of the times it isn’t a big story and therefore we (me also, I know that and I work on it) just implement it right after it and now it is gone. That’s the point, no it isn’t! Weeks later you get a question why something work like it does and not like that stuff written in the concept. If you’re lucky, you can remember more than just the good coffee, do you?

You see, it is a messy work but it's very important and if you’re a smart developer most of the time others have to do it.

You just have to handle it :wink:

6^th point Keep it simple

Plan your code before you write it.

That is the best way to see the full picture as far as you can and you are able to keep it as simple as possible.

If you think it is crux  you contact another developer around you and let him/her take a look at it.

I’m pretty sure there is most of the times an easier way to find :cool:

7^th point Don’t reinvent the wheel.

Many tasks you want to do have been done before and many of them are available prebuilt. That mean, before you work through a lot of tables take your time and search for helpful documents. The internet, SCN especially :wink: , older requests (if you got a ticket-system) might help you to save a lot of time.

Searching is the most undervalued timesaver at the moment. (But that is a personal statement)

Some words between
Now there are a few points which don’t match exact the timeline to do before changing code. But I felt to add these also here, so I just go ahead.

8^th point Know your tools

That mean, you need to use all the provided tools and plan the stuff you need to plan in the beginning. Unit-Tests / Codeinspector-Variants / Analysis-Tools / Breakpoint-Id’s / Test sets and all the stuff I forgot to mention here. So take your time to work through your tools and play with it. You will be very surprised what all is possible. I can’t tell you here, how often this happened to me in the past… and will in the future

9^th point Always be a hungry developer

Use your time and try out new things, it doesn’t matter if you need it right now. Read a lot and try things out. Just because you don’t need it right now, doesn’t mean you don’t need it next week.

10^th point Feel like the guy using your stuff

I know, it is a very global statement, but I think development improves by such thinking. If you like the feeling using it, I’m pretty sure the end-user likes it too. That doesn’t implement, to change essential things written in the concept. Just talk with the relevant persons about it and share your thoughts about the usability.

That’s it. I know, all the stuff I told here is not new, but it is very important to remember these. That’s why I shared the blog. At the moment I work through Managing Custom Code in SAP. A big thing is of course how to identify unnecessary or cloned code in your system.

The simplest possibility: Don’t create cloned or unnecessary stuff.

Thank you for reading to the end. Feel free to add points you think it is important or just leave a comment.

Cheers

Florian

PS: I'm not sure, if crux is a word, but I think you understand the meaning of it.

PPS: Thank you matthew.billingham for bringing that book under my pillow :smile: