Refactoring (2nd Edition) — Book Notes

Recently finished reading “Refactoring (2nd Edition)”. As a former ThoughtWorker, it would be embarrassing not to read a book by our company’s expert.

I must say this book is excellently written. The problems and solutions mentioned in the book resonate strongly with my own experiences in continuous programming and project work, and I learned many valuable insights from reading it.

I think this is what makes a good book - you genuinely feel that the points mentioned come from frontline experience summaries, not empty theories.

Key Takeaways

Some viewpoints and techniques from the book are worth savoring carefully and have high reference and learning value for actual programming. Here are some examples:

1. When writing pipeline operations, I like to put the ending semicolon on its own line, making it easier to adjust the pipeline structure.

2. When to refactor: The Rule of Three

   Don Roberts gave me a guideline: The first time you do something, just do it; the second time you do something similar, you wince at the duplication, but you do it anyway; the third time, you refactor. As the old saying goes: Three strikes and you refactor.

3. When not to refactor

   • When you don’t need to modify it, you don’t need to refactor. Refactoring is only valuable when you need to understand how it works.
   • If rewriting is easier than refactoring, don’t refactor.

4. Attitude toward comments

   If you don’t know what to do, that’s when comments are well used. Besides recording future plans, comments can also mark areas where you’re not completely confident. You can write down “why you’re doing something” in comments. This information can help future modifiers, especially those forgetful folks.

5. Use pipelines instead of loops whenever possible

6. Principles for extracting functions

   Once a function exceeds 6 lines, it starts to smell.

7. Refactoring isn’t a product of a certain phase, but something that needs to be done continuously

8. If a function has a return value internally, name this return variable result to quickly understand the function’s intent

9. The use of assertions isn’t limited to unit tests. JavaScript’s native support for assertions is only console.assert, but it can also be used in actual business code. Appropriately adding assertions helps explain situations, and don’t be afraid - assertions shouldn’t impact system operation. Assertions are particularly helpful for finding error sources.

10. Always remove dead code. If there’s a real possibility of needing it back, comment with the commit ID for retrieval

11. The test of good code is whether people can easily modify it.

…

There are so many good insights that I’m only excerpting a few here.

Final Thoughts

As mentioned above, a good book is one whose viewpoints align with your own thoughts, and that’s exactly how I feel. After reading this book, I have several thoughts:

1. I’ve always believed the difference between an engineer and a code monkey is that one uses their brain while the other doesn’t - this is both a joke and the truth. Engineers abstract and examine problems, reflect and summarize, while code monkeys mostly just move bricks, essentially trading time for money with no other gains. But in today’s rapidly developing world, how many more days can this brick-moving continue? I think it should be quite frightening to contemplate.

2. In the book’s preface, master Xiong Jie mentions that among the new generation of programmers, many focus on new tools, new frameworks, new business models, but very few focus on fundamentals like object-oriented programming, TDD, and refactoring. Indeed, superficial technologies emerge endlessly, and we should learn them, but we should pay more attention to the substance - fundamentals and internal skills are the way to go. So this sentence in the preface touches the hearts of everyone with thoughts and feelings. How many people get caught up in form, reading massive amounts of APIs, memorizing version numbers, but what’s the use?

3. The code readability we pursue is aimed at humans, not computers, so writing code should come with a sense of responsibility - not only being responsible for yourself but also for future others. So we can’t just say “whatever, as long as it works.”

4. After reading this book myself, I absorbed most of the abstract viewpoints and insights, but I can’t fully absorb all the specific refactoring techniques. I can only experience them in actual practice and training, while forming my own set of refactoring techniques.

5. I recommend this book to everyone committed to writing good code - it’s worth reading.