Programmers should know-also say refactoring

It has been a long time since Martin Fowler first proposed the concept of refactoring. It is not so much a method as an idea and a habit. I have been using it to improve my work.ProgramSo I want to talk about my two points here.

Rebuilding is not "picky eaters"

As mentioned above, refactoring is not only a fixed method, but also a habit of thinking and coding,No matter which language you program, you can apply refactoring.The examples in the book "refactoring" are all java. Many may think that the refactoring method can be used only in Java, C #, and other object-oriented languages, in process-oriented and functional languages, it is difficult to reconstruct applications. I don't think so. Indeed, there are many specific reconstruction methods in the object-oriented language, such as the extraction interface, the variable moving up, and the variable moving down, however, there are still some common refactoring methods that can be used in various languages.

Two common examples are as follows: renaming and extraction. These two methods are very common in whatever language programming, and we often perform such refactoring. For example, when I use PL/SQL to write procedure and function, I often perform this operation. Especially when the refactoring option is added in the new PL/SQL developer version, it can help us to perform the refactoring operation automatically. Here, PL/SQL is procedural rather than object-oriented.

Therefore, we can compile anyCodeYou can use refactoring in the process, even in HTML code, JavaScript code, and so on, because refactoring is not just a specific method, but a way to improve the code, the purpose of improving the system is to make our system more readable and maintainability, so as to have better quality.

Refactoring can be performed at any time

Another subtitle of Martin Fowler's refactoring is "improving the design of existing code", which makes me misunderstand at the beginning, I thought that Refactoring can only be performed after the code is written. Otherwise, we can refactor the program at any time. (I used to call it a refactoring in the process during internal communication)This will be more conducive to subsequent encoding.

For example, when writing a program, we suddenly find that the name of a variable is unreasonable. We can reconstruct it immediately and modify the name. Or, more practical, I found that the code I want to write next is completely the same as the previous code, or I can copy it from another place, and then I can make some modifications. Then we can extract the previous method back, you can call a method directly at a new location, or find that you want to use a method, but it is in another class, you can determine whether the parent class or interface can be extracted, then, extract the general method to it and inherit or implement it, so that you can conveniently call the method.

There are still many methods that can be done in the coding process, without waiting for all the encoding to complete. The advantage is obvious. If you need to implement similar functions later, you can directly call the existing method without waiting for the final adjustment.

In short, the more you use it, the more you feel that you should always put the idea of "refactoring" in your mind during programming and use it at any time.

Do you want to say something about refactoring?