How to Keep Code Clean During Rapid Java Backend Iterations

Hello, I am Su San.

Our project has been iterating intensely, with many teammates working on different features within the same micro‑service.

Because our commit policy requires a review step, I sometimes skim through others' pull requests and approve them without thorough inspection, especially when tasks pile up.

This leads to a gap between design and implementation, causing me to lose control over the service and constantly worry about potential production issues.

To address this, I now dedicate time to carefully review the code after a teammate submits a complete feature, record any issues, and discuss them with the author to ensure we share the same business‑logic understanding.

During this process I noticed inconsistent coding styles and various code smells, such as controllers handling all logic without separate service or DAO layers, methods with excessive parameters, and unnecessary code inside transactions.

These practices raise the question of whether the code truly has "technical depth".

Inspired by the "Boy Scout Rule" from the book *Clean Code*, I strive to leave the codebase cleaner than I found it—renaming variables, splitting long functions, removing duplicate code, and simplifying nested conditionals.

Improving code readability and maintainability is a continuous, professional effort, especially when multiple developers maintain a project.

I have been sharing resources on code style, standards, and refactoring with the team, including an article titled "Make Code Elegant: A Micro Refactoring Practice" from JD Cloud.

Readability of business code outweighs elegance; avoid flashy tricks in business logic.

The article demonstrates refactoring a bulky function into three dedicated classes, illustrating proper object‑oriented design.

The "broken window effect" in software means that low‑quality code, if left unaddressed, encourages others to adopt similar poor practices, eventually degrading the entire system.

Martin Fowler notes that refactoring consists of simple steps—moving fields between classes, extracting methods, or shifting code in inheritance hierarchies—but accumulated small changes can dramatically improve design quality.

By consistently applying these practices, we can keep the codebase clean, prevent technical debt, and maintain a high standard of readability.