Over the last few years, my experience of being a software dev has changed massively. I've not changed the language I code in, I've not changed what I'm trying to achieve, the change has purely been a move from coding on my own, to coding as part of a team.
Previously, my number one concern was "Does this code produce the right end result". Today, I balance this with the need for clean and reliable code. Now that I work as part of a team, I see that code needs to do more than just work. It needs to work reliably, it needs to be resilient in the face of unanticipated change, and it needs to be trustworthy in the eyes of my colleagues.
This should be the first of a couple of blog posts looking at different ways I'm striving to write resilient code. My four planned posts are:
- Single Responsibility (this one)
- Command-Query Separation
- Tell Don't Ask
- The Law of Demeter
If anyone can suggest anything to add to this list (Open-Closed principle and Design By Contracts are on the edge of my mind somewhere), please let me know in the comments below.
More...