refactoring refactoring

Martin Fowler's Refactoring made it to my bookshelf early on, but never read it in its entirety. One is that there is no time; the other is that every time I pick it up and look at it, I immediately lose my patience when I see those broken thoughts. Finally one day, when I had the time and the mood to read this book, I almost finished reading this book in one night. But to be honest, it's not because of the content of the book that I am attracted to it, but I am very worried that this time I will give up halfway again. After reading it, my first impression was to understand why Mr. Hou Jie did not translate the book himself, but had to make the first draft of Xiongjie first. I admire Xiong Festival, he can completely translate the content of such ramble. Just like the initial impressions Hou Jie mentioned in the preface, "the refactoring goal is too bland, and the refactoring steps are too trivial", I can't understand why this book is called a classic, but I can understand As Bear said, I did not read this book a second time after the translation was completed. And I really don't like some of the words in this book, the desktop terminology makes me uncomfortable. No matter whether "Type" is called type, it is called type; whether "Collection" is called collection or cluster, it seems really uncomfortable.

Although I have refactored a lot of code over the years, before each refactoring, I feel a little less confident. It was, after all, a program that was working fine so far, and I knew I had to refactor it, but I didn't want to do it. And every time the refactoring is completed, I have a deeper understanding of the Courage in the XP values. Without a little courage, I really don't want to start with the original code. I know the root cause is whether the code has unit tests. Without unit tests, there is no guarantee that it will work properly after modification. Unit testing is extremely important, but it has little to do with refactoring techniques, ---- no matter what refactoring technique is used, unit testing must be used, but with unit testing, it is not necessary to use Fowler's refactoring techniques. construction method.

Martin Fowler lists as many as 72 refactoring techniques, and quite a few of these refactoring techniques can be implemented directly through the IDE. For example, Extract Method can be easily completed in Eclipse. There are also quite a few that do not need to be listed separately, especially in the case of using an IDE, refactoring methods such as Add Parameter and Remove Parameter are listed in the refactoring directory, and the implementation is a bit of a fuss. Taking Eclipse as an example, adding or deleting parameters to a method, and what needs to be modified, is clear at a glance. There is no need to use Martin's method, so be careful. But considering that Martin was writing in 1999, there is no such excellent programming conditions, this kind of caution is not difficult to understand.

Some people juxtapose "Refactoring" and "Design Patterns" as classics, but I strongly disagree. "Refactoring" was written in 1999. From the current point of view, many refactoring techniques are too fussy. In comparison, "Design Patterns" was written in 1995, almost 20 years ago, and almost all patterns are still sparkling. Although "Refactoring" lists 72 reconstruction methods, the core idea is actually one, that is, small-step reconstruction. For example, taking Rename Method as an example, Martin's approach is to declare a new method with a new name, and then call the new method in the old method, so that the caller will not be affected, and then modify all callers. Other refactoring methods are similar, but in the current situation, this method is really unnecessary, and it is not good to do so. Because in the case of IDE, if we refactor in this way, where this method is called, it will be hard to find out. On the contrary, if we directly change the method name, the IDE will mark in red which places are affected. In addition, if Rename Method is to be listed as a refactoring method, why are Rename Interface and Rename Package not listed as refactoring methods? Therefore, Martin has listed 72 kinds of reconstruction methods, which makes people doubt his original intention. Not only that, refactoring methods such as Rename Method can be automatically completed using Eclipse. In general, there are 17 refactoring methods that can be automatically implemented, which are listed as follows:
Extract Method
Extract Class
Extract Interface
Extract Superclass
Inline Class Inline Class
Inline Method
Inline Temp Inline Temporary Variables Pull Up
Constructor Body
Pull Up Field
Pull Up Method Pull Up Method
Pull Down Field
Pull Down Method Pull Down Method
Encapsulate Field Value range)
Move Field (moving value range)
Move Method (moving function)
Replace Constructor With Factory Method (replace constructor with factory method)
Rename Method (rename function)

However, many of Martin's refactoring principles are still worth learning from. For example:
1. Remove temporary variables or local variables as much as possible, because variables will hinder the extraction of methods and make the code unclear. Some refactoring techniques will affect performance when used, but once the structure is clear, performance problems will be solved Great solution.
2. Remove comments as much as possible. The code itself should be able to explain itself. If it cannot be explained, it should be refactored. It's not that you can't add comments, but that comments are a signal that your code isn't clear.
3. Remove the branch structure as much as possible, the ability of the branch structure to respond to changes is low
. 4. Use the final keyword skillfully.
5. Test frequently and move forward in small steps.