When I teach evolutionary design with TDD, I often encounter programmers who don’t like all these little classes and all these extra interfaces. (Or all these little higher-order functions, if you prefer. It’s the same problem.) They worry that it creates a serious performance problem: deeper call stacks, passing parameters around, that kind of thing. They see memory being unnecessarily allocated and freed, memory becoming fragmented, and garbage collection happening at the worst possible...| The Code Whisperer
The name template method is a perfect example of a structural name: it describes the implementation rather than the meaning or purpose. This is what happens when programmers name things. The Problem We have standard workflows in our systems that programmers copy and paste from module to module in order to achieve some kind of standard behavior. Programmers call this boilerplate. Programmers tend to copy and paste this code because — They don’t see the duplication, because usually not much...| The Code Whisperer
I often hear this: Why should we extract this code? We only use it in one place. It doesn’t make sense to extract it. And yet, that same person wants to write tests for private (or otherwise invisible) behavior. That person is only hurting themselves: they want to treat this code like a separate thing (because they want to test it), but they resist extracting it because “it doesn’t feel right”. I have safely extracted numerous mini-frameworks and mini-libraries and my only regret rema...| The Code Whisperer
When you use relative include paths in your code, you bind each source code file to its current location in the project’s file layout. You relegate yourself to having to run it from a very specific location on the file system. You generally make it unnecessarily difficult to automate running your application (or its tests) outside your development environment, such as in platform-as-a-service environments. You make things like Docker not just helpful, but necessary. So stop doing that. You ...| The Code Whisperer
The entry point. Sometimes it’s main(). Sometimes it’s an extension point in some complicated framework. Most importantly, it is the border where Their Stuff runs Your Stuff. When I see entry points in other applications, I don’t see a lot of evidence of having thought about the design much. It becomes a kind of junk drawer for code. This happens especially when programmers are working in environments they don’t feel particularly comfortable in. (I don’t know where to put things, so...| The Code Whisperer
You might have noticed dependency injection gaining popularity in recent years. You might also have noticed some notable figures (I’m thinking of Kevlin Henney) who appear to be bad-mouthing dependency injection, when really they are simply taking away what they feel is a veneer of mystery from the term.1 I must say that I appreciate their doing so without pretentious use of the annoying word “demystifying”. (Simply ignore my own “demystifying” article by most certainly not clicking...| The Code Whisperer
This article describes an evolutionary design microtechnique. Specifically, it describes a weak signal that I use to guide myself towards more modular designs. I find it both simple and surprising: simple because it involves using a single value, but surprising because it involves a value that programmers largely recommend against using. I refer to the humble null. Yes: I have found a way to use null that doesn’t lead to heartache. I start with injecting collaborators through the constructo...| The Code Whisperer
. @cyriux : Imho the best paper ever written in software engineering: https://t.co/C6kmmj0ntl Parnas, 1972 — Alistair Cockburn (@TotherAlistair) August 1, 2014 I don’t intend to argue Alistair’s contention one way or the other, but I invite you to set aside some time to read David Parnas’ paper “On the Criteria To Be Used in Decomposing Systems into Modules”, which I have embedded in this article. Do not let yourself be put off by the quaint-sounding title. If you prefer, think of...| The Code Whisperer
You might call this title “clickbait”. Yes and no. Of course, I want you to read this article, but at the same time, there is no bait and switch here. I use test doubles (“mock objects”, since that term refuses to die) freely and happily. I use them prominently as design tools. I like them. I feel grateful to them. And even so, my design sometimes improves when I remove them. To paraphrase Ron Jeffries, this is good news about the improved design and not bad news about test doubles. H...| The Code Whisperer
Legacy code imposes an unbounded, inexact tax on the cost of all future features. This explains why I run events like Legacy Code Retreat, build training courses like Surviving Legacy Code, and write in general about improving the design of software systems. This further explains why I’m willing to accept the risk of people labeling me as an “over-engineerer”. What they label “over-engineering”, I consider managing risk. As part of managing risk, I like to test-drive changes to lega...| The Code Whisperer
Another “demystifying” article. Great! I know… bear with me. Of the SOLID principles, the Dependency Inversion Principle remains somewhat misunderstood. I’d like to help with that. I hope you’ll ask questions and challenge these ideas, so that I can improve this little article. I learned the Dependency Inversion Principle from Bob Martin’s article, the salient part of which states: High level modules should not depend upon low level modules. Both should depend upon abstractions. o...| The Code Whisperer
I wish that I could take credit for this article, but I can’t. Instead, I have to credit two people: Lasse Koskela and Miško Hevery. I credit Lasse for writi...| blog.thecodewhisperer.com