Why Bad Code Happens and How to Fix It: From Naming to Design Principles

1. Root Causes of Bad Code

Common symptoms of low‑quality code include meaningless names, oversized classes or methods, duplicated code, unreadable logic, and difficulty modifying the code. The two most damaging factors are misleading naming and poor logical extensibility, which confuse newcomers and hinder development efficiency.

1. Manifestations of Bad Code

Examples include unclear names, huge classes or methods, duplicated code, hard‑to‑understand logic, and difficult modifications. The most impactful issues are names that do not reflect intent and logic that cannot be easily extended.

2. Problem Classification

Naming issues: ambiguous or misleading names for variables, methods, and classes.

Code‑structure issues: overly large classes or methods that increase complexity.

Programming‑paradigm issues: overuse of “transaction‑script” style, leading to “spaghetti” code.

Readability issues: lack of comments, inconsistent formatting, or excessive lambda usage.

Scalability issues: violation of the Open/Closed principle, making extensions hard.

Lack of design: missing abstraction, reusable templates, or factory patterns.

3. Root‑Cause Analysis

External factors: tight schedules, resource shortages, and urgent bug fixes. Internal factors: insufficient skill level, lack of pursuit of excellence, and missing feedback channels. The author emphasizes that personal standards and regular code reviews are crucial for improvement.

4. Methods to Improve Code Quality

The author recommends three approaches: domain modeling, design principles, and design patterns.

Analysis Phase

Before coding, analyze the purpose of the requirement and identify the core business entities (e.g., navigation bar and Tab).

Design Phase

Assign responsibilities to entities using design principles such as GRASP, ensuring high cohesion and low coupling.

Polishing Phase

Select appropriate design patterns (e.g., Subscriber pattern for Tab registration, Template pattern for processing flow) to implement the solution.

5. Role of Domain Modeling

Domain modeling helps simplify, unify, and guide design by mapping real‑world concepts to code structures.

1. Simplify Understanding

Visualizing entities and their relationships clarifies the overall business flow, making code comprehension faster.

2. Unify Understanding

Using a shared model eliminates language gaps between developers, product, and operations, ensuring everyone talks about the same concepts.

3. Guide Design

Domain models directly inform class design; each real‑world object maps to a class, each behavior to a method, and each relationship to an association.

6. Underlying Logic of Design Principles

1. SOLID

Single Responsibility Principle: a class should have only one reason to change.

Open/Closed Principle: software entities should be open for extension but closed for modification.

Liskov Substitution Principle: objects of a superclass shall be replaceable with objects of a subclass.

Interface Segregation Principle: clients should not be forced to depend on interfaces they do not use.

Dependency Inversion Principle: abstractions should not depend on details; details should depend on abstractions.

2. Why Design Principles Exist

They aim to achieve high cohesion and low coupling, reducing the risk and cost of changes caused by tightly coupled or poorly modularized code.

3. How to Practice

Understanding the underlying logic—identifying points of change and encapsulating them—leads to the use of design patterns that capture change.

7. Essence of Design Patterns

Design patterns provide reusable solutions for common problems such as varying implementations, abstraction layers, and multi‑tenant scenarios.

8. Case Studies

1. Shop Brand Query

Different platforms (Lazada, AE) provide distinct APIs. A simple interface leads to mixed responsibilities; using the Adapter pattern separates API calls from data conversion, and a multi‑tenant framework further isolates variations.

2. Shop Coupon Query

Modeling coupons as separate request and specification entities clarifies the domain, allowing clean abstraction layers and easier product‑level component reuse.