Documentation in ABAP
Hi readers of pieterverstraeten.com,
All SAP BI developers know that you can’t develop a good BI solution without ABAP. But when the developer has a lot of code been written in the system, other consultants (and the client itself) cannot easy identify what kind of functionality is implemented. During the years several consultants will touch the same code but in the end no one knows which updates and modifications were done. Of course, the documenation on the sharepoint or shared drive will never be updated and consultants will leave the company. Conclusion, what the hell does this code do???
I think that everyone knows the solution, document your code in ABAP itself, write comments in the code to clarify what you’re doing. It would be nice if every consultant will do this :-). I’m not an expert in ABAP, but the tip below will explain you how to implement a header to store all changes in the ABAP code.
Example of the header:
To save time, you can reuse this header in the future, save it as a pattern in the ABAP editor. Go to transaction SE38 and create or change a program. Then select from the menu “Utilities –> More Utilities –> Edit Pattern –> Create Pattern“. Insert a name for the pattern, e.g. HEADER, and insert the header information (of course without the author filled, date filled, etc.). Save the pattern.
If you’re working in a transformation, how to get the pattern? Click the “Pattern” button in the left upper corner, select the “Other pattern” bullet and find the pattern that you saved. The header information will be inserted into your code, update the header information continuously when the code will change. Developers are always up to date what kind of changes has been done in the code.
Between the code you can also insert comments to clarify the details, like:
When SAP BI consultants always use this kind of methodology of documentation, clients will be happy and consultants that will edit the code after you left the firm will also be happy! This will make our life much easier!
Hi Pieter, good point! But there are two sides to the story. First and foremost, yes a good developer/consultant should document his/her work properly. Secondly, organizations should have a clear set of house rules to which (external) developers/consultants should comply. What should be described? In which format? Where to store the documentation? Etc. In fact these house rules should act as a set of acceptation criteria before discharging the developer/consultant from the project. So, there is a mutual benefit but also a mutual responsibility for organizations and developers/consultants. It takes two to tango!
Hi Dino, I totally agree with you. On the customer side everything needs to be in place and consultants need to take their responsibility to write their documentation :-)