Level up your
code quality

Every piece of knowledge must have a single, authoritative representation in the codebase.

Recognize hidden duplication and choose the right abstraction to eliminate it.

How the Toyota 5S manufacturing philosophy maps to professional software craftsmanship — naming, organization, cleaning, standardization, and discipline.

Understand what a framework does before using it — read the source, not just the docs.

Apply the F1–F4 heuristics to keep functions minimal, focused, and side-effect-free.

Keep high-level policy separate from low-level detail, and ensure base classes never depend on derived classes.

Apply the same pattern everywhere, avoid conceptual clutter, and never couple unrelated concerns.

Follow team coding standards religiously and replace every magic literal with a named constant.

Build systems that compile in one step, run all tests in one step, and never lie through suppressed warnings.

Use explanatory variables, precise names, and a deep understanding of the algorithm to make code speak for itself.

A method that spends most of its time reading another class's data belongs in that class.

Make all dependencies explicit, and replace if/switch chains with polymorphic dispatch.

Eliminate excessive information, dead code, and vertical distance to keep every file easy to scan.

Put every function in the class most interested in it, and keep static methods truly stateless utilities.

Boolean and enum selector arguments obscure intent — split them into focused, well-named functions.

A curated catalog of code smells and refactoring heuristics drawn from Clean Code chapter 17.

Code that tries to be clever is code that fails to communicate — density and brevity at the cost of clarity are not virtues.

Tests passing is not the same as understanding — clean code requires you to fully grasp why the algorithm works before you commit it.

Never let a module silently assume a value from another — make every dependency explicit and declared in code.

Three Java-focused heuristics: avoid wildcard imports, never inherit constants, and prefer enums over integer constants.

Safely transform tangled legacy code by adding tests first and refactoring in small steps.

Write names that reveal intent, avoid confusion, and make code searchable.

Apply the N1–N7 heuristics to write names that are accurate, unambiguous, and searchable.

Code is the only source of truth — comments lie as the code evolves.

Objects hide data behind behavior. Structures expose data. Mixing both creates hybrids nobody wants.

Quality is a professional responsibility — not something you deliver when time allows, but the non-negotiable minimum of your craft.

A pure function always returns the same output for the same input and changes nothing outside itself.

Use the Single Responsibility heuristics to detect and split overloaded classes and modules.

Apply successive refinement to the SerialDate class — test, rename, extract, and simplify.

A case study in reading legacy code critically — find the smells before touching anything.

Kent Beck's four rules, in priority order, for a design that is always ready to evolve.

Functions should do one thing, do it well, and do it only.

Code formatting is a communication act — structure files so any developer can navigate them in seconds.

Start with working code, then refactor iteratively — never write clean code in one pass.

Third-party code belongs at the edge — wrap it so it never pollutes your business logic.

Master the red-green-refactor micro-cycle: write a failing test first, then only the code needed to pass it.

Apply the T1–T9 heuristics to write complete, meaningful, and maintainable test suites.

Fit more objects in RAM by sharing common state — separate intrinsic (shared) from extrinsic (unique) data to avoid duplicating heavy objects.

Traverse elements of any collection without exposing its internal structure — the client never needs to know if it's a list, tree, or graph.

Restrict direct communication between objects — force them to collaborate through a mediator to reduce chaotic many-to-many dependencies.

Capture and restore an object's internal state without violating encapsulation — implement Undo by storing snapshots of past states.

Let objects subscribe to events and be notified automatically — decouple event producers from consumers without either knowing about the other.

Copy existing objects without depending on their classes — clone complex configurations instead of rebuilding them from scratch.

Provide a substitute that controls access to another object — use for lazy loading, access control, logging, or caching without changing the real object.

Abstract data access behind an interface so your business logic never knows whether data comes from a database, cache, or API — and testing becomes a one-liner swap.

Ensure a class has only one instance and provide a global access point — but overuse creates hidden global state and makes testing painful.

Allow an object to alter its behavior when its internal state changes — replace state conditionals with polymorphic state objects.

Define a family of algorithms, encapsulate each in its own class, and make them interchangeable at runtime — eliminate conditionals by selecting behavior through composition.

Define the skeleton of an algorithm in a superclass, but let subclasses override specific steps without changing its structure.

Add new operations to an object hierarchy without modifying the classes — the visitor carries the operation, the elements just accept it.

Source code dependencies can only point inward — nothing in an inner circle can know anything about an outer circle, keeping the business core stable and reusable.

