Codebase & Dependency Organization

A cache hit means the build system already ran this exact task before with the exact same inputs, so it reuses the saved output instead of redoing the work — like reheating leftovers instead of cooking again.

Because rebuilding and testing everything every time gets too slow as the codebase grows. Affected detection figures out which projects a change could actually break and only runs those, so a small change gets fast feedback instead of a multi-hour full run.

A CODEOWNERS file maps folders/files to people or teams. When a PR touches those files, the platform automatically asks the listed owners to review, and can require their approval before merge.

One place in the repo says "we use version X of this library" for everyone, so all teams building together use the same code and can't accidentally clash with incompatible versions.

A shell script rebuilds and tests every package every run, which gets slow fast. A monorepo orchestrator tracks changes and dependencies between packages, so it only reruns what's actually affected and reuses cached results for the rest.

It's called a 'diamond dependency conflict.' Two things your app needs each secretly need a different version of the same third thing, but most systems can only load one version of a library at once, so something has to give.

A lockfile records the exact version of every package (including indirect ones) that got installed, so everyone who installs later gets the identical set of files instead of whatever the version ranges happen to resolve to that day.

SemVer is MAJOR.MINOR.PATCH. 2.3.5→2.4.0 (MINOR) means new features were added, safe to upgrade. 2.4.0→3.0.0 (MAJOR) means something incompatible changed - your code might break, so check the changelog first.

An attacker publishes a public package with the exact same name as a company's private internal package. If a build tool checks the public registry and grabs whichever version looks newest/highest, it installs the attacker's fake package instead of the real internal one — no phishing or malware download needed, just a naming collision.

A direct dependency is a library you add yourself. A transitive dependency is a library that gets pulled in automatically because one of your direct dependencies needs it to work.

Code in the core business logic should not need to know about outer layers like databases or web frameworks. Only the outer layers should import and depend on the inner ones, never the other way around.

Public means any code anywhere in the program can use the class. Default/package-private means only code living in the same folder (package) can use it. Teams hide helper classes as package-private so other parts of the codebase can't accidentally depend on internal details that might change.

Split the module into two: a small public part other code depends on (the API), and a bigger hidden part with the real logic (the implementation). This lets you change the hidden part freely without breaking dependents.

Layer-based grouping sorts files by their technical role (all controllers together, all services together). Feature-based grouping sorts files by what business thing they do (everything about orders lives in one folder, everything about users in another).

It compiles, but the business-logic layer is now stuck to one specific way of talking to the database — you can't swap it or test the logic without the real database. Fix: put an interface next to the business logic and make the database code implement that interface instead of the other way around.