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.
Leave a Reply