Code refactoring skills

As a software developer, have you ever encountered such a situation: when reading other people's code, it feels messy and repetitive; or you may find many of the shortcomings when you go back to view your own code after one or two weeks. If so, congratulations. At least you are a thoughtful programmer and your realm is better than before. In this case, do you choose to rebuild it yourself? If you choose the latter, congratulations again. Not only do you have thoughts, but you are a programmer who thinks and can put them into practice. If you choose the former, it is a pity that you may have been deeply numb. You can no longer feel the pleasure of software development. Maybe you have been passionate and please have it again, even a bit.

When writing a new piece of code, you don't have to worry about code refactoring, because you have no code to refactor at all, and you don't have to be too obsessed with the structure design before coding, the author of Java and pattern also suggested that the reader encode the code first and then modify the design, which is what we often say. First, let's talk about it. Because we often do not reach such a high level and can cover all aspects before coding, it is unnecessary to spend too much time on code design. But the design still needs to be done, which can be rough. Of course, annotations cannot be added after the code is compiled, and half of the functions will be lost. Half of a good comment is to write a clearer code, and the other half is of course for the convenience of readers.

But all day long, you are faced with an existing code and an existing framework, that is, your one-acre three-point location. Reconstruction is inevitable at this time. If you are numb to Ctrl + C; Ctrl + V, you may not be able to experience the fun of refactoring a piece of code. You can think about how a sense of accomplishment is achieved when you replace 5000 lines of code with 500 lines.
Refactoring may not necessarily reduce your code or improve the system performance. However, refactoring will make your code clearer, easier to maintain and expand, and more robust, it also makes it more possible and easy to implement simplified code and improve performance.
So what kind of code should you consider refactoring? How can we reconstruct it?
1. duplicate code: this must be the first. If you see the same data structure in more than one place, be sure to combine them into one. The most common method is to extract data into a function.
2. Too long function: the longer the program, the harder it is to understand. All benefits of the indirect layer: Interpretation, sharing, and selection capabilities are supported by small functions. If you encounter a function that is too long, you should break it down more aggressively. At this time, we follow the principle that every time we feel that we need to annotate something, we write it into an independent function and name it for its purpose. If you give a good name to the function, the reader can understand the function's role through the name, and there is no need to look at what is written in it.
3. Category: If you want to use a single class to do too many things, there will usually be too many instance variables. Once so, repeated code will come one after another. At this time, we should move things that do not belong to this class, put them in its place, or create a new class, instead of simply considering convenience, put too many attributes and functions that do not belong to a class into it, resulting in a bloated class.
4. too long parameter list: We often add parameters to expand a function, which leads to excessive parameters at a time, then the call of the method will become obscure and difficult to understand, and the order of parameters cannot be written incorrectly. At this time, we can make too many parameter lists into a meaningful object, or replace functions with function objects.
5. casual modification: if every time you encounter a change, you must make many small modifications within different classes to respond to the change, then you may encounter the trouble of making a casual modification. if there are too many changes to be made, it is not only difficult to find them, but also easy to forget an important change. After the modification, the testing work will be heavier. At this time, we can put this series of related behaviors into the same class. If there is no such class, you can create a new one.
6. Attachment: The function is more interested in a class than the class in which it is located. In countless experiences, we can see that a function calls a half-dozen get function from another object to calculate a value. The modification method is to move these functions to the desired place.
7. data dashboard: data items are like children who like to stay together in groups. You can often see three or four identical data items in many places: the same attributes in two classes, and many functions have the same parameters. The data that always appears together should be put into their own objects.
8. Basic Type paranoia: Java has eight basic types, and others are objects. We know that the basic type is stored in the stack in the memory, and the object is saved in the heap. Obviously, objects consume more memory. If you have a set of attributes that should always be put together, you can make them into an object.
9. Redundant class: Every class you create has to be maintained and understood. These are all about spending money. If a class no longer undertakes the originally planned work, it should disappear, rather than let it survive in the system.
10. in the future, we sometimes encounter a situation where a function has a parameter that is temporarily unavailable, called a reserved interface, or a table has multiple unused fields, these are all data that will be used in an imaginary day, but they exist in our current system. Or to use a certain design pattern, too many base classes and methods are abstracted. Many of these things may only be possible in test cases. At this time, you can consider deleting it.
11. Relationship with Potassium: Sometimes you will see that the two classes are too close. If they happen to two people, we don't have to be GUARD: But for the class, we want them to strictly abide by the rules.
12. Too many comments: Don't worry. We're not saying you shouldn't write comments. In terms of smell, annotation is not a bad thing, but it is often the case that you see a piece of code with long comments, and then find that these comments exist because the code is terrible.
13. Confusing temporary variables: Sometimes you will see an object where an instance variable is set only for a specific situation. Such code is hard to understand, because you usually think that an object needs all its variables at all times. When a variable is not used, it is assumed that the purpose of the variable is crazy. Please create a home for this poor orphan and pull all the Code related to it. You will find that this orphan also has its own parents. A common example is that a class has a complex algorithm that requires many variables. Because the implementers do not want to pass common parameters every time, these temporary variables are defined as member variables, these member variables are only valid in this algorithm and will be confusing in other cases. At this time, you can replace this algorithm with a class to form an algorithm object and make these variables into attributes of this class. Then everything will go through the clouds and see the sun.