Personally, if I'm landed in front an application I haven't seen before and is complex, I like to get a debugger attached, put a breakpoint in the main method (or a controller action method) and then just step line by line, inspecting what changes and where the code goes.
It can take a while, but it means you are getting the literal truth of what the program does.
This approach particularly helps with badly laid-out code or 'lightly commented' code.
DevOps Engineer | Full Stack Developer | Building Cloud Native Apps | Working with Linux, AWS, Kubernetes, React, Node.js & TypeScript | Open to Remote Roles
Personally, if I'm landed in front an application I haven't seen before and is complex, I like to get a debugger attached, put a breakpoint in the main method (or a controller action method) and then just step line by line, inspecting what changes and where the code goes.
It can take a while, but it means you are getting the literal truth of what the program does.
This approach particularly helps with badly laid-out code or 'lightly commented' code.
Thanks for sharing. I too find myself doing this every so often.
I think a debugger is a defacto tool. Combining the awk / feel solutions with a debugger has a genuine benefit for everyone.