I attack it pretty much the same regardless of language or project. Generally, I start with the product, see how it works, find the 3-4 most common workflows and get a handle on them.
Then I like to check out the database (or algorithms & data structures if no db) and see how data is stored and manipulated, usually tells you a lot about choices that have been made.
Then open the project(s) and trace those 3-4 workflows once I understand it from the top level workflows. Part of this is also of course, getting the project(s) loaded and building locally as needed also reviewing tests, CI/CD, dependencies etc.
Lately, I've used Claude Code to help me with this, have it build a function map or class map and have it breakdown key insights about the code and trace those few workflows for me that I then validate. My process is pretty much the same just Claude does a lot of the initial lifting. I'll also dump the entire DDL for most databases (if they are more then a few tables) and send it to Claude and use that as a way to look for patterns/issues etc. For older monolith apps I've had to break the DDL into chunks sometimes just because some of these older apps have a very large number of tables/indexes/constraints etc that have been added over the years. Same thing works for json stores too fwiw.
GPT + Grok (sometimes Claude) for writing docs, policies, requirements, client responses etc. Grok is often times more concise/direct, which helps me as I tend to be verbose. I always review/edit regardless. Much faster than writing from scratch, and combining responses on the same topic is sometimes best.
Copilot for code completion + reviews or small snippets/functions but larger code/module generation has been weak so far.
Claude for full modules generation or complex multi-file edits.
Research: Grok (less filtered + better search), Claude (complex dev topics), GPT (balanced but sometimes slanted and/or seems to favor certain sources).
My Teams: Mostly Copilot for code completion/reviews, mix of GPT/Claude for code. Last year was loose/experimental to learn but we plan to formalize guidelines more this quarter.
Definitely a ton of hype that doesn't always match reality, but it is a super powerful tool that really has made things move faster.
Very fair and very true, and I am 100% in agreement with your points, I do not know of a single resource we can go to as an educational toolset that is based on real world products/experience. The problem is the industry as a whole is locked into these NDA type agreements (along with proprietary information) which prevent a lot of the complete schema sharing etc which would help people learn the best.
That said, some of the best things to look at are open source projects and research their pain points and highlights. That will many times point you to the tradeoffs they made in modeling and in code. For e-commerce things like magento and other open source solutions can be really informative, even woocommerce and how it shoehorns itself into wordpress can be informative as to the tradeoffs on highly normalized vs lightly normalized vs key/values etc.
Kinda tough to give a good answer without more context, IMO. What I mean is that a good e-commerce schema that serves a single small store and runs off a single database server would look quite different then a multi-tenant or distributed data store for a e-commerce site at scale.
The one you linked is a pretty typical relational model and isn't bad, but it has trade offs that I'd personally not make, however, that doesn't make it bad.
In the end context, scale and usage all determine a good schema design. Sometimes what would be a good relational design on paper would be tragically horrid in practice once you get beyond a small dataset.
Then I like to check out the database (or algorithms & data structures if no db) and see how data is stored and manipulated, usually tells you a lot about choices that have been made.
Then open the project(s) and trace those 3-4 workflows once I understand it from the top level workflows. Part of this is also of course, getting the project(s) loaded and building locally as needed also reviewing tests, CI/CD, dependencies etc.
Lately, I've used Claude Code to help me with this, have it build a function map or class map and have it breakdown key insights about the code and trace those few workflows for me that I then validate. My process is pretty much the same just Claude does a lot of the initial lifting. I'll also dump the entire DDL for most databases (if they are more then a few tables) and send it to Claude and use that as a way to look for patterns/issues etc. For older monolith apps I've had to break the DDL into chunks sometimes just because some of these older apps have a very large number of tables/indexes/constraints etc that have been added over the years. Same thing works for json stores too fwiw.