The article is simultaneously published in personal blogshuyi.tech, welcome to click on the original jump to read.

Refactoring is a great read for beginners. It will give you some perspective on refactoring, why you should refactor and how you should do it. Based on the book Refactoring, this article summarizes the preparation of “ideas” and “techniques” needed for refactoring.

Thoughts chapter refers to the knowledge of refactoring, and understanding these ideas will help you do a better job of refactoring. Tips refer to specific refactoring techniques that can help you write better code.

Thought article

Build test cases before refactoring

The first step in refactoring is to establish a solid set of test cases for the code to be modified. Anticipating established test cases is your safety rope that tells you if the work is done and if there are possible defects.

Value of refactoring

Refactoring can improve the design of software. Just like you’re constantly cleaning up your code, frequent refactoring helps your code stay in the shape it should be. Refactoring makes the software easier to understand, rather than leaving your code unreadable to others (or even yourself) months later. Clarity helps you understand the intent of your code faster. Refactoring helps find bugs because refactoring is done in small steps, with a hunter (test case) at each step to help you catch your prey (bug).

Good refactoring can ultimately help you make programming faster and more enjoyable.

When to refactor?

When to refactor? Just do it the first time, hate it the second time, refactor it the third time. Three things, three reconstruction.

It’s not possible to set aside time for refactoring; we need to refactor constantly in our daily work. But it’s ridiculous to think of refactoring before you start having repetitive functionality. But repetitive code or code problems, and not doing anything after three times, is a bit lazy.

When not to refactor?

When existing code doesn’t work at all, you should rewrite it, not refactor it.

Refactoring should be a habit

Refactoring should be a work habit, a little bit of refactoring in your daily routine, rather than dreaming of having a dedicated time for refactoring. Some of the big refactorings we’ve done have taken months or even years. If you need to add functionality to a running system, you can’t stop the system for two months to refactor. You can only do your work little by little, a little today, a little tomorrow.

How to test?

Our time is always limited, so test the parts you’re most worried about going wrong so you can get the most out of it. When testing, look for boundary conditions and focus your fire on that!

When do YOU cancel refactoring?

If you feel that refactoring is getting out of hand, the best thing to do is cancel the refactoring and go back to your safe zone. When you regain control, do the refactoring.

Refactoring team spirit

When doing large-scale refactoring, it is necessary to build consensus across the development team. The whole team must be aware that there is a major refactoring going on, and everyone should plan their actions accordingly.

Design patterns help you refactor

Learning design patterns is a great way to help you refactor, and it helps you carry complex business in the right place. But you should not simply know, but rather compare the differences between design patterns, what problems they solve, and where they apply.

Tips article

Don’t duplicate code

When duplicate code occurs, you should extract public methods. I think this is clear enough that when there is duplicate code you need to think: Do I need to extract duplicate code?

Don’t have functions that are too long or too short

When a function is too long, you should refine multiple functions based on the business logic. So how many lines is a function long? In my opinion, a function at lines 20-50 is appropriate. But this is just a rule of thumb, and the bottom line is whether your code can be read clearly and easily by others. If you write it long but it’s comfortable for others to read, that’s fine.

Be aware that functions that are too short can also make reading difficult, as they will make you jump multiple times and break your reading train of thought. So if a function is too short, you need to consider whether to remove it. In short, you should still structure each piece of business logic into the appropriate functions.

Do not have large classes

When a class is too large, you should consider whether you can split multiple classes. Or you should consider whether there is a problem with your class abstraction system. A class that is too large can be just as overwhelming and difficult to read as a function that is too long.

Don’t make the parameters too long

When argument columns are too long, you should use object arguments.

Refine divergent variations

Multiple changes due to a single change indicate divergent changes and you need to consider merging the changing code together.

Extracting object

Data that is always tied together needs to be distilled into a separate object.

Introduce explanatory variables

Don’t make your variables or expressions semantic, and include explanatory variables if necessary. Many people get into the habit of using flag to carry the value of an expression, but this is not a good habit. Variable names should be more semantic so that we can clearly understand what the variable does.

Move the function

If a function is called frequently by another class, you may want to consider moving that function to another class.

Move the field

If a field is used frequently by another class, you might want to consider moving it to another class.

Refine class, simplify class

When a class does something that should be done by two classes, a new class should be extracted and combined using composition relations. This is consistent with the SOLID principle that a class should have a single responsibility. If a class does something that two classes do, it has a complex responsibility and needs to be split off into a new class.

If a class doesn’t have much content, it’s time to consider whether to remove the class and optimize the entire class structure.

The resources

  • Out with the old and in with the new, try the System Refactoring and Migration Guide – Zhihu
  • Five simple rules to write clean code – Zhihu
  • Github-phodal/Migration: The System Refactoring and Migration Guide guides you to analyze and evaluate existing systems, formulate refactoring strategies, explore feasible refactoring solutions, build test protection networks, reconstruct system architecture, service architecture, module, code, database, and post-refactoring architecture guardianship
  • Four Principles of Technical Debt Governance – ThoughtWorks Insights
  • 31 Days Reconstruction Guide – InfoQ
  • VIP！！！！ Refactoring Day 1: Encapsulate Collection Los Techies
  • Don’t make “Clean Code” harder to maintain, use “Rule of Three” -infoq