15 March 2017, by Chris Arnott
This post is a quick overview of patterns I have picked up over the years that I aim to use when coding and usually end up pointing out in code reviews.
These aren’t hard and fast rules, but to me, this post forms an extension to Uncle Bob’s clean code (which you should read right now if you haven’t already!).
2 June 2014, by Hereward Mills
Writing good code is hard.
We all have an idea of the ideal codebase: clean, SOLID code; fast, easy to maintain unit tests; well structured integration tests… The list goes on and yet the reality of most projects falls short of our high expectations in some way.
A project I work on has a lot of technical debt. Some of the problems are large structural issues that are just too risky to fix. Others are really tiny niggles: commented out code, spelling mistakes… As a team we try to tidy up as we go along (Uncle Bob’s Boy Scout Rule) and we have made some progress in cutting back the weeds: classes have been tidied, methods refactored and tests added. Progress, however, is slow and away from the bits of the code we tend, the undergrowth is still thick and impenetrable. Time to put away the secateurs and get out the bush knife.
Back in March I issued a challenge to Softwire to clean up their code; to take up a challenge over Lent instead of giving something up. Forty days, forty fixes: small or large, to your own code or someone else’s: the only requirement was to do a little bit every day for forty days. Surely that would be achievable? It could not be that difficult.
Turns out: writing good code is hard. Writing a little bit of good code everyday for forty days is really hard. No one completed the challenge without some degree of cheating: doing fixes the day before, the day after or even pulling in two year’s worth of gradual refactoring as one of the forty days. For some day to day life got in the way: holidays, illness and childcare all took their toll. Many of us found it difficult to keep our fixes small enough (an hour is not that long for all but the simplest of fixes) and others just found better things to do with their time.
This does not mean the ‘experiment’ was a failure. Over the forty days a lot of things were fixed that might otherwise have been left undone: forms were commonised, application internals overhauled, lots of unused classes and files were removed, tests were added, small improvements suggested, classes greenified and over 100,000 lines of never-run, broken tests were removed from one legacy codebase.
Forty days of fixing was not easy; we struggled to keep motivated and make those fixes. But we should not be discouraged: every fix we completed was an improvement on what was there before. The code become clearer, the cruft was removed and a test was added. Each fix was something we should be aiming for every day in both our professional and personal work. Next time you have a spare few minutes or are embarking on a change to an existing system remember this: what can I do to make this codebase a slightly better place for everyone?
10 September 2013, by Simon Wilson
Every Friday lunchtime at Softwire we all get lured into a meeting room with the promise of free food, and one of our colleagues gives a talk on something they’ve been working on recently.
We filmed this talk on TDD and clean code, by David Simons, so that others can enjoy it too.