IN THE BEGINNING THERE WAS DESIGN
This is part one of the series of blogs going through the book “Understanding the 4 Rules of Simple Design” by Corey Haines in the context of a Software Engineering apprentice.
Let me introduce you to the mind of a novice software engineer who feels adept in terms of algorithms, data structures and different dev-ops technologies.
Whenever a problem comes up your first thought is to try and find the fastest and cheapest solution. If I get a simple problem I try to do it with constant complexity, A linear one a linear solution and a quadratic one a less than quadratic solution using dynamic programming if possible. As long as I solved the problem I was happy especially if the solution performed well in terms of its complexities.
Eventually, my position on how to code was bound to be challenged, especially if I was going into the industry. One World Coders is the first place where I came across this. The emphasis here is not only on how well your code performs but does it stand by the rules of Simple Design.
You’re probably wondering what and why the emphasis on these rules. Well here is a scenario, you are an engineer and have to make adjustments or add features to code that was written by someone else. It performs extremely well it is fast and uses minimal storage in terms of its functionality. But you can not seem to pinpoint where to make your changes. You delete a single line and it stops working you, You add a line it stops working as well, You try to read it to understand it but you can not and not all its features are working whatever you do you are likely to cost the company thousands if not millions of dollars. I assure you, you do not want to put your future self or anyone else in this position.
With this, the rules of Simple Design are important to consider, besides it is always cheaper to fix a problem at the design stage than at any other stage.
Well to not hold back the veil any longer the Fours simple rules of design are:
Tests pass
Express Intent
DRY coding (Avoiding duplications)
Making the code as Small as possible
From someone who has coded for a while, it seems almost obvious that the above rules should be followed.The question is to what extent.
TESTING
What I have come to learn with the TDD (Test driven develoopment) model is that test the simplest and most minuscule functionality in your code even before you write down your own algorithm. You will find that the testing process will lead you to the pattern that forms your solution algorithm. This ensures that all the functionalities are working as expected and enables you to spot redundant code losing out any excesses.
EXPRESSING INTENT
Your code should always express intent in terms of naming the files, folders, classes, methods, functions and variables. Imagine how hard it is to find the a method tosend messages in your texting app if you named it something off like say_hi. If you were ever to come back to try and fix this you would probably give up looking for it if you have to scheme through pages of code
DRY CODING (AVOIDING DUPLICATES/REPETITIONS)
The term coined in the book The Pragmatic Programmer has its meaning directly represented in its name Do Not Repeat Yourself. If you have any functionality that you find being repeated such as a simple loop try and represent it as a method or function.This reduces the length of your code and the amount of work that you have to do. This should also include knowledge topology for instance a loop may be used for different reasons within the code but any chance you get to reduce this to a single feature/method/function should be taken
SMALL
Having your code being as small as possible makes it easier to go through and understand. This will reduce how tedious it is to spot bugs and to mould new features for the code. To do this you handle and remove vestigial code and duplicates. You can also look for the smallest unnecessary features within the code.
These rules can help your code be easier to work with, and change in the future. You will never have to build your code to guess the future but to adapt to it easily without any issues.
With these rules, you have gotten the basics of the rules of Simple Design.
Side note as you process this, remember we are also trying to achieve the simplest solution possible which is way better for any future changes and adaptations.
