3 ms·
Skip 1 and 2. 3 becomes the new 1. 2. Find an entry point. If it’s a CL find main and then where params are parsed. If it is a GUI or web app find a form or me
by JustSomeNobody 7y ago
Skip 1 and 2. 3 becomes the new 1.
2. Find an entry point. If it’s a CL find main and then where params are parsed. If it is a GUI or web app find a form or menu.
3. Don’t debug, READ the code and trace with pencil and paper for notes. If you’re debugging you’re not reading.
Wash, rinse and repeat a few times. Note all questions you may have.
Now go find a domain expert to answer your questions.
- jasonpeacock 7y agoYes, exactly this. I worked support for many years, fixing bugs in other developer's code. The most efficient way to find the problem and fix it is to find a string and start pulling it. Don't waste your time researching everything - you don't where that problem is yet. You're either starting from "when I try A, B happens, but I want C" or you're looking at "the logs show this error (or just stop after last successful action)". Use that as a starting place and follow it carefully until you get to the suspect behavior. Then start learning what's going and why it's wrong. Half the time, it's a red herring and you need to keep looking elsewhere. It's take some effort to put on the blinders and ignore everything else, and you need to be OK with not knowing how some parts of the system work. If you need to know it to fix the problem, you'll learn about it in the course of your investigation.