Sharing: refactor and reason for rearchitecture)

People who have experienced rearchitecture reconstruction of a large scale know that rearchitecture is an extremely painful process.CodeIt is daunting to completely use the new architecture and rewrite the new technology. The most complicated thing is to sort out the business logic. If you have the energy to read the original code from the beginning, it is the most luky thing, but in most cases, you need to re-write the code written by others. Most people do not have the energy or are unwilling to read the code. Instead, they mainly rely on the requirement documents and use the old code to write new code. However, the update of the requirement document will never keep up with the code update speed. You have to look forward to the good habits of those who wrote the code and reflect the change requirements in the document, and the code has good comments. This is rare.

In addition, the rearchitecture takes a relatively long time, And the rearchitecture I have experienced is basically more than 30 months. In addition, most systems that require rearchitecture are important business systems. rearchitecture means that the business logic cannot have or the base cannot have too many changes during the reconstruction. This is also the main reason why many businesses are reluctant to support rearchitecture (because business functions are basically ineffective ). Most rearchitecture can be executed because it cannot be implemented without modification, or because it is unable to implement an important business function without modification, or because it takes longer and longer to implement business functions under the existing architecture.

After talking about the shortcomings of so many rearchitectures, we should explore why rearchitecture is required? What are the essential reasons? With this doubt, I recently read some Masters'ArticleThere are two points of view, which clearly explain the reasons for rearchitecture. One of them is the famous Martin Fowler. In his book refactoring-improving the design of existing code, he explained why refactor should be implemented as follows (p55 ):

"No refactor,ProgramThe design will decay (Note: This word is not translated, because there is a similar word behind it, turning it may cause ambiguity ). When people modify the code, the structure of the Code (modifying the code to achieve short-term business goals or modifying the code without fully understanding the existing design) is damaged. It is very difficult to understand the code design. Refactoring is somewhat like organizing code. Remove codes that are not properly positioned. The failure of the code structure will result in cumulative effect. The harder it is to understand the design of the Code, the harder it is to retain the design. The faster the decay is, the more frequent refactor can help the code to maintain its design"

Seeing this paragraph (it is better for you to look at the original text, it will be more original than my translation), I think Martin Fowler is very brilliant and in place. In the same case, Jaroslav tulach, netbeans's chief architect, has a more precise description (P100) in his book practical API design-Confessions of a Java framework Architect ):

"Degradation of the Architecture (this word is better than decay, I personally think it is more accurate than decay), that is, the beginning of each part of the code is talking with its unrelated parts, is inevitable. It will happen unless it is manually prevented"

Few original articles are cited as follows:

"The degradation of Architecture, Where each part of the code base starts talking to each other unrelated part,Is inevitable. It has to happen, unless explicitly prevented"

But Jaroslav tulach thinks the solution is module programming. This is beyond the scope of my discussion. I personally appreciate this sentence by Jaroslav tulach and recommend it to colleagues around me. I think it is more refined than classical Chinese. In addition, let's make a decision:Active Prevention. This sentence has become an important principle for me to consider problems and design solutions.

After understanding the reasons for rearchitecture, it is easier to solve the problem,Do some frequently RefactorCan Prevent ArchitectureDegradationOr codeDecay. There is a comprehensive description of how to refactor in Martin Fowler's book. Here I will mainly list the refactor opportunities:

• When added, refactor.
• When fixing a bug, refactor.
• Refactor when performing code review.

Finally, the refactor definition of Martin Fowler is listed:

• Refactoring (N): A change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior.
• Refactor (verb): To restructure software by applying a series of refactorings without changing its observable behavior.

Finally, I do not fully disagree with rearchitecture. rearchitecture is still required at the right time and in the case. However, as long as the above principles and practices are adhered, it can greatly avoid unprincipled and unpurposeful rearchitecture.