Best practices are the way to go
How important is it to follow best practices? In development it is crucial to produce a high quality software. Let me tell you why in this article.
Best practice, standards and processes
If I take a step back in time and try to think about my first projects, I can find a long list of mistakes I made that allowed me to form myself.
Software development is an activity that, fortunately, is now accompanied by numerous best practices and many standards, agreed upon by influential developers, but not only that. There are many programming languages, many patterns that are used and many techniques to solve problems with digital technologies.
Fortunately, this whole ecosystem is controlled by a few rules of good conduct that those who produce quality softwares follow very carefully.
Of course we too, like many other teams, have defined our process and have our guidelines, which work for the flow we have established internally, without ever transgressing general best practices.
In this article I want to cover some of these rules that my team and I use during the implementation process. Let’s begin!
Don’t write code not yet necessary
As you can see from the figure above, the development process is a cyclical and continuous action.
Writing code that has not been analyzed or, worse, that has not yet been requested, could be a huge waste of time. It could also be harmful, introducing unexpected errors.
All of this requires extra effort to test and maintain. So it is very important to stick to the requirement.
Avoid duplicated code
Very often it happens to write functions with a very similar code to the one already written somewhere else in our project.
It is very important to know how to identify portions of code and encapsulate them in reusable models or functions. This also saves us from introducing potential new bugs.
Each function must be tested with unit tests
The previous two points have already introduced the concept of testing. Writing tests and writing application code are two sides of the same coin: if we cherish our code, then tests are part of it. I also talked about it in another article.
The most suitable approach is TDD (Test Driven Development): writing tests well before writing the functions enables us to thoroughly analyze the requirement, and therefore we will only write the necessary code (respecting the first point).
Writing code without testing is pure incompetence and it is also dangerous, kind of like running a red light.
Let’s imagine a software that manages, for example, the automatic driving of a car. Or, again a software that manages an aircraft’s control panel. If this code isn’t tested, this could lead to severe consequences.
Actually, not writing tests is a huge act of irresponsibility.
Writing tests means having high code coverage
Code coverage is certainly one of the most important metrics to define how many lines of developed code are crossed by automated tests.
One must be careful though: if the code coverage is high, this doesn’t mean that tests are written properly or the code is secured.
Having this metric under control allows us to evaluate if the code is in bad conditions, when the coverage is very low. But, if we diligently observe the previous point, then we shouldn’t worry about this.
On the other hand, I want to focus again on the concept of code coverage for those who use this metric as a guideline, giving an example.
If we have a function that needs to process data, we can write a test calling that function and simply check the success of the call: this test ensures that coverage is guaranteed, but it does not assure us that the algorithm that is implemented inside does what we expect.
This is why it’s very important to define all possible scenarios and the related test inputs. And expect the right output after its call.
Write as little code as possible
This point relies a bit on all the previous points.
Writing the necessary code to meet the requirements, and writing tests to verify its correct functioning, should be the approach to follow.
If we stick to these rules, the code we write will be the bare minimum. Furthermore, it is essential to pay attention to the quality of the produced code and, therefore, to review from time to time what has been implemented, to minimize the amount of code of our algorithm and optimize their functioning and performance.
Testing small functions is easy
And the previous point brings us directly to this.
If we had hundreds of lines of code in one function, writing a good test would be laborious, to say the least. However, writing a test for a small piece of code will be very simple.
Sometimes we need to rush, and hush is never a good advisor.
It is important not to neglect the optimization of the released code when we know that it wasn’t written in the best way: dedicating time to refactoring saves us from running into unpleasant surprises when things go wrong.
Optimizing database queries, writing simpler and clearer algorithms, reducing the number of unnecessary lines of code, making the code more comprehensible, are all things that can also be done at a later time, if we didn’t have any chance at the moment of release.
Of course, if we work in a hurry we will certainly lose the quality we want to get from our work.
Build and setup automation
At this point we should have understood how important it is to write good code along with a test suite.
Furthermore, in a modern software development process it is essential to create a build and set up process of our application, which can be automatic, functional and that has the right documentation for anyone who needs to interact with it.
This will allow us to be faster in introducing new programmers to the team and will drastically reduce the possibility of human error caused by distraction during installations.
Even when releasing the software we are subject to human error. And, even in this case, having a good automated and stable process will save us enormous waste of time.
I explored this topic right here.
Obviously all these practices are the result of a lot of common sense, which should be the first thing to keep under control when developing software.