Hi, I spend most of my day trying to understand and simplify complex code with many moving and interdependent parts. My usual technique is to "rubber duck" by writing a mini essay to myself related to the code, or to try to step through the code, but I was wondering if anyone has some other techniques which I may find useful. Thanks in advance :)
Yes, many things here I should be doing more of, thanks:
(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
Yes, I do go through a debugger, but can be very tough to do sometimes when there are multiple concurrent threads/processes and execution divided between browser and server
What do you mean by moving and inter-dependent parts ?
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.
By moving parts I mean components in a system which change state, and communicate with other components. Anyway, yes, reading docs I guess is useful, usually out of date though. Yeah, good tips on trying to read the logs, to understand how the parts interact and get a mental model. Thanks for the tips
A common two-bird-with-one-stone approach of experienced programmers is
to rewrite the code to fewer lines, and to condense long-winded
comments. This not only aids understanding, but also imparts
ownership to the rewriter.
This approach often generates ill will, but eff them.
That's a good suggestion for small to medium codebase. In huge codebase, it's not feasible but explaining to others (like colleagues or interns or friends(oss repos not proprietary stuff)) usually helps me a lot.
Most colleagues (even developers) walk away in boredom as soon as the discussion gets too deep. I do understand though as they are happy to help me, but when it gets too deep they feel they are doing the work for me
Yeah, I've done this a few times, and it really helps with my understanding of the code. Often I have found that colleagues or managers view the time as wasted, and I get comments such as "Why did you waste time rewriting that code?", and my replies of "So I could understand it and make the code clearer at the same time" falls on deaf ears. But definitely a good technique, thanks for tip :)
Yes, I've started to do that more and it is definitely helping. Sometimes I need to also put things in an external Google Doc though just to explain how things fit together, or to explain certain abstractions with diagrams. Thanks
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.