How to Write High‑Quality Code: Readability, Maintainability & Changeability Explained

In this training session I avoid discussing specific technologies such as Spring, Hibernate, or Ext, and instead focus on improving code quality by understanding its three essential attributes: readability, maintainability, and changeability.

Three Elements of High‑Quality Code

High‑quality code must satisfy all three criteria: strong readability, strong maintainability, and strong changeability.

1. Readability

Many developers write large, dense code blocks without comments, making maintenance difficult. To improve readability, avoid writing long code sections; split functionality into independent functions, add clear comments, and give meaningful names. Use responsibility‑driven design to place functions in appropriate classes.

/** * Initialize factory. Load data from XML file at the given path. * @param path XML file path */ public void initFactory(String path){ if(findOnlyOneFileByClassPath(path)){return;} if(findResourcesByUrl(path)){return;} if(findResourcesByFile(path)){return;} this.paths = new String[]{path}; } /** * Initialize factory with a list of paths. * @param paths array of XML file paths */ public void initFactory(String[] paths){ for(int i=0; i<paths.length; i++){ initFactory(paths[i]); } this.paths = paths; }

When reading others' code, large blocks without comments are frustrating. Refactor by extracting independent sections into separate functions, give them descriptive names, and place them in suitable classes based on responsibilities.

2. Maintainability

Maintainable software must adapt to various deployment and usage scenarios without hard‑coded values. Use relative paths, configuration files, or classpath resources instead of fixed absolute paths. Example: store log files or property files in configurable locations.

3. Changeability

Software should accommodate evolving requirements with minimal modification cost. Applying design patterns—such as replacing long if‑else chains with a factory, using the Strategy pattern, Adapter pattern, or Template pattern—helps decouple code and make extensions easier.

For instance, replace repetitive if‑else logic with a factory that maps keys to implementations, allowing new options to be added via configuration without changing existing code.

Other patterns discussed include Strategy (encapsulating varying algorithms), Adapter (isolating external system changes), and Template (defining a fixed algorithm skeleton with customizable steps).

Responsibility‑Driven Design and Domain‑Driven Design

Responsibility‑Driven Design (RDD) assigns behavior to classes based on their real‑world responsibilities, aiming for low coupling and high cohesion. Domain‑Driven Design (DDD) extends this by emphasizing a rich domain model that guides both analysis and implementation, ensuring the software reflects the problem domain accurately.

Key concepts include low representation gap (mapping real‑world entities closely to software objects), assigning responsibilities to the “information expert” class that holds the necessary data, and using GRASP patterns such as Information Expert, Low Coupling, and High Cohesion.