12 Surefire Ways to Write Unmaintainable Code

1. Over‑splitting microservices (one table per service)

Er Gou embraces microservice architecture and creates a separate service for every database table, believing this maximises independence and allows the use of the latest JDK 21. The resulting system contains dozens of tiny services, each exposing RPC interfaces. A new teammate must modify ten services for a small change, dealing with versioning, jar publishing, and environment conflicts, which leads to missed deadlines and a chaotic deployment order.

2. Refactoring without releasing to production

Er Gou adds a new logic branch and marks it with the comment "new logic" but never enables the corresponding feature flag in production. When the code is later modified by a newcomer, the flag remains off, causing the new code to fail at runtime and forcing the team to roll back and redo work late at night.

3. Writing megamethods (over 1,000 lines)

Er Gou believes that longer methods keep the coding flow uninterrupted and demonstrate skill. He never extracts helper methods, instead appending large blocks to existing ones. New developers struggle to understand these monolithic methods, leading to slow development and frequent misunderstandings.

4. Deeply nested control flow (10+ levels of if/try/catch)

Er Gou writes code with many nested conditional and exception blocks, proudly claiming the code has "high quality" despite its unreadability. New teammates are overwhelmed by the nesting depth and must repeatedly ask for explanations, often over a cup of tea.

5. Random, meaningless variable names

Er Gou treats naming as an art, using generic identifiers such as str1, list2, etc., without reflecting business meaning. Although he can remember them initially, after a month the names become opaque, making future maintenance difficult.

6. Writing misleading comments

When adding comments, Er Gou intentionally flips meanings (e.g., changing "is" to "is not", swapping unrelated notes) to confuse readers. New developers spend days trying to decipher the intent, only to discover the comments are deliberately wrong.

7. Never updating comments after code changes

Er Gou updates the implementation but leaves the original comments untouched, resulting in a mismatch between code behavior and documentation. New team members cannot rely on the comments and must seek clarification from Er Gou.

8. Blind copy‑and‑paste coding

Under time pressure, Er Gou copies existing code snippets instead of refactoring. This leads to duplicated logic across the codebase; when a bug is fixed in one place, the other copies remain buggy, causing repeated failures and overtime for newcomers.

9. Writing elaborate technical designs that are ignored in implementation

Er Gou spends weeks drafting detailed design documents and diagrams (e.g., a complex Redis‑based flash‑sale inventory system) but then implements a much simpler, low‑performance solution, leaving the documentation out of sync with the actual code.

10. Refusing to add any logging

Confident in his code, Er Gou never adds log statements. When a production incident occurs, the team lacks any useful logs beyond stack traces, leading to prolonged debugging and blame‑shifting.

11. Introducing heavyweight frameworks for trivial problems

Er Gou learns several rule‑engine frameworks (Drools, Avatior, SPEL) and integrates them to solve a simple strategy‑selection problem that could have been handled with plain code, inflating system complexity and steepening the learning curve for newcomers.

12. Reinventing the wheel for basic functionality

Inspired by open‑source heroes, Er Gou builds his own distributed lock using SETNX instead of using a mature library like Redisson. The custom solution introduces bugs, but Er Gou views the effort as valuable learning.

These twelve anti‑patterns collectively illustrate how poor architectural decisions, unnecessary complexity, and disregard for maintainability can turn a codebase into a "shit mountain" that hampers productivity and reliability.