If one has a code base that's getting somewhat large, and one wants to do a review of all of the code, what's a good strategy?
In olden times I printed out all interesting parts on paper and took over a meeting room with its large desk for a day or two, but that's no longer an option. Also, that's too much paper.
@liw i don't think i've ever printed out the whole of a codebase, but i've taken a similar approach to big subsystems i needed to untangle.
render to pdf and read on your remarkable? ;)
@brennen I've thought about PDF on a reMarkable, but that brings up two issues: a) it's only one page at a time b) I don't have a tool produce a kick-ass PDF. I used GNU enscript in olden times, but it breaks pages in the middle of functions etc. That's OK on paper since I can just put pages next to each other, but it's awkward on an rM tablet.
But I may go that way if I don't find something better.
@liw my partner has a stand on her desk that supports 6 at once. it is completely absurd, but i am also a little jealous.
@liw (er, i guess it's only 4, but the side ones are vertical and there are two laptops plugged in, so...)
@liw Reminds me of how I tried to understand some legacy systems at work. What I did is read modules separately, and write summaries for them. That gave me an opportunity to look at the code closely, and also left me with a description of the architecture. Then it was easy to find worst modules (their summaries are impossible to write) and see where decomposition failed (parts of summaries repeated, or summaries were of vastly different lengths). Hope this helps!
Lars and friends