The database, web layer, and frameworks are delivery mechanisms — a good architect postpones these decisions and keeps business rules independent to avoid a costly technology marriage.

Tying business logic to specific I/O devices is a costly mistake — architecture should be agnostic to whether data comes from cards, terminals, files, or APIs.

Source code dependencies should point only to abstractions — Abstract Factories create the architectural boundary between volatile concrete code and stable policy.

With interfaces, architects make source-code dependencies point against the control flow, granting absolute power over module coupling.

Architecture is important but rarely urgent. Developers must defend good structure against short-term business pressure.

Entities hold critical business rules that exist across the enterprise; Use Cases orchestrate application-specific flows and are isolated from UI and database changes.

Functional programming disciplines assignment. Immutability eliminates race conditions, deadlocks, and concurrent update issues at the architectural level.

Design and architecture are the same thing — their true measure is the effort required to meet client needs while minimizing lifetime cost.

Split hard-to-test from easy-to-test behavior — the Presenter prepares all logic into a testable ViewModel; the View is a humble object that only renders what it receives.

The best architecture fails without disciplined use of access modifiers — the compiler is your strongest ally in enforcing Clean Architecture rules across the team.

Interface Adapters convert data between the format use cases understand and the format external systems need — boundaries are always crossed with simple DTOs, never raw entities or DB rows.

Don't depend on things you don't use — fat interfaces force unnecessary recompilation, coupling, and vulnerability to failures in unrelated code.

A good architect maximizes the number of decisions not yet made — separating policy from details so database and framework choices can be postponed until more is known.

Separate what changes at different rates — UI, application business rules, domain business rules, and database each change for different reasons and should be horizontal layers.

Subtypes must be substitutable for their base types — LSP violations at the architectural level force expensive special-case logic into the design.

Main is the dirtiest, lowest-level component — the entry point that wires all dependencies and hands control to the clean architecture above it.

Components should balance Abstraction (A) and Instability (I) — the Pain Zone (stable+concrete) and Uselessness Zone (abstract+unstable) are architectural anti-patterns to avoid.

Software artifacts should be open for extension but closed for modification — adding new behavior should add code, not change existing code.

OOP didn't invent encapsulation — C had perfect encapsulation before C++ and Java actually weakened it with header file requirements.

Group all responsibility for a clean feature boundary into one package — internal persistence and logic stay private, the compiler enforces what's visible to the rest of the system.

Group code by domain feature — top-level packages reveal the business, every feature is co-located, and searchability dramatically improves as the system grows.

The simplest code organization groups by technical layer (web/service/repository) — easy to start but hides business intent and allows accidental cross-layer shortcuts.

Full architectural boundaries are expensive — partial boundaries using Strategy or Facade patterns preserve future separation points without the full upfront cost.

The peripheral anti-pattern occurs when infrastructure code talks directly to other infrastructure code, bypassing the domain — like the Paris ring road, traffic flows around the city instead of through it.

Level is the distance from inputs and outputs — the farther from I/O, the higher the level. Source code dependencies should always point toward the highest-level, most stable policies.

Polymorphism lets you treat external dependencies — database, UI, I/O — as interchangeable plugins, making core logic device-independent.

The inside is the domain; the outside is infrastructure — outside depends on inside, ports speak the domain's language, and adapters translate between domain and external systems.

Tests don't prove correctness — they prove absence of known incorrectness. Good architecture produces easily falsifiable modules.

The three paradigms — structured, object-oriented, and functional — impose discipline by removing capabilities, not adding them.

REP groups classes released together; CCP groups classes that change together for the same reason — both mirror SRP at the component scale.

A component should be as abstract as it is stable — the most stable components should be pure interfaces so they can be extended without modification.

Your folder structure should reveal what the system does, not what framework it uses — a health system screams 'Health', not 'Rails'.

Depend in the direction of stability — a volatile component should never be depended upon by a stable one, or that stability is permanently compromised.

Services don't define architecture — a service with poor internal structure is just an expensive function call. True architectural boundaries can exist inside a monolith or across services.

A module should be responsible to only one actor — preventing changes for one department from accidentally breaking another.

Dijkstra proved unrestricted goto is harmful. Sequence, selection, and iteration alone are sufficient for correct, decomposable modules.

Tests are the outermost architectural circle — fragile tests that couple to implementation details make the system rigid; a Test API decouples test structure from application structure.

Software derives value from behavior and structure. A perfectly working but rigid system will fail when requirements change.

Use cases are vertical slices that cut through all layers — decoupling them lets each evolve independently without one use case's changes colliding with another's.