Downloaded 15 times
Uploaded byChristian Drumm
The best debugging tool - your brain
The document discusses debugging techniques and emphasizes that the best debugging tool is one's own brain. It outlines several steps to effectively debug problems, including understanding available tools, thinking about the problem by considering things like error messages and software layers, debugging code as an experiment by designing tests of assumptions, and maintaining the right mindset. While debugging is not always easy, following approaches like these can help.
![谷歌留痕技术教程[ 𝙩𝙤𝙥 𝟮𝟯𝟯. 𝙘 𝙤𝙢 ]](https://cdn.slidesharecdn.com/ss_thumbnails/top233-260130173900-2eb784f9-thumbnail.jpg?width=640&height=640&fit=bounds)
The best debugging tool - your brain
- 1. THE BEST DEBUGGINGTOOL – YOUR BRAIN 12.09.2015 The best debugging tool - your brain | Christian Drumm | #sitWro 1
- 2. Debugging? 12.09.2015 The bestdebugging tool - your brain | Christian Drumm | #sitWro 2
- 3. Debugging is easy! 12.09.2015 Thebest debugging tool - your brain | Christian Drumm | #sitWro 3
- 4. 12.09.2015 The bestdebugging tool - your brain | Christian Drumm | #sitWro 4
- 5. Is debugging really thateasy? 12.09.2015 The best debugging tool - your brain | Christian Drumm | #sitWro 5
- 6. 12.09.2015 The bestdebugging tool - your brain | Christian Drumm | #sitWro 6
- 7. 12.09.2015 The bestdebugging tool - your brain | Christian Drumm | #sitWro 7
- 8. http://geekandpoke.typepad.com/geekandpoke/2012/06/abstraction.html 12.09.2015 The bestdebugging tool - your brain | Christian Drumm | #sitWro 8
- 9. Debugging is not easy!* *Atleast for all non-trivial bugs. 12.09.2015 The best debugging tool - your brain | Christian Drumm | #sitWro 9
- 10. How to debug effectively? 12.09.2015The best debugging tool - your brain | Christian Drumm | #sitWro 10
- 11. Step 1: Know yourtools. 12.09.2015 The best debugging tool - your brain | Christian Drumm | #sitWro 11
- 12. There is more thanthe debugger. 12.09.2015 The best debugging tool - your brain | Christian Drumm | #sitWro 12
- 13. Step 2: Thinking about theProblem… 12.09.2015 The best debugging tool - your brain | Christian Drumm | #sitWro 13
- 14. Which business process causes theerror? 12.09.2015 The best debugging tool - your brain | Christian Drumm | #sitWro 14
- 15. What does the errormessage tell me? 12.09.2015 The best debugging tool - your brain | Christian Drumm | #sitWro 15
- 16. Which system causes theerror? 12.09.2015 The best debugging tool - your brain | Christian Drumm | #sitWro 16
- 17. Which software layer? 12.09.2015 Thebest debugging tool - your brain | Christian Drumm | #sitWro 17
- 18. Step 3: …and thecode. 12.09.2015 The best debugging tool - your brain | Christian Drumm | #sitWro 18
- 19. Step 4: Debugging asan experiment 12.09.2015 The best debugging tool - your brain | Christian Drumm | #sitWro 19
- 20. 12.09.2015 The bestdebugging tool - your brain | Christian Drumm | #sitWro 20 Design experiment Debug & test assumptions Refine assumptions
- 21. <F5> vs. <F6> 12.09.2015The best debugging tool - your brain | Christian Drumm | #sitWro 21
- 22. Step 0: The rightmind set. 12.09.2015 The best debugging tool - your brain | Christian Drumm | #sitWro 22
- 23. 12.09.2015 The bestdebugging tool - your brain | Christian Drumm | #sitWro 23
- 24. Debugging is not easy!* *Butthere are approaches and practices to help. 12.09.2015 The best debugging tool - your brain | Christian Drumm | #sitWro 24
- 25. What do you think/ do? 12.09.2015 The best debugging tool - your brain | Christian Drumm | #sitWro 25
- 26. http://scn.sap.com/community/abap/blog/2015/09/09/the-best-debugging-tool--your-brain 12.09.2015 The bestdebugging tool - your brain | Christian Drumm | #sitWro 26
Editor's Notes
- #3 Why do I want to talk about debugging here?
- #4 Debugging is easy, right? Everybody knows how to do it!
- #5 Simply set a break point in your tool of choice, execute the program and you are debugging.
- #6 If it is easy why do even seasoned developers getting lost in the debugger, pondering over an issue for hours or days without being close to a solution.
- #7 CRM Problem I was working on recently. Context menu opens up in some search results but not in the agent inbox.
- #8 Think about a possible Fiori system architecture, SAP HANA XS in a side by side scenario (taken from help.sap.com) Different languages (HTML5, ABAP, JavaScript) Different protocols Different systems Different applications Different frameworks Different supporting processes
- #9 This is only on the highest level. If I dig deeper in a SAP system (at least the once I currently work with: IS-U and CRM) I usually get the feeling similar to the this comic.
- #11 The question is: How to debug effectively:
- #12 If we focus on ABAP : Different approaches for finding the source code where a message is raised Features of the new ABAP debugger Debugger variants Saving parameters for se37 possible to use as test data for unit test? Conditional break points and Watchpoints Debugger scripting ATC Read on SCN; try out what you read Similar for other languages
- #13 Recently I adopted the habit to reply to questions by colleague with a general response: Have you already searched on SCN and in the SAP support portal? In a lot of cases the answer is no. However, in my opinion searching for hints in SCN and the SAP support portal should be the first step whenever you encounter a complex bug. Although SAP software is highly customizable and probably no two installations are the same those searches usually result in valuable information. Even if you won't find the complete solution you will at least get information in which areas the cause of the bug might be. And last, but not least, also an internet search usually turns up some interesting links. Know how to search on the support portal Google
- #14 First step is normally to reproduce the error in the QA system. Once I’m able to reproduce the error I won’t start up the debugger immediately. Instead I start to reason about the problem. This I usually organize around some general questions.
- #15 What is the business process and the context causing the error? Do I understand the business process? Without this it might be really difficult to indentifiy a bug
- #16 In the case of a dump this is pretty easy. The details of the dump clearly show what happened and where it happened. in the case of an error message Is a long text with detailed explanations is available? Most error massages don't have an detailed description available. But if a detailed description is available it is usually quite helpful. Even the error messages without detailed descriptions can be very helpful. Learn the patterns in your application pattern "...<some key value> not available." or "....<some key value> is not valid." missing customizing. "The standard address of a business partner can not be deleted" problem in the process flow.
- #17 Not necessarily a trivial question Recall the Fiori architecture diagram Integrated CRM – ERP scenario
- #18 Once the system causing an error is identified, it is important to understand in which layer of the software the error occurs. each layer has different responsibilities provide the UI perform validation checks access the database) For example, in a SAP CRM application the error could occur in the BSP component building the UI, the BOL layer the GenIL layer the underlying APIs. Understanding on which layer an error occurs helps to take short cuts while debugging. If the error occurs in the database access layer it's probably a good idea to not perform detailed debugging on the UI layer.
- #19 After answering the question mentioned in the previous section I usually have a first idea in which part of the software the error occurs. navigating through the source code try to come up with a first assumption what the program code is supposed to do and which execution path leads to the error. first assumption what I would expect to see in the debugger Test my assumptions I have come up with so far. might not be sensible approach in all cases.
- #20 After all the thinking it is time to get to work and start up the debugger. I try to thinks about debugging as performing an experiment.
- #21 simply performing the business process that causes the error. Especially if an error occurs in a complex business process it might be better to find a way to test the assumptions without performing the whole complex process. execute the "experiment" in order to test the assumptions. This basically is the normal debugging everyone is used to. If the root cause of the problem is identified during debugging the cycle ends here. If not, the final step of the cycle is to refine the assumptions based on the insights gained during the debugging. On the basis of the new assumptions we can redesign the experiment and start the cycle over again. move forward in small increments. change to many parameters between to debugging sessions very difficult to identify the cause of a different system behaviour. E.g.error occurs during the address formatting for a business partner. first test the code for the address formatting with a BP of type person after that with a BP of type organization with the same address. This will enable to check if the BP type is part of the formatting problem or not.
- #22 In order to decide if to step into a particular function or method or to step over it I use a simple heuristic that has proven very useful for me: The more individual a function or method is the more likely is it to use <F5> The more widely used a function or method is the more likely is it to use <F6>. Using this heuristic basically leads to the following results: I will almost always inspect custom code using <F5>. the only exception is that I'm sure the function or method is not the cause of the problem. I will only debug SAP standard code if I wasn't able to identify the root cause of a problem in the custom code. I will basically never debug widely used standard function modules an methods and instead focus on new ones (e.g. those delivered recently with a new EhP). As an example consider an error in some SEPA (https://en.wikipedia.org/wiki/Single_Euro_Payments_Area) related functionality. When debugging this error I would first focus on the custom code around SEPA. If this doesn't lead to the root cause of the error I would start also debugging SEPA related standard functions and methods. If I would encounter function modules like BAPI_BUPA_ADDRESS_GETDETAIL or GUID_CREATE in the process I would always step over them using <F6>. These function modules are so common that it is highly unlikely they are the root cause of the problem. rare cases everything points to a function module or method like e.g. BAPI_BUPA_ADDRESS_GETDETAIL as the root cause of an error. check the SAP support portal first before debugging these function modules or methods. As these are widely used for quite some time it is highly unlikely I'm the first one encountering the given problem. Only if everything else fails I would start debugging those function modules or methods as a last resort. Different approaches: Look at the call stack first. Find the enhancements, Z-Implementations Binary debugging
- #23 SAP is not stupid nor mean What is the underlying reason for some code fosters better understanding Most important technique sometimes is to step back