I really appreciate the recommended reading order mentioned in the repository. Many times when looking at a repository as a learning resource it can be pretty daunting to know where to start, so I'm glad to see that in the readme.
Out of curiosity and for possible discussion, do you have any hard and fast methods for approaching a medium-to-large unfamiliar codebase?
In the past, I've tried looking in the past of the repo and trying to make maps of the dependencies between different files over time, to better understand which classes or types are the most widespread. In dynamic languages, I really don't know how I'd start, I'd probably just see how it's invoked and start depth-first from there.
For database-driven applications, that means, read the DB schema first. For everything else, look at their in-memory equivalents.
"Show me your flowchart and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won't usually need your flowchart; it'll be obvious." -- Fred Brooks, The Mythical Man Month (1975)
"Bad programmers worry about the code. Good programmers worry about data structures and their relationships." -- Linus Torvalds (2006)
It depends on the type of app. If it's a rails app, I usually start with user.rb or whatever the equivalent is (account.rb or something) as those usually have most of the functionality. From there, I'll either look start looking at routes config and going from there or some of the base controllers to get a sense of things (i.e. ApplicationController or maybe AuthenticatedController).
For non-rails web apps (and rails apps), I'll usually find a portion of the UI and just start tracking from the front-end to the back-end. Something like finding some text on the page, and trying to reverse back to where that particular piece of text was defined and what steps it took to get there (which view, helper, controller, etc.)
For non web-apps, I don't have any good techniques, unfortunately.
If it's a popular library, I also go to github and search for "import <library name>" and go to the code results, and look at a few examples of files from different projects that use that library to see how it can actually be used
I recently gave a talk at RailsConf that might interest you. I stepped through some ways to make a code base "auto-document" itself - including Swagger/OpenAPI, end-to-end code and data flows, and database schema. The talk is available as a 4-part blog series, starting here - https://dev.to/appland/we-need-a-better-way-to-communicate-a...
