Or examples of projects that did things one way, but later refactored, and why they refactored.
the real meat of the matter comes when you are trying to make a change. is the structure robust? is there convenient tooling that helps you do what you need to do? does the system require extensive boilerplate to do simple things? does the system come crashing down in some unrelated area when you are trying to make simple changes?
it may be surprising, but large old codebases usually have huge hunks that serve no real purpose whatsoever except to glue together two pieces that would be much happier talking directly to one another.
I really wish as a community we could abandon the 70s business notion that software is a concrete artifact that one invests in and sells. its a really poor model. software is a process. code that is not being maintained is largely just dead. as developers we should be evaluating software as a living thing that responds to its environment...not as a shrink wrapped item we unbox and review on youtube.
And refactoring as almost always a must... unless you are stuck in a legacy support project where you are just hacking fixes away despite the glaring flaws and the client doesn't want to spend any more money on improving things.