Wow, it’s been a while! Nearly nine years since my last blog post. A lot has changed since then – some for the better, some for the worse. I’d like to think it’s been the former for me, and what it means to be a professional software engineer nowadays. And as I embark on the next chapter in my career, I thought it apt to write a little about something that has had such a profound impact on me and the way I now look at the structure of computer source code.
So - clean code. Why does it matter, and why am I blogging about it? Well, as Martin Fowler once said, “Any fool can write code that a computer can understand. Good programmers write code that humans can understand.” More on Mr. Fowler in a future blog…
Many programmers are under the impression that if it compiles, it’s good to go, and on to the next feature. Who cares if code is not separated into logical units, or that the functions are small, or the proper boundaries have been implemented, or that the names are clear and reveal intent? As a result, the software inevitably loses its “softness” – it’s ability to change. It becomes rigid, and it takes longer and longer to implement new features due to the tangled mess.
I too was guilty of this many times. It’s not that I didn’t care about the code, I simply just didn’t know better, until, that is, I was introduced to SOLID. I was just as keen as the next developer to finish the feature and move onto the next thing. For example, a number of years ago I had a very popular iOS app on the app store that was a pretty good MVP (minimum viable product) that had enjoyed around seven thousand downloads! Pretty impressive, if I say so myself! Then came the time to add the next feature. To cut a long story short, this new feature (although nothing major) ultimately required way too much effort because the structure of the existing code did not allow for the new code to be written, and the app never got its new feature implemented, and ultimately disappeared off the app store as it had lost its market value without that new feature.
So, what is SOLID? According to the Wikipedia definition, “in object-oriented computer programming, SOLID is a mnemonic acronym for five design principles intended to make software designs more understandable, flexible and maintainable. The principles are a subset of many principles promoted by Robert C. Martin. Though they apply to any object-oriented design, the SOLID principles can also form a core philosophy for methodologies such as agile development or adaptive software development.”
I am thankful that I got the opportunity to learn about the SOLID principles, having experienced the benefits first-hand working on an iOS application for one of the leading banks in South Africa. Our codebase has become clean, and changes are implemented with relatively little effort due to the “soft” nature of the code.
But it took time. There was no smooth road to grasping all the principles. All too often others would look at some code and go “this is a clear SRP violation”, or “this violates ISP”, or “this code violates the Open / Closed principle”, and so on and so forth. But in the bigger context of the application it was sometimes hard to spot these violations, let alone find solutions to implement the code to remedy the violations. It was a bumpy ride. At the time it would have been useful to have a few concrete, bite-sized SOLID examples that I could refer to when I got stuck or was in doubt.
And so the idea for this article was born.
I have put together a very basic collection of Swift Playgrounds in a workspace (SOLID-Swift-Demo.xcworkspace) that can be found on GitHub. The playgrounds have been written in Swift 4.2.1 and XCode 10. The playgrounds are sorted according to the SOLID acronym in the workspace (01 Single Responsibility Principle, 02 Open/Closed Principle, etc.). Each principle has an associated playground page giving a brief explanation of the principle, how to recognize it in code, and the benefits of implementing it. In most instances there are two playgrounds per principle: an example of a violation of the principle, and in some cases an example of how one could fix the violation.
Maybe you’ve seen this type of thing on the web before. There are certainly no shortage of blogs and information on the web talking about SOLID, but the one I have posted on GitHub is the kind of thing I wish I’d had when I was first introduced to the principles.
