Forem: Yeferson Guarin

Take care of the quality of your software and do not fail in the attempt: Part 2

Yeferson Guarin — Wed, 13 Jan 2021 22:55:40 +0000

In the last post I told you about the quality criteria to take into account for the project development. Today, I will continue to tell you about this so you can be a more professional developer. Before continuing, I remind you of the six quality attributes:

Functionality
Reliability
Usability
Efficiency
Maintainability
Portability

In this post I am going to tell you about the last three.

Efficiency is the ability of the software to respond to a user request with the appropriate speed. You may think that I mean "the application responds fast", but this would be ambiguous, since how can you determine what is fast and what is not? At this point you must take into account what is an adequate response time for your user, as well as take into account the norms or standards that exist about this. You as a developer can help the software have adequate response times by correctly managing hardware resources, using good development practices, such as using efficient ordering methods or long-proven industry libraries.

Maintainability is the ability of the software for the user to invest minimal effort to maintain or improve it. Perhaps this attribute you understand better with examples. Suppose that in your work you were assigned a new requirement for an application that was developed by a person who no longer works for the company. The first thing you are going to do is check the code to try to understand it, if the code is easily understood by you or by another of your colleagues, we could say that the software is maintainable, but this is not enough. Now, suppose that you are going to start making the request, but you find that to do it, you have to change many things and that when you move something, the application begins to present unexpected effects, in this case we would see that the application cannot be " easily modified "and it is" not very stable ", so in this case we could say that the application is not very maintainable. Finally, suppose that you have finished the adjustments that you requested in the requirements, now you must do the corresponding tests to validate that the change you made has been correct, if the application is modular, doing these tests will probably be easy, in this case we could say the software is maintainable. In general, to determine if software is maintainable, we must ask ourselves how understandable, changeable, stable, and testable it is.

Ultimately, portability is the ability of software to be transferred from one environment to another and function in it. This means that the software can be installed / executed in different environments, for example that it can run on Windows, Linux or IOS, if it is a web application, that can be viewed in different browsers, or if it is a mobile application, that it can be installed on Android or IOS. It also refers to the ease of installation, preferably having an assistant to perform the installation and in each step it is clear to the user what he is doing, always avoiding that he makes decisions that affect the environment where it is executed and does not generate conflicts with other system. Portability also refers to the ability that the software can have to be used instead of another product, for the same purpose, in the same environment, for example, a mailing API that can replace another API that does the same. same.

It is important to clarify that the software does not necessarily have to comply with 100% of these attributes, it all depends on the requirements, needs and even the budget of the client, but if it is important that when you make the software, you have all this in mind, think in the impact it will have in the future, since the conditions and needs of the environment and your client may change

You can read the first part here

Take care of the quality of your software and do not fail in the attempt: Part 1

Yeferson Guarin — Tue, 15 Dec 2020 05:46:50 +0000

Today you listen, you read, you see many talking about this, they give you hundreds of tips, recommendations of what you should and should not do, but do you really know how to evaluate if your code is of quality or not? I am going to tell you what are the criteria that you must take into account, regardless of what language or tool you are using, since these are part of an international standard. Software, like any product, has quality attributes that can be objectively measured to determine whether it is a good product or not. There are six quality attributes:

functionality
Reliability
Usability
Efficiency
Maintainability
Portability

In this post I'm going to talk to you about the first three, all so you don't get bored (Yes, I know, I'm the best) and in the next post I'll talk about the remaining three.

The first three quality attributes are related and very end-user oriented. The functionality attribute is very simple, this attribute refers to the ability of the software to do the tasks for which it was created, nothing more, nothing less, something that seems trivial, but that many times developers because they are "too creative" not We comply, maybe the user wanted a calculator that would add two numbers but we make a calculator that obtains the square root, divides, makes derivatives but does not add or does not do it well, believe me, the user first needs you to do what he wanted you do, the rest is addition. That can generate value if you first comply with the fundamentals.

Reliability is the ability of the software to maintain its operation under normal conditions, that is, that the software works continuously and controls common errors, such as validating that only numerical data types are entered when you try to do a sum in the calculator or avoid doing divisions by zero, or at least show an error message when something unexpected happens, the important thing is that the user understands that something happened and has the possibility to continue using the software if possible or notify the error, write it in a log file and make a secure close

Finally, usability is the ability of the software to make the user invest the least possible effort in its use, for example, that the user does not require many clicks to be able to navigate to an application option, that the application is intuitive and easy to understand the purpose of a functionality. This may seem a bit subjective to you, but there are certain rules that give you guidelines to comply with this, but the most important thing is to do tests with your users, to be able to receive feedback from them, because each group has its peculiarities and culture has an important influence

As you can see, validating the quality of your software is not something from the other world, it is something that you can measure and evaluate and taking it into account will have a positive impact on the end user, which you can make very happy and you can even make your user enjoy product.

You can read the second part here

Something you should know if you want to be a better developer

Yeferson Guarin — Tue, 01 Dec 2020 00:23:37 +0000

Hello friend, I hope everything is going well for you. Today I want to talk to you about a very important topic that you may have overlooked because the day-to-day eagerness did not give you the space to pause and reflect on it, but don't worry, it is something that almost all developers have past, but you learn from mistakes and I can help you to make them as little as possible. What I'm talking about is the SOLID principles, 5 principles that every good developer should know and apply in their day-to-day work. I will quickly explain what they consist of. The SOLID principles are a set of principles that guide us to apply good practices in the developments we make, seeking that our products have a very high quality (I will tell you about these quality criteria later)

Each of the initials of these principles has a meaning. The 'S' refers to "Single Responsibility Principle", that is, to make our developments in a modular way, where each module, function, library, component, as you want to call it, should only have one responsibility since with this we could understand more quickly makes our code and modify it without generating side effects, or replace it with another more efficient implementation.

The second principle, the 'O', refers to Open / Closed, this principle tells us that when we make a component of our development, it should be open to be extended, but closed to be modified (speaking of its inputs and outputs) , since with this we will guarantee that in the future our code continues to be compatible.

The third principle, the 'L' refers to the 'Liskov Substitution Principle', this may scare you or sound very bombastic, but this principle simply tells us that classes that inherit from other classes should be able to be replaced by their base classes without alter the correct operation of the software, this allows us to create different implementations of a functionality and to test them without having to modify the code.

The fourth principle, the 'I' refers to 'Interface Segregation Principle' another name that may scare us a bit, but in practice it is easy to understand, this principle tells us that we should make small and concrete interfaces, this In order not to force our components to implement functionalities that have nothing to do with their nature, it would be preferable that our class implements several small interfaces.

Finally, the fifth principle, the 'D' refers to 'Dependency Inversion Principle', once again, a name that may scare many, but when you understand its philosophy and its power, you will evolve as a developer. This principle tells us that our components should not depend on implementations (classes that implement interfaces or abstract classes), but on their abstractions, this in order to minimize the dependency between components and therefore have a low coupling, which will allow us make our software more extensible, maintainable, bearable among many other benefits.

As once, these principles are very important in the development world and are widely considered (although there is no shortage of criticism), so much so that it is almost a requirement that every experienced developer handle them and have the criteria of how and when to apply them, as well. I invite you to continue delving into this topic, which is sure to hook you.