Why does software development need to be refactored?

Here's an example. Suppose there are 10 points to consider when building a complex system. Due to human limitations, you will definitely get 6 of them wrong, and of course these 6 points will not affect the release of the first version. Then, how do you correct these 6 points?

You can't rewrite the system. Because of rewriting the system you will also get 6 points wrong, although it may be a different 6 points.

You can't fix these 6 points while adding system functions, because adding one function will add another 5 points to consider, for example, and you will make 3 points wrong in the process.

When you don't add new features and try to fix one or more of these 6 points, the process is refactoring.

Refactoring doesn't guarantee that it won't break the 4 points you got right, but you can at least be sure that the error was caused by your refactoring and not for some other reason (such as the new 5 points added in Option 2). And it's also encouraging you to try to fix only one mistake in the third option.

You'll never get exactly 10 points right, even if you have infinite time to restructure. In fact, your refactoring is always competing for resources by adding new features.

Because of point 5, you don't refactor for no reason unless you need to add new features. However, due to point 4, it cannot be done at the same time as the addition of new functions.

When the ** of human civilization accumulates to a certain extent, we no longer need to write new ** (or only need to write glue**). Programmers at that time would have been called archaeological programmers (because they were always refactoring what had already been created). Refer to "The Abyss".

Refactoring isn't a complete reinvention, and the original design isn't useless.

Software development is a process, and the people and environment of software users may change in the process, and some assumptions and conditions in the original design will change, which needs to be adjusted according to the new situation. Refactoring is the redesign of the level, the implementation of the software, the design is adjusted, and of course it must be adjusted.

Reconstruction is also the improvement of the original, eliminating the rancid smell in the first, making the first more robust, more efficient, and easier to maintain. This is determined by the laws of software development, and no one can write a perfect ** at the first time.

Refactoring is necessary to improve the structure of the project. Refactoring is generally an improvement of the already written project, this process does not modify bugs, does not add new features, but can improve reusability, extensibility, and make ** more readable.

That said, refactoring is not necessary. And the cost of refactoring is also relatively large, and the general process is relatively long.

My answer probably has nothing to do with refactoring, but the two guidelines I personally agree on when it comes to program development are"iterate" + "dry".Starting from these two criteria, refactoring is to adjust the structure of the program through a continuous iterative process, eliminating the ** and construction of repeat yourself.

1.It needs to be refactored, looking at a lot of repetitive **, inelegant designs, etc., I really want to change him, for fear of being embarrassed to stay.

2.Willing to refactor, refactoring requires an investment of time and effort, and that requires our determination.

PS: This is the case with a recent project, and it was also the first project I did, which was very tangled.

The house needs to be cleaned when it is messy, there are more files to be organized, and more functions need to be reconstructed.

This concept is common in object-oriented programming languages, and it is easy to get confused. Generally speaking, it is easier to understand if you put it another way. Refactoring can be said to be overlay, and the word overlay is clearer.

One of the object-oriented features of inheritance, is refactoring.

Refactoring is the rewriting of a subclass inherited from a parent method with the same method name and parameters, that is, the same declaration, but the implementation is inconsistent or completely different. In this way, if you have a deep understanding of object-orientation, it is clear that refactoring is a major feature of object-oriented programming.

For example: public class A

Public Class B Extends A} From the above two classes of the print method, it can be seen that the declaration and parameters of the method are exactly the same, but the implementation is inconsistent, which means that the print method of class B refactored the print method of class A.

Refers to any changes made to the software** to increase readability or simplify the structure without affecting the output.

Software refactoring is done with the help of tools, which can modify all references to that tool. In the methodology of Extreme Programming, refactoring requires unit testing to support.

In software engineering, the term refactoring usually refers to modifying a source without changing the external behavior, sometimes informally referred to as "cleaning up".

In Extreme Programming or other agile methodologies, refactoring is often part of the software development cycle: developers take turns adding new tests and features, and refactoring** to improve internal clarity and consistency. Automated unit testing ensures that refactoring doesn't stop ** from working.

Definition of refactoring.

Refactoring (noun): A modification of the internal structure of software with the aim of not changing"Observable Conduct of the Software"Under the premise, improve its comprehensibility and reduce its modification cost.

Reconstruction (verb): Use a series of restructuring criteria (techniques) without changing"Observable Conduct of the Software"premise, adjust its structure.

Both definitions emphasize that it is not changing"External behavior of the software"Under the premise, it does not change"Observable Conduct of the Software"This means that the changes do not affect the external use of the program (programmer), and externally, there is no change in the behavior and results of the program. Refactoring is simply a tweak to the internal structure of the program to make it easier to understand and then easier to maintain.

Because the essence of software development is to solve problems, and in any case, at least fully understand these problems before you start working, in fact, no matter how delicate and elegant you design, the problems to be solved change from time to time, and eventually someone (or even yourself) will force you to obey the schedule, and when you happen to make this piece of cobbled together things look like they can run, the boss can't wait to take it to the customer, at this time, from the perspective of an elegant programmer with a habit of cleanliness, no matter what, you have to refactor it again, But at this time, no one will allow you to do this, so you keep crying, you are seriously ill, and you are bedridden, so you stop talking and smiling.