I'm hunting around these days for good books on general programming. I'm a fairly pragmatic programmer (not everything needs to be a class). Has anybody here read the first edition, and what was your impression of it?
I always try to either be refactoring or changing behavior but not both at the same time. That has kept me out of a lot of trouble.
> "For each desired change, make the change easy (warning: this may be hard), then make the easy change"[0]
[0] https://twitter.com/KentBeck/status/250733358307500032
Edit: Added a link to his first Tweet containing the quote that I know of.
Keep those tasks separate.
The biggest benefit is that it makes code reviews easier for others because the reviewer can step through each commit. This makes the refactoring changes much more obvious.
Splitting the commits also makes it much easier to roll back a functional change that goes wrong or isn't needed while still keeping the refactoring improvements.
You don't need to understand the code; you don't need to step through the code. You follow the steps for "extract method" and you go from a working state to another working state with no worries.
The individual refactorings are more-or-less interesting, but as others have said, they're somewhat commonplace now.
Two books that every programmer should read: Software Tools[1] and The Elements of Programming Style[2] by Kernighan and Plauger. Bonus: The Unix Programming Environment[3] by Kernighan and Pike.
[1] https://www.amazon.com/Software-Tools-Pascal-Brian-Kernighan...
[2] https://www.amazon.com/Elements-Programming-Style-2nd/dp/007...
[3] https://www.amazon.com/Unix-Programming-Environment-Prentice...
They describe the design and implementation of many of the classic unix tools. Nowadays it is posible to learn the same principles by reading the userland source code of BSD or Plan9.
If I was going to read a refactoring book while waiting for the second edition, I would take a look at “Refactoring to patterns.” (https://industriallogic.com/xp/refactoring/) R2P combines the best parts of Fowler’s Refactoring and the Gang of Four design pattern book.
Notably: it emphasizes the fluid nature of Refactoring and design patterns. Every Refactoring to a pattern in the book is shown in a few different ways, each explaining some of the trade offs. It has the same recipe book feel that Fowler’s book has and it lends itself to browsing and reference.
The recipe-driven approach makes it easy to carry out the refactorings and provides a fun new way to think about modifying code.
Imho, the section on the “Compose method” Refactoring in R2P makes the purchase worth it. How can such a dead simple Refactoring make code so much nicer? Read the book to find out ;)
Javascript has a lot more first-class options other than classes and interfaces, so there might be some more insight.
As far as good programming books, I quite liked Code Complete when I was a younger programmer, and found that Anti-Patterns was helpful in giving me a lot of vocabulary and patterns in recognizing what happens in job-settings, as well as refactoring overviews as a solution to real problems.
When I was in college, I read "Refactoring to Patterns" which pretty much sums up Refactoring in a short chapter. The ideas aren't really that complicated, but seeing some practical examples is pretty useful.
"Working Effectively with Legacy Code"^1 is usually what I recommend instead. It felt like a more up to date approach
More generally "The Pragmatic Programmer"^2 is a classic for a reason. But from you're comment you've probably already read it.
1. https://amzn.to/2I4rIWP 2. https://amzn.to/2GfxVTa
2.
It's a decent book, though obviously looking a bit dated now, particularly in the OO-centric presentation. I would confidently recommend it to someone like a junior developer at work or a keen self-taught programmer who had figured out the basic mechanics and was starting to explore ideas about building and maintaining bigger systems. I probably wouldn't recommend it to anyone further down the path, though, just because the techniques described tend to be quite simple and they're mostly things that people learn with experience anyway.
1. Refactoring does not change functionality. The observable behavior should be the same before and after.
2. Refactoring should be done one step at a time. Each step should be as small as possible and obviously correct.
3. When changing code, at any given time you should be working on a functional change or refactoring - never both at once. Ideally these should be split into separate commits as well.
I think beyond the principles something like extracting a chunk of code into a separate function is not a task that needs a proper name. It's just something that comes naturally once you get into a mindset of always making things better, or as we say where I work: "suck less." It's getting into this mindset that takes the most work. If every time I deploy code it sucks less, or even just on average, that's good enough.
Refactoring is compound interest for maintainability. Once people buy into this everything starts getting better.
I also believe that you should never ask permission to refactor - just do it. A gardener who's task is to mow the lawn shouldn't ask permission before pulling a weed just because it's outside the narrow scope of the task at hand. Likewise a programmer should not ask permission before refactoring code (excluding large, time consuming refactors).
Kind of like Effective C++, More effective C++, the old Win32 Charles Petzold book, GoF, etc.
To me, it was a classic, and much appreciated it as that was also when the whole TDD thing took off.