Any fool can write code that a computer can understand. A good programmer is one who writes code that a human can understand.

— Martin Fowler, Refactoring

Older, slower systems; Messy chunks of code left behind by previous programmers; A maze of super-large functions… What can you do? There are two choices: endure or reconstruct.

However, reconstruction, is how many people in the pain!

Expert refactoring code looks like this:




When you refactor the code, it looks like this:




Capability aside, there are many reasons why people resist refactoring:

The project is so urgent that it is good if it can be launched. How can we have time to reconstruct? There are too many modules involved, too much refactoring, too risky! Refactoring code is thankless and disliked by colleagues. With so much turnover in the Internet industry, what’s the point of leaving next month? …

There are many reasons, the root of which is the lack of high requirements for their programming skills. Knowing the importance of refactoring, but being forced to surrender by external circumstances or circumstances. However, as the movie Infernal Affairs said: “Out of the mix, sooner or later, you have to pay back.” If you don’t hone your refactoring skills now, the bad taste of code will retaliate in the future.

What do the pros think about refactoring?

In time for the 20th year of refactoring, one of the timeless classics of software development, Refactoring: Improving the Design of Existing Code, has received a major update. In a recent interview with Martin Fowler, author of The book Refactoring, we thought He had thought about refactoring and some of the issues associated with it. Let’s see what the pros can do for you.




What triggers refactoring?

Martin: Of course there are many reasons for refactoring code. First, when you don’t understand code, a sure sign is that you spent a lot of time trying to figure out the purpose or function of some code. Another case, to paraphrase Ward Cunningham, one of my favorites: Once you have a mental idea of what code does, “take” it out of your mind and put it back in the code so that the next time you or someone else sees it, they can actually read it. Another factor that triggers refactoring is when the developer wants to improve the code, but the architecture of the existing code makes it difficult to do so. In this case, refactoring increases the speed and difficulty of improvement, and as the structure becomes simpler, improvements will follow. Again, Kent Beck said it best: make the code architecture easy to change first, and then make simple improvements. To me, these are The Times when refactoring is triggered: when your code isn’t clear enough to understand; When you know something about the functionality of your code and you want to embed it. When you want to improve your code, it’s easier to refactor first and add new functionality later.

Basically, people have a tendency not to fix things if they’re not broken, let alone reconstruct them. What do you think can be done to overcome this barrier in light of the fact that “we’re not refactoring enough”?

Martin: I have to admit, I’m not a very persuasive person. I don’t try to convince people to improve, I just try to explain how things should be done and hope they see and try best practices for themselves. When you talk about not changing code, you definitely need some kind of code base to make sure that problems can be easily detected when you change code, which is why we put a lot of emphasis on rigorous testing, because testing is a great monitoring mechanism. Other technical managers from projects explain that it’s okay to improve the code, but only through iteration and extension to produce effective code. However, sometimes developers can get stuck in their old ways. I’ve seen teams where developers say “oh, we shouldn’t change” to their supervisor, and the supervisor is surprised and says “No, I really want to refactor”. It’s not uncommon for people like this to have completely opposite ideas. You need to create a culture that allows people to say, “We can go back and improve the code.” On the testing side we have the necessary security foundation so that developers can detect errors when they occur.

During development, you need to add new features to the software on the one hand, but you also need to refactor to keep the software healthy, otherwise you can’t add new features to the software. Maintaining a balance between the two is important and requires good judgment. Like many things, good judgment is indeed a key element, but unfortunately there are no shortcuts to teaching it.

Business people often think that if a program isn’t broken and doesn’t add new features, it shouldn’t waste time improving it. How do you recognize the meaning of refactoring?

Martin: Employers pay us to do technical work, and a big part of that is keeping the code base healthy so that new features can be added to it in the future. If we don’t refactor, we’re technically failing our employers, because not refactoring slows down feature development. From an economic point of view, we have a responsibility to keep our codebase in a healthy state, and refactoring is certainly an important way to keep our critical codebase in a healthy state, and if we don’t keep our codebase in a healthy state, we’re stealing money from our customers and our bosses. So fundamentally, we have a responsibility to refactor.

In my opinion, you should never use phrases like “it’s our professional duty,” “It’s the right thing to do,” or “for moral reasons.” I know a lot of people like to use that phrase, and when you abuse terminology, you’re lost. The only reason for refactoring is economic. The purpose of refactoring is to add more features more quickly in order to respond more promptly to the changing needs of all parties. Economic reasons are the underlying reasons for refactoring. By the way: that’s why smart professionalism is the way to go, because employers pay developers to generate functionality quickly from code, and we should think about refactoring in that way. But strictly speaking, it’s not important for managers or organizations to quickly develop or add features, or to keep the code base healthy. They pay developers to do software development to deal with these problems.

Can refactoring thinking extend beyond code?

