Reflections on the scope of application of "reconstruction"

"Refactoring" a very good writing, let me greatly broaden the train of thought, realize that the revision of the code is a quantifiable, repeatable process, the software industry, the most lack of seems to be quantifiable and repeatable process.

However, similar to most of the books on methodology, the book does not discuss the scope of refactoring, nor does it evaluate the role and status of refactoring in real-world software coding work. Of course, perhaps these two issues are too broad and not easy to make the next conclusion. This article hopes to discuss the scope of refactoring and the location of refactoring in the process of software development.

　　Here's a thought about the restricted scope of refactoring:

1. The reconfiguration of the local code and the reconstruction of the design are two completely different fields. Although the large-scale reconfiguration of the code will affect the design, but this is the indirect impact. The reconstruction of the design directly includes the key parts of the system, such as the refactoring of API contract, domain model, database schema, etc. "Bupobri". There is no good solution to the problem of how to reconstruct the design.

Corollary 1: The refactoring of local code cannot be confused with refactoring for design, especially if you can't do these two things at the same time, or software development can get out of control quickly.

2. The reconstruction environment before the release of the program is completely different from the reconstruction environment after the release of the program, and basically everything can be reconstructed before it is released, including the overall structure, the interface, the service layer API, the database schema, and the micro part Code improvement, etc. But when the program is formally provided to the user, the difficulty of the interface and database reconstruction increases immediately. Most of the time, for a number of non technical reasons, these two refactorings are impossible. For example, the user does not want any changes to the interface, unless the interface itself is unable to meet his needs. Database refactoring can cause inconsistencies between historical data and new database schemas, and the risk of migrating data is often not acceptable to users.

Inference 2: After product release, it is difficult to refactor the interface and database schema (including entities).

3. According to experience, if you try to replace the prior design with refactoring, the cost of refactoring increases with time (or even exponentially), and often the cost of refactoring is greater than simply modifying bugs. A better idea for refactoring and design is to try to make a good design before writing the code, and then use refactoring to solve the remaining design errors in the coding process. The key here is to allocate the time ratio between design and refactoring to achieve maximum input/output balance.

Inference 3: Refactoring is a complement, not an alternative, to the design of the advance.

4. When the refactoring does not have a quantified standard, in accordance with the law of diminishing marginal value, endless refactoring will increase the cost.

Corollary 4: When a "programming hat" can be easily worn on the head, there is no need to continue refactoring. If you still don't see how to take the programming hat with you, continue refactoring.

　　Here is a simple summary of what is appropriate for refactoring:

1. Improve the design within the API.

After an API is published, it is often difficult to refactor its signature, and refactoring can be used to improve its internal design.

2. Code review, improve the quality of local code.

Once you have found the bad taste of the local code, you can use refactoring to modify it locally.

3. Before adding new features, organize the old code.

Add new features, if you need to reuse some of the previous functions or code, you can use refactoring to make the original function or code more suitable for reuse, and then write new code.

4. In the design encounter difficulties, you can consider the use of heavy refactoring to improve the previous design, and then add a new design. Heavy-duty reconfiguration includes interface reconfiguration, API reconfiguration, domain model reconstruction, database schema reconstruction, heavy-duty refactoring is destructive, especially the internal and external continuity of the system, which is very different from the ordinary local reconstruction, so use caution when using.