Book: https://www.amazon.com/Refactoring-Improving-Existing-Addison-Wesley-Signature/dp/0134757599
Author: Martin Fowler
I loved the format of this book and how it references the various refactoring types in the “refactoring catalog”. This newer edition of the book uses JavaScript for its examples and I found them very insightful and thorough. My only qualm is I wish there were more composition examples not using ES6 classes / inheritance, but it definitely translates with a little thought.
I think Chapter 3 on Code Smells was my favorite along with the “refactoring catalog” which specifies refactoring types and provides motivation, mechanics, and before/after examples on how to implement each of them.
Refactoring (noun): A change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior.
Refactoring (verb): To restructure software by applying a series of refactoring without changing its observable behavior.
When you have to add a feature to a program but the code is not structured in a convenient way, first refactor the program to make it easy to add the feature, then add the feature (P. 4)
This is the essence of the refactoring process: small changes and testing after each change. (P. 8)
Any fool can write code that a computer can understand. Good programmers write code that humans can understand. (P. 10)
So, my overall advice on performance with refactoring is: Most of the time you should ignore it. If your refactoring introduces performance slow-downs, finish refactoring first and do performance tuning afterwards. (P. 20)
A common sequence is: Read the code, gain some insight, and use refactoring to move that insight from your head back into the code. (P. 43)
The true test of good code is how easy it is to change it. (P. 43)
A healthy code base maximizes our productivity, allowing us to build more features for our users both faster and more cheaply. To keep code healthy, pay attention to what is getting between the programming team and that ideal, then refactor to get closer to the ideal. (P. 43)
Refactoring is all about applying small behavior-preserving steps and making a big change by stringing together a sequence of these behavior-preserving steps.
Refactoring is always done to make the code “easier to understand and cheaper to modify” (P. 46)
Refactoring Improves the Design of Software (P. 47)
Refactoring Makes Software Easier to Understand (P. 47)
Refactoring Helps Me Find Bugs (P. 48)
Refactoring Helps Me Program Faster (P. 48)
The first time you do something, you just do it. The second time you do something similar, you wince at the duplication, but you do the duplicate thing anyway. The third time you do something similar, you refactor. (P. 50)
Whenever I have to think to understand what the code is doing, I ask myself if I can refactor the code to make that understanding more immediately apparent (P. 51)
While it does happen that teams do too much refactoring, it’s much rarer than teams not doing enough… Many managers and customers don’t have the technical awareness to know how code base health impacts productivity. In these cases I give my more controversial advice: Don’t tell! (P. 55)
The reason we mention comments here is that comments are often used as deodorant. It’s surprising how often you look at thickly commented code and notice that the comments are there because the code is bad… A good time to use a comment is when you don’t know what to do. (P. 84)
When you feel the need to write a comment, first try to refactor the code so that any comment becomes superfluous (P. 84)
With ❤️ Andrew