you can also look at a finite state machine. UML has interaction diagrams and/or state charts.
you can look at black box abstraction, try to separate the internal state from the external interactions.
I've also tried using a table to layout all the variations of the variables and what the output should be with "don't cares" to cut the options down.
you could always have chatgpt document the code and see what it says. it will probably be wrong but you never know.
(1) UML is something I haven't been doing much of, I will try to use some sequence diagrams and other things, that could be useful
(2) a table to layout all the variations of the variables and what the output should be with "don't cares" to cut the options down - I'll experiment with this
(3) black box abstraction - True OO I guess... I'll look into it
I've tried ChatGPT extensively, but it never produces anything remotely useful, since mostly I want to document the "why", not the "how" or "what", if that makes sense
Thanks for the input!
I read doc (if any), talk with different people, although it's none in my team (T_T), then identify different services or processes, read their logs a lot, then glance through code structure + file names, then put thread dumps, then somehow found it.
Then explore around something, add more logs or use a debugger - run it locally or on cluster, then speak with people - share my findings, then they'll ask few more questions or explore on their own - this will happen for a week.
This way you'll exponentially (whether you remember that info is a different topic) gain knowledge + faster turn-around time for any poc or incremental feature change.
Ultimately, everything is a kernel process with some threads running in it. So, yeah attack codebase in anyway possible.
This approach often generates ill will, but eff them.
Like talking to a duck.