I copy-paste the call stack from some important parts of the code and put it in a readme file. If I look back at it 2 years later, chances are I'll remind myself how the app works.
I don't mean stuff like onclick events that everyone can easily follow. I mean callbacks/events, interface implementations, code that creates new threads etc.
Also, if you have Visual Studio (Profesional or Enterprise, not sure, but either way, it's expensive), you can use the code map feature. Classes and methods can be drawn and drag and dropped using a Visio-like GUI. And clicking on the method jumps to the code. You draw a few of these diagrams and save them in the project and voila.
I am a big fan of puzzle solving. I said to people in my office that if they have a difficult bug that I'd try solving it.
I've seen a lot of bad code and I'm skilled at debugging realtime multithreaded apps. So, when you have a corporate app that runs many events in a short period of time, you have X different call stacks with ~10 functions and nobody can remember all that so I write down the call stacks I find potentially problematic. After that, I go through all the call stacks, sometimes it's the interaction between them causing the bug.
Here's a thing I like to do in a big project.
I copy-paste the call stack from some important parts of the code and put it in a readme file. If I look back at it 2 years later, chances are I'll remind myself how the app works.
I don't mean stuff like onclick events that everyone can easily follow. I mean callbacks/events, interface implementations, code that creates new threads etc.
Also, if you have Visual Studio (Profesional or Enterprise, not sure, but either way, it's expensive), you can use the code map feature. Classes and methods can be drawn and drag and dropped using a Visio-like GUI. And clicking on the method jumps to the code. You draw a few of these diagrams and save them in the project and voila.
I don't know if any other IDE supports code maps.
Fascinating, how did come up with such approach. It is quite intuitive.
I am a big fan of puzzle solving. I said to people in my office that if they have a difficult bug that I'd try solving it.
I've seen a lot of bad code and I'm skilled at debugging realtime multithreaded apps. So, when you have a corporate app that runs many events in a short period of time, you have X different call stacks with ~10 functions and nobody can remember all that so I write down the call stacks I find potentially problematic. After that, I go through all the call stacks, sometimes it's the interaction between them causing the bug.
Interesting, thanks for sharing your approach