Maintainability
15 items tagged with "maintainability"
Best Practices2
Hexagonal Architecture (Ports and Adapters)
An architecture that isolates core application logic behind ports, with adapters connecting external concerns like databases and UIs, so the core stays independent of technology.
Modular Monolith
An architecture that keeps a single deployable application but enforces strong internal module boundaries, capturing many microservices benefits without distributed-system complexity.
Anti-Patterns12
Magic Numbers
Unexplained numeric literals embedded in code, hiding their meaning and duplicating values that must change together.
Magic Strings
Hardcoded string literals that act as keys, flags, or identifiers, with no central definition, inviting typos and silent failures.
Long Method
A single function that does too much and runs for hundreds of lines, mixing many concerns and resisting comprehension, testing, and reuse.
Long Parameter List
A function signature with too many parameters, making calls error-prone, hard to read, and a sign of poorly grouped or missing abstractions.
Data Clumps
The same group of fields or parameters traveling together everywhere, signaling a missing abstraction that should be a single object.
Yo-Yo Problem
An inheritance hierarchy so deep that understanding behavior forces constant scrolling up and down between many classes to trace a single call.
Poltergeist
A short-lived, do-nothing class that only passes data or calls to other objects, adding indirection and noise without real responsibility.
Copy-Paste Programming
Duplicating blocks of code instead of factoring out shared logic, so every fix and change must be repeated across each copy, and some are missed.
Redundant Comments
Comments that merely restate what the code already says, adding noise, drifting out of date, and masking the absence of self-explanatory code.
Technical Debt Denial
Refusing to acknowledge or pay down accumulated technical debt, treating short-term delivery speed as if it carried no compounding cost.
Resume-Driven Development
Choosing technologies for their appeal on a resume or their hype rather than their fit for the problem, optimizing careers over systems.
Documentation Rot
Documentation that drifts out of sync with the system it describes, becoming stale and misleading until teams learn to distrust it entirely.