Code is written by humans, executed by machines. Live code is also read by (other) humans for about 10x more than the time it took to write it. This is where "refactoring" comes to play. It is sort of making continuous improvement to code so it is more readable. It is cleaning up cobwebs from the corners.One of the most popular CS papers ever ("Hints for Computer System Design", 1983) suggests 3-step process about writing code - first, make it work; second, make it right; finally, make it fast". This book, a succinct second edition of a very popular first, is an excellent "show and tell" for the second part.It has a catalog of "code smells" and an inventory of "refactoring tricks" mapped to each. The first edition had working Java examples. The present one shows JavaScript ones. The examples are real-life but simple enough to not distract from the core - how to simplify the "first version" of code. Apart from the content, the insights that pops out can only be gleaned from years of deep experience. One example, say, most developers encode a "phone number" attribute as string in the first attempt of modeling. Soon enough, one needs to add "spam rules", "blocking number", "area code" etc. That necessitates phone number to be 'refactored' from string (i.e., a primitive type) to its own object model (say, a class called PhoneNumber). The author cheekily refers to the former type of behavior as "stringly typed" variables. Word play is a hallmark of many good engineers I'd worked with, but it is also a phenomenal way to remember things. Humor shortens the retrieval curve.What I liked most about the book is a broad adoption of "Paracelsus' Maxim" - the difference between a poison and something benign is the dose. Most of the refactoring pattens come in pairs. You can "extract function" from a big one, or "inline function code" if it is short, obvious and singularly used, say. You can "replace parameter with query" or "replace query with a parameter". The only unpaired pattern shows up with large/complex conditionals (say, a switch, or a multiway nested conditional with 'guard clause) - most/all of them are pain to read and should ideally be refactored, say, with "replace conditional with polymorphism". Live book site has 4 more patterns beyond the book.I found the refactoring patterns could be of three principal dimensions - one, structure -- variable, method, class, conditional; two, usage and locality -- depending on how much they're used and if they are used within/outside the module (class); three, data and mutation -- there is a clear separation between refactoring a data (or, value) object/data passed as value- or reference; separating data (query) from command etc. On top of that, some of the refactoring could be thought of as "helping the original developer" (say, to modularize or DRY better) vs. "helping others who may read the code later".When I read the first edition years ago, IDEs were not as robust nor opinionated enough about refactoring. These days, majority if not all the refactoring is done by default - one just needs to click to accept, say, extracting a method. It has been a huge time saving and long-term benefit for collaborative work and fits very well within the philosophy of "continuous integration"/Kaizen etc. One could argue that lowers the importance of such book. While the IDE may do the grunt work, key decisioning remains with humans, for now. Especially since most refactoring could appear in polar opposites it is therefore even more important to understand the context - the "why" - which this book brilliantly lays out.