Reconstruction with JBuilder 2005 realization of Reconstruction

Why do you want to refactor

From Martin Fowler's "refactoring-improving the design of existing code" for two consecutive years to become one of the best-selling computer books, you can understand the degree of joy of refactoring to the programmer.

So what is refactoring? Refactoring is to improve the software quality and performance by adjusting the program code without changing the existing function of the software, so as to make the program design mode and architecture more reasonable, and improve the expansibility and maintainability of software.

One might ask, why not spend more time at the beginning of the project to get the design done, and then take the time to refactor it later? It is not possible to know a design that is perfect enough to foresee any change in the future, or a design that is flexible enough to accommodate any expansion. System designers on the upcoming projects are often only to be controlled from the general direction, and can not know each detail, followed by the change is never changed, the user often put forward in the software after the formation of the beginning to "comment", system designers are not the foresight of the immortal, The change of function leads to the adjustment of the design again unavoidably. Therefore, "testing for the first, continuous reconstruction" as a good development habit by more and more people, testing and reconstructing like the Yellow River dike, to ensure the quality of the software magic weapon.

By refactoring, you can achieve the following goals:

• Continuous bias correction and improved software design

Refactoring and design are complementary, and they complement each other in design. With refactoring, you still have to do the advance design, but do not have to be the optimal design, only need a reasonable solution is enough, if not refactoring, program design will gradually corrupt deterioration, more and more like Broken kite, runaway Mustang can not control. Refactoring is just sorting through the code, allowing all code with divergent tendencies to return to standard.

• Make the code easier to understand

Martin Flower has a classic in refactoring: "Any fool can write a computer-understandable program, and only a program that is easy to understand by humans is a good programmer." "In this, the author is very deep, some programmers are always able to quickly write the code can be run, but the obscure name in the code makes people dizzy need to hold the arm of the chair, imagine a recruit to take over such code he would like to be a deserter?

The lifecycle of software often requires a lot of programmers to maintain, and we tend to overlook these up-and. To make your code easy for others to understand, you need to do a lot of extra things when implementing software functionality, such as clear layout layouts, concise notes, and naming is an important aspect. A good way to do that is to use metaphor to name that is, the function of the object to achieve the basis of the use of figurative or personification of the name, a good attitude is to each code elements like a newborn named, perhaps the author a bit of the tendency to name paranoia, such as to honor this nickname, will be deeply fortunate.

For those who are full of confusion and even misleading naming, need to decisively, drastic plastic surgery, never mercy!

• Help to uncover hidden code flaws

Confucius said: "Wen is aware of the new." Refactoring the code forces you to deepen your understanding of the code that was originally written. I often write down the program, but it happened to their own procedural logic is not very understanding of the scene, had this horror, and later found that this symptom is incredibly many programmers often suffer from the "cold." When you do this, refactoring your code can deepen your understanding of the original design, uncover the problems and pitfalls, and build better code.

• In the long run, help improve programming efficiency

When you find that solving a problem becomes extraordinarily complicated, it is often not the problem itself, but the wrong way, and poor design often leads to bloated coding.

Improve design, improve readability, reduce defects are to stabilize the ground. A good design is half the success, and stopping to improve the design by refactoring may slow it down at the moment, but the advantage it brings is not underestimated.

When to start refactoring

The new broom started a brand-new project when the three fire programmers often will also ignite three fire: the intense, foot hoof, overtime, a mammoth thousand Army million "code" clip wrapped in the programmer's passion and the make its debut of the keyboard struggling to move forward, irresistible, siege-swept land, directly to the "Huanglong mansion."

Development Manager is this a vast soup code team commander, he is responsible for the fate of this team, when Ziheng Park stood on the top of the mountain to see the troops of the training team uniform forward, he lamented that "I have such an army where still afraid of No victory?" "。 But unfortunately, your hands of this team originally just stragglers, in the forward recruitment, and constantly grow, so the team deformation inevitable. When the development manager finds that the team is deformed, it may be to restrain the temptation to conquer the hills ahead and to stop and reorganize the team.

Kent Beck puts forward the phrase "bad Code", which is the same as the "Team Metamorphosis" We put forward, and what is the signal of the team morphing? The following code symptom is a strong signal of "Team Metamorphosis":