I'm currently working on a system that has managed to build up an amazing amount of technical debt in just a short amount of time.
I can understand why and how this happens, but there are some things that I believe come from a flawed perspective. And that perspective is your own. It is dangerously easy to write code that makes sense to you but no one else. The worst part is that since you have your own perspective, your own mindset, it is very hard to know when you're in the wrong.
For example, I'm currently working with a system that handles bookings, the entity or data object has a field called
bookingTime makes sense, right? Well no, no it doesn't. What really is a bookingTime? It could be the time the booking was made or it could be the time the booking is supposed to occur.
Well, what sense would it make to have
bookingTime point out the time the booking was made, surely that isn't all that interesting, except maybe for the BI people, it must be the time when the booking starts, right? Well no, in this case it isn't.
But my point isn't to rant about my current project, no, what I want to rant about is how deceptive names can be, especially in context. The context may give you a hint what is happening. And this is ignoring the fact that we're in an object called booking and repeating the name booking.
So how do we combat this? My suggestion is have descriptive unambiguous names,
bookingTime should be
placed, preferably with a field called
start. If we have that, then we have enough context.
This gets harder for those of us who don't have english as our primary language, sure we can talk and read english, but the nuances are sometimes lost to us.
There are two rules that help avoid this.
Rubber Duck programming
And my favorite quote:
“Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live”
― John Woods