Posts
-
Be bold
-
Rule of three
-
Exceptions are meant to be exceptional
-
Is no QA the way to go?
-
Avoid using switch-case statements
Are you bold enough?
We can all be a little bolder sometimes.
Being bold is often what holds us back. As children we’re taught to “look before you leap”, which is great as a child, yet risk taking is an important part of learning.
Read More »Sometimes called “1, 2, refactor”, the “rule of three” is code refactoring rule of thumb to decide when a replicated piece of code should be replaced by a new procedure. It states that the code can be copied once, but that when the same code is used three times, it should be extracted into a new procedure.
“Refactoring is a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior” ― Martin Fowler
This is a rule that has really served me well in recent years when I’ve come up against challenges on when something should be refactored.
Read More »Now and again I come across patterns that I see in codebases and pull requests, especially when the project or team is maturing. This covers one of them.
I’ve found that developers that have picked up more advanced patterns and become familiar with a codebase that is full of compromises made during it’s organic growth, they begin to apply those same patterns to solve the problem with a broad stroke, sometimes at the risk of not fixing the underlying issue.
One such pattern is try-catch. Once the power of a try-catch is learned, it starts being used everywhere. I’ve seen the whole contents of a method wrapped in a try-catch, catching anything it can. When all you have is a hammer, everything looks like a nail.
Read More »There’s no getting away from it, quality is a whole team responsibility. If you’re aiming for Continuous Delivery, then you’ll recognise one of the core principles of Continuous Delivery is to “Build quality in”.
If you’ve heard of lean development, then you will no doubt have heard of the principle of “The Toyota Production System” of “building quality into” software.
It’s inevitable then, that there will be a tension between filling that “QA” role and building a team of “T-Shaped people” who treat quality as a first class citizen. Read More »
Recently I’ve been asked why switch-case statements should be avoided, it turns out to be a pretty common question, and although I’m pretty happy with the reasoning of switch statements being less readable and maintainable, I had forgotten the source of this wisdom so I thought it would be worth revisiting.
Read More »subscribe via RSS