software

Recommended to me by: Sam Livingston-Gray

Refactoring is the art of improving software through a series of small steps without changing how it functions, specifically without introducing new bugs. In an attempt to make it closer to a science, Martin Fowler defines a series of recipes to make safe changes, a series of “code smells” that indicate that change is needed, and adds examples and stories along the way.

I bought the book through my job because I was responsible for a whole menagerie of semi-abandoned applications in varying states of disarray, and I wanted ideas and support for how to improve them. The main benefit I got directly from the book is the idea to take very small steps, and to keep checking whether the application still works correctly at each step.

Indirectly, I got a lot of other benefits. I started a weekly study group where we went over 5 pages or so of the book each time, sharing things we agreed and disagreed with and examples from the code we were working on. In theory people were reading ahead, but everyone is busy and I made it welcoming whether people had read the week’s section or not.

It was hands-down the best part of my job, connecting with coworkers outside of my small group, learning together, and hearing how people were improving their code using the techniques we discussed.

The book’s examples are in Javascript, which made them harder to read for those of us working in Python and Ruby. Those of us who had been programming for years had an easier time with the book than the people who were just starting out. In particular, one person pointed out that it was difficult to tell the difference between unfamiliar programmer lingo and “funny” asides about methods gathering at the water cooler to share gossip.

Recommended for more experienced programmers who want a deeper understanding of refactoring. Read it with a group if you can!

Available at Powell’s Books.

Subtitle: A Practical Guide to Object-Oriented Design

Recommended to me by: Sam Livingston-Gray

This book creates and then refactors (edits to improve) code to generate the “99 Bottles of Beer” song. (When I was a kid on field trips, we started at 100 Bottles.)

I read most of this book in 2015, but didn’t finish it, so didn’t add a post for it here. Apparently the initial “Shameless Green” code (straightforward code that makes the tests succeed) stuck with me, because I mostly reproduced it in the half-hour recommended to attempt the problem before reading the rest of the book.

There are lots of great points about object-oriented design and recipes for refactoring. The Ruby code that results at the end is elegant and easy to modify, although its readability benefits from the step-by-step walkthrough to get there. I will probably refer back to the book for refactoring tips when faced with Ruby code to improve.

Recommended for people wanting to improve their object-oriented coding skills, especially in Ruby. There are now editions available with code examples in PHP and Javascript as well, and the beverage can be beer or milk. Now I’m curious to see their code that generates the different versions of the book!

The book’s page and Sandi Metz’s website.

Available at SandiMetz.com.

Subtitle: An Agile Primer

Recommended to me by: Sam Livingston-Gray

I first read this back in 2012. It struck me as friendly rather than condescending this time, which is an interesting shift.

In 2012 I was just learning Ruby and focused on deciphering the example code as I read. Coming back to it after having programmed in Ruby for three years, I could read the examples fluently and focus more on the general points in the book, even though I haven’t looked at Ruby code in a while.

Some points that stuck with me this time:

• The purpose of design is to allow future changes in code, since requirements and circumstances keep changing.
• In object-oriented design, pay attention to the messages passing between the objects.
• Each object should have a single responsibility. (I’ve seen a downside to this, where you have to chase through a mass of fine-grained objects to find where something is actually done.)
• Manage dependencies to reduce risk. An object should depend on objects that change less often than it does.
• Inject dependencies, use Ruby’s duck typing: Send in an object as an argument that responds to the needed message
• Delay design decisions until you have at least three examples of what a class needs to do. (Two, if pressed.)
• Good design is TRUE: Transparent, Reasonable, Usable, Exemplary
• DRY: Don’t Repeat Yourself.
• Law of Demeter: Don’t chain calls through many objects, since that entails knowing too much about the insides of other objects.
• Isolate risky bits of code inside a wrapper, so they can be improved easily later.
• Test an object’s public interface (messages it responds to), and command messages it sends (messages with side effects).
• Use Ruby Modules to share code and tests.

Highly recommended as a guide for both general design, and how to write maintainable, flexible Ruby code.

The book’s website and Sandi Metz’s website.

Available at Powell’s Books.