From Code Design to Refactoring: Improving Code Quality

A programmer who aspires to write high‑quality code often wonders where such quality originates. Some argue it comes from good design, like a well‑planned building, while others claim it emerges from continuous refactoring as software inevitably changes. This article explores the relationship between design, refactoring, and high‑quality code through a concrete example: an image‑optimization tool used in a large‑scale information‑flow service.

Case Study – Image Optimization Tool

The tool transforms original image URLs into optimized ones by adding cropping and compression parameters. The workflow can be broken into three steps: verify the original URL against cropping rules, verify it against compression rules, and finally construct the new URL. Initial implementations relied heavily on nested if‑else statements, leading to tangled logic and high cyclomatic complexity.

if (necessary parameters are provided) {
    if (domain matches && meets cropping rules) { /* calculate optimal crop ratio */ }
    if (domain matches && meets compression rules) { /* calculate optimal compression */ }
    if (domain matches) { /* build new image URL */ }
}

When new domain requirements arise, the code quickly becomes unmaintainable. To address this, the article proposes several refactoring strategies:

Decompose complex conditionals into separate functions.

Replace conditionals with polymorphism by defining a Strategy base class and concrete strategy subclasses for each domain.

Apply the Strategy pattern to encapsulate algorithm variations.

Introduce a Template Method pattern to move common steps to an abstract class.

Consider the Template Method combined with Dependency Injection for better modularity.

These steps transform the tangled if‑else code into a clean, extensible design where adding a new domain only requires creating a new strategy subclass.

Six Pillars of Code Quality

The article outlines six high‑level goals for good code (functionality, durability, adaptability, non‑duplication, reusability, testability) and maps them to concrete practices:

Write readable code with descriptive names and appropriate comments.

Avoid surprises by defining clear contracts and handling invalid inputs.

Design APIs that are hard to misuse.

Modularize code, possibly using dependency injection.

Keep function signatures focused (e.g., remove unnecessary parameters).

Write testable code and practice one‑behavior‑per‑test.

Design Principles – SOLID

The SOLID principles (Single Responsibility, Open/Closed, Liskov Substitution, Interface Segregation, Dependency Inversion) are presented as universal guidelines, not limited to object‑oriented programming. Examples illustrate how each principle applies to the image‑optimization example, such as extracting domain‑specific logic into separate strategy classes (Open/Closed) and ensuring those classes can be substituted without breaking behavior (Liskov).

Design Patterns

Design patterns are described as concrete applications of SOLID in typical scenarios. The article mentions the 23 GoF patterns without detailing each, emphasizing that recognizing patterns helps solve recurring design problems.

Technical Debt and Code Smells

Technical debt is defined as short‑term compromises that increase future maintenance cost. The article distinguishes intentional vs. accidental and prudent vs. reckless debt, referencing the Technical Debt Quadrant. Code smells (e.g., “mysterious naming”) are presented as symptoms of debt. A simple example shows how renaming a poorly named function dramatically improves readability.

function getThem(list) {
    // ... unclear logic ...
}

Renaming to getFlaggedCells(gameBoard) instantly clarifies intent.

Refactoring

Refactoring is defined as improving internal structure without changing external behavior. The article stresses that refactoring should be guided by identified code smells and technical debt, using systematic steps to minimize risk.

Conclusion

The article ties together design, SOLID principles, design patterns, technical debt, code smells, and refactoring into a cohesive workflow for producing high‑quality software. By continuously evolving code through disciplined design and regular refactoring, developers can keep technical debt under control and maintain a sustainable codebase.