Martin: Absolutely. The key to refactoring is the idea: how to make the smallest change, rather than trying to make big changes, and figure out how to do that. There are a lot of small changes that can happen through refactoring, and then connecting those changes together is at the heart of how refactoring applies to this situation. How do we break down one big change into many small changes, make as many small changes as possible without changing the overall performance of the system, and then over time, practice and think about how to break it down. The content of my book is my experience of thinking through refactoring frameworks, experimenting with various refactoring techniques and making decisions. There is a whole set of mechanisms in the book that allow me to refactor effectively, but mostly by doing it. You try different refactorings, and you figure out which refactorings produce the desired sequence, and you try to identify the refactorings, and the same logic applies at a broader level.

Masters value the tao, and Martin’s share tells you more about how a software guru or a senior developer thinks about refactoring, cognitively. So, how to cultivate their reconstruction skills? This is why I recommend refactoring (2nd Edition), the immortal classic upgrade secret!




The much-anticipated Refactoring (Version 2) is an overhaul of the first edition, reflecting many of the changes that have taken place in programming. The list of refactorings introduced in version 2 is more cohesive, with code examples rewritten in JavaScript. In addition, refactoring examples related to functional programming have been added in version 2 to teach readers how to refactor without classes. The new edition follows the structure of version 1, explaining what refactoring is, why it is needed, how to identify code that needs refactoring by “bad smell,” and how refactoring can be done successfully in any programming language in practice.

A lot of attention has been paid to the change in the use of code samples from Java to JavaScript. Martin explains that the philosophy and architecture behind refactoring can be applied to any programming language. I chose JavaScript simply because I felt it was a language that was widely used. No matter which language you program in, the basic mechanics are exactly the same, and there are differences between languages, but I think there are far more similarities than differences. Keep in mind that Java is a very strict object-oriented programming language, and all refactoring in release 1 is object-oriented. I want to use this reprint to show that you can refactor in any language, in any environment, and follow the paradigms mentioned in the book, which is another reason I plan to republish this book, and the motivation for republishing this book. If this update is good enough, I won’t have to revise the book for another 20 years.




Bad taste, test-first, behavior-preserving change is the foundation of refactoring. In Refactoring (Version 2), the details of the refactoring approach were polished again, and the refactoring process was much smoother than in version 1. A good way to read a book is to look at the steps before and after the reconstruction technique and how the author achieves behavioral preservation. In version 1, for example, the method of keeping objects intact was to add new parameters to the original function; Version 2, on the other hand, creates an empty function, makes the desired adjustments, and then replaces the original function as a whole. By contrast, the new approach is undoubtedly more controlled and less likely to fail when things go wrong.




Comparing the refactoring lists of the two editions, you will find that the refactoring methods included in the second edition are more cohesive in use, more coherent in operation, and more focused on the combination of refactoring methods. The “large reconstruction” that took up an entire chapter in the first edition was completely deleted in the second edition. Some of the more complex refactorings, such as copying “monitored data” and shaping template functions, are also not included in version 2. The new refactoring methods in version 2 are more detailed and micro operations such as extracting variables, moving statements, splitting loops and splitting variables. These new tricks seem simple, but they address the most common refactoring challenges in large-scale legacy code and fill in the details that were missing in release 1. This change reflects Martin Fowler’s consistent attitude toward refactoring: a journey of a thousand miles begins with a single step. The more complex and changeable the external environment is, the more basic skills and solid steps must be taken.

Practice secrets in this, the most important or hands-on practice. Refactoring is like most things in software development: there’s no other way to do it. Refactoring is certainly helpful to those who are new to the concept of refactoring, but it can also help those who know refactoring share relevant skills. Martin also reminds readers: Remember that refactoring is all about small steps, and make sure you commit frequently. If something goes wrong, you can just roll back to the previous commit record, which reduces the stress of refactoring. Refactoring won’t hurt you too badly, because you’ll roll back at worst, which is what version control systems are for. So get started and refactor. Action is the key.




Refactoring: Improving the Design of Existing Code (2nd Edition)

By Martin Fowler

Translator: Xiong Jie Lin cong Yu

Editor’s Recommendation:

  • The immortal classic of world software developer MartinFowler

  • Ordinary programmers to advance programming master’s training secrets

  • It is a worldwide bestseller and has been translated into many languages including Chinese, German, Japanese and Russian.

  • After 20 years, this classic book has been updated by more than 30%, with many project cases updated.

The book is an updated version of the classic “Refactoring”, published 20 years later. The book clearly reveals the refactoring process, explains refactoring principles and best practices, and shows when and where to start digging code for improvement. There are more than 60 possible refactorings, each of which introduces the motivation and techniques for a proven code-changing approach. The refactoring guidelines outlined in this book will help developers make small changes to the code, thereby reducing risk in the development process.

-END-