Programming design patterns is something I’ve wanted to blog about for a while. They are fundamental to being a programmer. Knowing a multitude of design patterns and knowing when to apply them separates the true developers from the “code monkeys.”
For example, I have inherited a project in the past where the initial developer had no concept of architectural patterns. 10 years on and a few more developers later, the underlying codebase had become a mess of different developers doing things ‘their way’. This was more than likely due to a lack of a fundamental structure which should of been in place from the get-go.
Having experienced the work place that the developer had previously been at, deadlines were indeed tight. To make things worse, there was usually more than one project going on at a time. However, It is common place for deadlines to be tight in the Software Development industry, so getting the job done is a key part of the job to keep your employer happy.
This does not mean that all care should be dropped from the code you are writing to ‘get it done’ as getting it done and doing it right are very dissimilar. This is where knowing programming design patterns is key. They really don’t take that much more of your time initially and they will save you and future developers time in the future!
If the initial developer put a system in place for managing the database, front end and business logic (MVC springs to mind); all future developers would likely follow the framework. Thus resulting in a unified codebase with a clear indication of what is going on behind the scenes.
This topic is more of a by-product of knowing your design patterns. Knowing when implementing ‘pattern X’ solves ‘problem Y’ is likely going to lead you to down the path of good programming practice.
However, there are some key principles that should resonate in your head as a programmer, off the top of my head they are:
- Don’t Repeat Yourself (DRY) – Not duplicating code, reuse code by breaking it up into functions/objects.
- SOLID – An OOP principle used to help define responsibility for classes. It can be seen as the most fundamental practice a programmer should know when working in an object based language.
- KISS – Keep It Simple, Stupid – Is a funny one by all means but a very good principle. Don’t over-complicate your classes & functions. Break them down into bitesize pieces and chances are you’ll separate your logic and dependencies in the process.
In the project described earlier, it basically broke all of the above rules. Just to give an indication on how bad things were… There was a .txt file named “code to paste.txt”. Inside of it were about 4 different sections of code that had indeed been copied and pasted around the codebase in numerous locations.
Breaking up code into reusable functions is programming 101 – Don’t Repeat Yourself (DRY)!!
I have not got a set list of the patterns I am intending on blogging about, instead I am just going to write about ones I feel like writing at the time.