You will see

  • Mysterious named
  • Duplicate code
  • Too long to function
  • Global data
  • Divergent variation
  • Shotgun modification
  • Attachment bond
  • Data mud pie
  • Basic type paranoia
  • Repetition of the switch
  • Looping statements
  • Redundant elements
  • Talk about universality
  • Temporary field
  • Too long message chain
  • A middleman
  • Too much class
  • Insider trading
  • Classes of the same kind
  • Pure data classes
  • A rejected bequest
  • annotation

Mysterious named

Naming changes are probably the most common refactorings, including changing function declarations, changing variables, changing fields, and so on

Many people don’t want to rename program elements because it’s not worth the time, but good names can save a lot of time on future puzzles

Changing your name isn’t just about changing your name, but if you can’t come up with a good one, there may be a deeper design problem behind it. The hassle of having an annoying name often drives code simplification

Duplicate code

If you see the same code structure in more than one place, be sure: try to merge them

When you read this code, you have to be extra careful, paying attention to subtle differences, and looking for all the copy changes if you’re going to make them

Too long code

In our experience, the longest and best programs have shorter functions

Programmers who are new to this code base often feel that “computation doesn’t happen” — the program is filled with endless delegate calls.

But after spending a few years with programs like this, you’ll see the value of small functions.

The benefits of indirection-better interpretation, easier sharing, more choices-are all supported by small functions

While small functions can also be a burden to the reader of the code because you have to switch contexts frequently to see what the function does, modern development environments can quickly jump between a function call and a light, or see both.

But in the end, the key to making small functions easy to understand is good naming

The net effect: you should be more aggressive with the decomposition function,

The rule to follow is that whenever you feel the need to comment something, you should write it in a separate function and name it after its purpose (not how it was implemented). We can do this with a set of even a single line of code, even if the replacement function call action is longer than the function itself, as long as the function name explains its purpose. The key is not the length of the function, but the semantic distance between what the function does and how it does it

The global variable

How were they invented by demons from the fourth circle of hell, and where are the programmers who dared to use them now resting

The problem with global variables is that they can be changed anywhere in the code

And there is no mechanism to detect which code has changed, and time and time again, the global data is causing weird bugs that are far away, making it incredibly difficult to find the code that is wrong

The first defense is to encapsulate variables

// bad
const info = { name : "haha" }

// good
const info = { name : "haha" }
export function defaultGetInfo(){return info}
export function setGetInfo(arg){info = arg}
Copy the code

Whenever we see data that could be contaminated by code anywhere, this is always our first line of attack.

At least you can see where to modify it and start controlling access to it, then it’s best to move the function to a class or module and allow only code inside the module to use it, thereby controlling its scope as much as possible

The global data bear out Paracelsus’ dictum that the difference between a good medicine and a poison is just the dose. A small amount of global data may be fine, but the more it is, the harder it is to process it exponentially.

Our willingness to encapsulate even small amounts of data is key to coping with change as software evolves