I am wondering what are the best strategies to read others' written code, especially when it is not well commented, or documented. Add to that if it uses libraries and technologies that are new to you.
I heard about what is called "reverse engineering" and that it could help tracking the code and spotting bugs. What you know about it and how could one improve his/her ability to make the best out of it?
For further actions, you may consider blocking this person and/or reporting abuse
Top comments (5)
If I'm in a lang with decent refactor tools and I find variables or methods with names that don't seem to line up with that the codes does I like to rename them in my local branch. It just takes out an additional layer of trying to mentally map between the names and the intentions of the code
Another thing would be to try and write some unit tests (if they aren't already there). When I don't understand what it is trying to do then write them without any asserts even, at that point it is a segregated sandbox for observing behavior
Have you seen
?
No, I haven't. But I will watch it.
Thank youπ
Reverse engineering usually refers to code not handed to us. When you have the code in your hands there is not any special strategy most of the times or it might be dictated by what we want to accomplish with it. Usually you can get a general sense of structure and what it accomplishes and than focus and understand the parts that are relevant to your task. Lots of times running it with a debugger and stoping at certain points to inspect variables helps in making sense faster.
When it uses libraries that are new to me I try to understand the purpose they serve and see how they are used within the code and read more about them from documentation or other resources and usually go as deep as to make me understand in order to complete my task. We can not really know the inner workings of ALL the libraries we use throughout our code.
Generally it tends to involve muffled screaming.. but for me it comes down to a couple of key approaches.
1) breakpoints. So many breakpoints.
2) comment the code yourself as you work through it.. if you can't work something out, leave a to-do and come back to it, but comment every live if you need to. Writing it down generally helps me get a grip in my mind of it.
Actually, my first go at it generally involves fitting it up on a closed test server and turning on a SQL trace and taking a look at the SQL that is hitting the database. From there I can generally understand a bit easier. Obvious exceptions of course