Developers generally agree that code quality is a goal to strive for. Yet not all technology supports this ambition equally well.
As mentioned from the start, the business logic should be the main focus of applications. If changes in the business logic or new knowledge after working in the domain emerge, the domain model, as well as the source code, needs to be refactored. Iterative refactoring is a necessity to achieve and maintain high quality of the modeled domain as well as the source code in general. Domain-Driven Design describes this effort of deepening the understanding of the business knowledge.
A lot has been written on refactoring at the code level. After the business logic has initially been represented into the code and verified by tests, developers should spend some time and effort to rethink and improve the first attempt. This includes identifier names, methods, and classes. Especially, naming, layers of abstractions and single points of responsibility are important aspects.
Following the reasoning of Domain-Driven Design, the business domain should fit its code representations as much as possible. This includes, especially, the language of the domain; that is, how developers and business experts talk about certain features. The goal of the whole team is to find a uniform, ubiquitous language that is used and well represented not only in discussions and presentation slides, but also in the code. Refinement of business knowledge will happen in an iterative approach. As well as refactoring at the code level, this approach implies that an initial model won't perfectly match all the requirements from the beginning.
Therefore, the technology being used should support changes in the model and code. Too many restrictions become hard to change later on.
For application development in general, but especially for refactoring, it is crucial to have a sufficient coverage of automated software tests. As soon as the code is changed, regression tests ensure that no business functionality has accidentally been damaged. Sufficient test cases thus support refactoring attempts, giving engineers clarity as to whether functionality still works as expected after it has been touched. The technology should ideally support testability by not constraining code structures. Chapter 7, Testing will cover that topic in detail.
In order to achieve refactorability, loose coupling is favored over tight coupling. All functionality that explicitly invokes or requires other components needs to be touched if either of those change. Java EE supports loose coupling in several aspects; for example, dependency injection, eventing, or cross-cutting concerns, such as interceptors. All of these simplify code changes.
There are some tools and methods that measure the quality. Especially, static code analysis can gather information about complexity, coupling, relationships of classes and packages, and implementation in general. These means can help engineers to identify potential issues and provide an overall picture of the software project. Chapter 6, Application Development Workflows covers how to verify code quality in an automated way.
In general, it is advisable to refactor and improve the code quality constantly. Software projects are often driven to implement new functionality that generates revenue instead of improving existing functionality. The issue with that is that refactoring and improving quality is often seen to not provide any benefit from the business perspective. This is, of course, not true. In order to achieve a steady velocity and to integrate new features with satisfying quality, it is absolutely necessary to reconsider existing features. Ideally periodical refactor cycles are already built into the project schedule. Experience shows that project managers are often not aware of this issue. However, it is a responsibility of the software engineer team to address the relevance of quality.