Refactoring is not a silver bullet

Posted on Edited on Disqus: Word count in article: 2k Reading time ≈ 2 mins.

When this book was written, object-oriented programming was still niche, but now functional programming has begun to become popular.

Until today, most programmers have heard of the ideas and methods of refactoring. If you are a Java programmer, it is even harder not to know about it.

As time has elapsed, refactoring has become a part of coding.

Chapters 1, 2, and 3 of this book explain what refactoring is and when to refactor. They should be read carefully.

Chapters 4 to 11 discuss specific methods, so if you are familiar with Java, you can refer to them accordingly.

The following chapters can be skimmed over.

I used to read “Code Complete” in school, so when I read this book, it’s relatively less important.

For example, I may not be good at iOS development, but when I see the project in my current company with hundreds of lines of functions, a lot of duplicate code, and various magic numbers, it’s really frustrating.

Of course, this doesn’t mean that the previous projects were bad. After all, everyone has been forced to be stupid because of deadlines.

Overall, this book should still be read, especially because the cover says:

“The secret technique that ordinary programmers must practice to become programming experts”

Not reading this book may mean not being aware of the pitfalls discovered by previous programmers.

For example, my understanding of temporary variables was not appropriate.

Also, I used to write functions too casually, without using let for parameters and without adding private for non-public ones.

Some of the inspiring aspects are:

  • Eliminating temporary variables
  • Polymorphism replacing switch statements
  • Null Object

I have been working on iOS for a short period of time and I am a junior programmer. There are a lot of things I don’t understand. When I work on features, I often ignore these things.

Although I often think of refactoring immediately after a feature is done, people are inherently lazy, so I usually think everything is fine as long as it runs, and then I rely on refactoring to tidy up the code.

The ideal situation would be:
Version Control + Review + Pair Programming + Refactoring (my current company is awesome, as we have implemented most of this)

But this makes me think of a classic essay about software engineering written by Fred Brooks in 1987, “No Silver Bullet”.

Refactoring is certainly not a silver bullet.

Sometimes, we just have to rewrite, my dear.

Translated by gpt-3.5-turbo