One quarter of a year has passed. Have you achieved your small goal of reading more books?

I recently bought two copies of Refactoring 2 (see the cover art, the one written in JavaScript) after reading it for a long time. Conveniently made a few small summary and extract to share, hope to be helpful to everyone.

PART 1 · Chapter refining

Chapter 1: Start with a very ordinary Demo and make the code better and better through step-by-step refactoring. Without further ado, relevant demo has been written and uploaded to Github. If you need it, you can directly click to read the original text (it is suggested to eat with the original book).

Chapter 2 – Principles of refactoring: Explains what refactoring is, what it is for, when to refactor, and when not to refactor, as shown in the figure below.

In order to improve the speed of programming for refactoring purposes, there is a “design durability hypothesis”. By focusing on improving the internal design, we increase the durability of the software, thus maintaining rapid development for longer.

There is another key point, how to tell the manager (customer)? After all, it’s a wasted effort that most people think adds no value. Two suggestions from the book:

  1. If the manager knows the technology and understands the design durability hypothesis, it should not be difficult to explain the meaning of refactoring. Such a manager should encourage daily refactoring and actively look for signs that the team isn’t doing enough daily refactoring. (While “teams do too much refactoring” does happen, it’s much rarer than not doing enough)

  2. If managers and clients aren’t tech-savvy, there’s a more controversial suggestion: Don’t tell your manager. Software developers are professionals, and our job is to create efficient software as quickly as possible. I got paid because I was good at implementing new features quickly, and I thought the quickest way to do that was to refactor, so I refactor.

Chapter 3 – Bad Code Smell: Refactoring is often associated with teasing poorly written code, but what is bad code? How do we avoid it when we develop. The book summarizes 24 scenarios for you to consider:

  • Cryptic naming, repetitive code, long functions, long argument lists, global data

  • Variable data, divergent change, shotgun modification, attachment, data mud

  • Basic types paranoia, repetitive switches, loops, redundant elements, talk of generality

  • Temporary fields, too long message chains, middlemen, insider trading, too large classes

  • Similar classes, pure data classes, rejected bequests, annotations

Specific definitions and common solutions for some difficult words can be seen in the following figure:

I just read three chapters, the summary of the follow-up and then I gradually serialized the follow-up, and then I posted some of the 15 statements that I thought were pretty good and made sense.

PART 2 · Excerpt

If you want to add a feature to your program

But found that the code lacked good structure

It’s not easy to change

So let’s refactor that program first

Make it easier to add features

Then add the feature

Refactoring is about making small changes to your program

If you make a mistake

It’s easy to spot him

Any fool can write code that a computer can understand

Only those who can write code that humans can understand

Is a good programmer

Performance issues for refactoring processes

The general recommendation is

You can ignore it for the most part

If refactoring introduces performance costs

Finish refactoring first

Then do performance optimization

When programming

You need to follow camp rules

Make sure you leave the codebase healthier than when you arrived

The test of good code is

Is whether people can easily modify it

To keep the code base healthy

Be aware of the gap between the present and the ideal

And then we get closer and closer to that ideal through refactoring

If someone says

Their code was unavailable for a day or two during the refactoring process

Almost certainly

What they’re doing is not refactoring

Three rules

Just do it when you do it for the first time

Doing something like this the second time produces a solution

But you can do it anyway, right

Do the same thing a third time

You should refactor

Initial refactoring is like sweeping the dust off a window

It allows us to see the scenery out of the window

When I read the code

Refactoring leads me to a higher level of understanding

If you know how to read the code, it’s hard to catch on

Some people think these refactorings are just meaningless toying with code

They don’t realize it

It’s missing these nuances

They can’t see the opportunity that lies behind the chaos

Dirty code must be refactored

But beautiful code also requires a lot of refactoring

Every time I have to change it

First, make it easy to change

(Warning: This can be difficult.)

Then make this easy change

The sole purpose of refactoring is to make development faster

Create more value with less work

The point of refactoring is not to polish up the code base

It’s purely economic

The reason why we refactor

Because it makes me faster — faster to add features

Fixing bugs faster

Most people would think

It’s good to have a large inheritance

But from a programmer’s point of view, it’s different

Legacy code is often complex

There’s not enough testing.

And the most important thing is

Someone else wrote it

PART three, the tail

The article that thinks to extract a category originally, should write relatively rise to be able to relax a bit.

However, in order to extract the whole picture can look good, specially to masturbate a section of code to do a small tool to generate pictures, but also really should introduce myself, very can toss.

Finally, everyone to a wave of concerns to share ah ~