Beauty of refactoring-opening part

Code refactoring has become a frequent issue. Since Martin Fowler's book refactoring, it has been around for ten years. Many programmers have become familiar with refactoring. However, whenever we face project pressure, we often leave the reconstruction behind and leave it out of the 9th cloud. There are enough reasons to explain: the function is not complete. Why should we rebuild it? The reason is that we have not considered refactoring as a habit. Even though many ides now support common refactoring Methods automatically, we will still forget and ignore them. Reconstruction cannot directly generate value, because we have not yet seen the beauty of reconstruction.

This column tries to re-launch the reconstruction flag to improve the existingCodeDesign, making restructuring deeply rooted in the hearts of the people, to a "hysterical" advocacy and shouting. Refactoring is not a trivial matter. If everyone can learn to use the tool of refactoring, the developer's living environment may become beautiful. Beautiful code, beautiful structure, and beautiful design are always so pleasing to the eye. We yearn for a beautiful environment, which is the result of nature; so, why cannot we create a beautiful code environment?

How to present the beauty of refactoring? The key is to find ugly and intolerable. Hate for ugliness is actually a powerful driving force that will drive you to use refactoring until it turns into a natural and indispensable breath. Reconstruction can be performed anytime, anywhere, without special stages. Regular refactoring ensures that the code is always updated, such as sharp. The masterpiece of Andy hunt and David Thomas 《ProgramThe path to practice is mentioned in the famous "Broken window theory ". Broken Windows represent poor designs, wrong decisions, or bad code. They think that "don't tolerate broken windows (don't live with broken windows)" and they need to repair it in time. It is also Andy Hunt's book practices of an agile developer. When talking about the good habits of efficient programming, he thinks that "it takes time and effort to keep the code Clean and bright ." Hunt's personal experience is that "in the project, the code should be brilliant, and there should be no darkness ."

Sincerely speaking!