The Pyramid of Coding Principles
There are a lot of processes that need to be completed and technical issues to be tackled to make a fully functional application. One of the things we can do to make our apps right, work, and faster is to implement the coding principles.
With years of experience working in software houses. I’ve been dealing with a lot of clients' applications that are barely maintainable.
So what’s wrong and how am I identify those apps as “barely maintainable”. If we are used to implementing coding principles into our application then most likely we can identify whether an application is bad or good from the codebase perspective.
These are the coding principles I used to use for the majority of my application.
Make It Work
The first rule before implementing any principle is we need to make sure our application works first as fully functional apps. What’s the point to have a fully maintainable codebase if the application itself can’t be used by the users at all.
Because in the end, the user doesn’t care whether the application is built on a top super server and developed using the best coding principles. The user just cares whether the application work or not to help their needs.
After the application is working as it is, then we can start working on implementing any coding principles that suit our applications.
You Aren’t Gonna Need It
Oh silly me, back in the day I was a junior software engineer I used to keep unused code, components, comments, etc just because I thought I will gonna need it later.
But the reality is, I never use that piece of code for weeks or even months.
First of all, we need to exclude any unused code from our main codebase, and if you insist to keep it because “you will need it later”, then just you version control system properly.
If we remove a code from our codebase, there will be history in the VCS and we can easily roll back or copy-paste the old code without keeping that code forever in our codebase.
In the end, the bigger codebase the bigger effort needed to maintain.
Keep It Simple Stupid
Ya, you heard it right. Don’t make anything more complicated as it is.
If we can make a process more straightforward then why would we bother to make that thing more complicated?
The easiest benchmark is our code changes lighten the server load or burden it and is our codes are maintainable by others or not.
If our code did not pass those benchmark then it means our codebase is too complicated and needs some refactoring. We can easily refactor the code using an open-source code critic, or code smell libraries to automatically make a code changes suggestion for us.
Remember the simpler the codebase the easier to maintain it and the simpler the process the less server resources will be used to handle the process.
Don't Repeat Yourself
Have you ever needed action or process that need to be done before every action, such as we need to make sure the user already login before it can access any user pages?
As you can see from the above code, I try to call is_user_login? in every controller action, and it should be optimized, because if we need to rename the method or change the logic, etc. This kind of method will be inefficient, but we can fix it.
We can create a constructor/middleware/before action that will call is_user_login? function every time one of the functions is being triggered.
You can see the difference after we refactored the code, the code will more maintainable and readable.
But bear in mind there are different approach in each programming language or framework to handle this case, so be wise and be flexible.
Clean Code
I bet you already heard many times about the clean code principle, and I want to tell you that clean code is a more like general principle.
The first rule of clean code is always to create a clear and concise code with a clear intention for the example is whenever we create a function, method, module, or variable name.
The name should represent its value or its logic as a whole and don’t forget to follow the existing code conventions because every programming language has a different approach.
I can’t write all of them in this article but if you are interested to explore furthermore about this topic, I highly recommend you to read this book https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882
Standing On The Shoulder of Giants
Utilize industry standards and mature technologies instead of building our own standard(s).
There are a lot of resources that already discuss how to create a boilerplate code with some tools, how to code with best practices with a specific tool, and so on and so forth.
I highly recommend you to follow the existing conventions, best practices, and standardization because we should not build any solution on top of such standards unless it gives us a competitive advantage
Boy Scout Rule
What is one of the main causes of the decrease in programmers’ productivity?
Yes, you are right. The main reason for our decreasing productivity as time goes by is when we have to maintain or continue the development of a project that’s built with a messy code.
Surely it will slow us down when we have to deal with someone else’s messy code or even our messy code (shame of us).
So how to deal with it? We can use “The Boy Scout Rule” as uncle Bob said in his book “Always leave the campground cleaner than you found it”.
So whenever we have to develop new features or maintain the existing features, we have to always add some improvement to our codebase. It doesn’t have to be a major fix, we can do a minor fix too. For examples are renaming variables, removing whitespace, making the code have the same indentation, and so on so forth.
Make It Fast
After a tackle the challenge to make our code more maintainable, optimized, and readable, then we can be focusing on making our application faster.
Whether it optimize the database indexing, modify the architecture, add cache strategy, and so on and so forth.
Lastly, The mark of a great craftsman is actually understanding that refactoring costs time and it’s better to balance all the principles concurrently. Don’t just do YAGNI only for phase 1.
Meaning using these principles at the same time within each iteration/milestone, but allocating the least time/care to items at the bottom of the pyramid.
Otherwise, you end up with a mountain of technical debt even before you realize it
you can check one of my articles for reference https://medium.com/life-at-mekari/why-does-my-website-run-very-slowly-and-how-do-i-optimize-it-for-free-b21f8a2f0162