This week we are talking through chapter 5 of Pragmatic Programmer - In a nutshell we talk through what it takes to make code that is flexible and can take the cold realities of the real world. Tip 36: Minimize Coupling Between Modules Tip 37: Configure, Don't Integrate Tip 38: Put Abstractions in Code, Details in Metadata Tip 39: Analyze Workflow to Improve Concurrency
John: Welcome to Iteration: A weekly podcast about programming, development, and design through the lens of amazing books, chapter-by-chapter.
Quick update: Sketch Color Spaces
Life doesn't stand still. Neither can the code that we write. In order to keep up with today's near-frantic pace of change, we need to make every effort to write code that's as loose—as flexible—as possible.
Organize code into modules and limit interaction between them. If one module gets compromised and has to be replaced, the other modules should be able to carry on.
Avoid coupling by writing shy code and applying the law of Demeter
What is shy?
Implement technology choices for an application as configuration options, not through integration or engineering
Program for the general case, and put the specifics outside the compiled code base
Exploit the concurrency in your user's workflow
This example was really good so I'm copying it from the book:
making a pina colada
1 open blender
2 open pina colada mix
3 put mix in blender
4 measure 1/2 cup white rum
5 pour in rum
6 add 2 cups of ice
7 close blender
8 liquefy for 2 mins
9 open blender
10 get glasses
11 get pink umbrellas
12 serve pina coladas
Think about how imperative this is. First do this... then do this...
BUT, think about what you can do concurrently: 1, 2, 4, 10, 11. These can happen all at the same time and up front. Next, 3, 5, and 6 can happen concurrently afterwards. These would be big optimizations