Restructuring-a job that makes programmers happy

Refactoring is something that almost every software project will encounter. Whenever people mention "refactoring", they will always describe it like this: the process of reorganizing an object design using various means, the purpose is to make the design more flexible and/or reusable. You may have several reasons to do this. Efficiency and maintainability may be the most important reason.
We don't want to talk about the benefits of restructuring and restructuring. This article wants to talk about how to make every Program Employees are happy to work.
Milutinovic has brought the advanced football theories originating in Europe to Chinese football. In addition to these theories, there is also an important concept: Happy football !". He taught his Chinese players to play football because they are happy and even more happy. Similarly, one of my leaders often tells us that we work eight hours a day. If you are unhappy during the most important time of the day, so what is the significance of your work?
Code It is too easy to get worse. Code always tends to have larger classes, longer methods, more switch statements, and deeper condition nesting. Repeated code can be seen everywhere, especially the code that looks similar and detailed at the beginning is flooded with the entire system: conditional expressions, loop structures, set enumeration .... Information is shared between components with few relationships in the system. Generally, this makes almost all important information in the system global or repetitive. You cannot see any good design for this code. (If any, it is not recognizable .)
This code is hard to understand, let alone modify it. If you care about the system architecture, design, or a good program, your first reaction is to refuse to work with such code. You will say, "It is better to rewrite such a bad code for me to modify it. "However, it is unlikely that you completely rewrite a system that can or even is running. You cannot guarantee that the new system can implement all the original functions. What's more, you are not living in a vacuum, and there are more investment, delivery, and competitive pressures.
So you use a quick-and-dirty method. If the system has a problem, you can directly locate the problem and modify it locally. If you want to add a new feature, you will find a similar piece of code from the original system, copy it out, and make some modifications. For the original system, you think, since I cannot re-write it, and they are already running, let it go. Then, the code you added becomes the object that the next programmer cursed. The system becomes increasingly difficult to understand, and maintenance becomes increasingly difficult and expensive. The system becomes a huge mud ball.
It is not hard to see that the programmer's work is undoubtedly heavy and boring at some times. How can we let the programmer get rid of these unhappiness? As a programmer, I have a very important method, is to refactor the code.
After successful reconstruction, the development efficiency is improved. When programmers have time, they can read books or news and send back an email to their friends, instead of having to copy and debug them all day. When maintaining a piece of unfamiliar code, it will no longer curse the poor design of previous designers, so that they can easily face the schedule on the calendar.
In many cases, it is difficult to make a good design at a time. To ensure the vitality of the software, it is doomed to frequent changes. In the face of so many iterations, as designers and programmers, we must pay full attention to the vitality brought by refactoring to a software product.