Ir al contenido principal

What we should do?

A good programmer is not made by how fast he or she can solve a problem, but someone who can help to maintain a whole system  by committing the best practices he or she has been taught.  In this case, what I am referring to is that we are used to hear or think that someone is a good programmer because they  solve first an exam or even because they know all the library of a language, but  that is not right.

There are many elements that can be related to a programming language, but a good practice should be the main one we are searching for ( besides the client's desire). In this case we should consider that everything that we are doing will be running on someone's computer or server and that  there have been many years where people have develop this science up to the point where we have ground rules to understand it or to make it better.

As we have seen, the gang of four has develop some pattern  elements to create a whole program, but these ideas are related to all software engineering theory that we have seen. As we can understand from Pressman's book, there are many steps to follow as a software engineer, and there are many rules we should follow, all of them depend on our client and on our user.  And as we have learned,  if someone has already created something, why not to use it in our program.

In this case, what Edward Guinness has developed is an acronym to  summarize the basic principles on object-oriented languages. It is important to mention that it might apply to other languages but not as a whole. He has developed SOLID principles, where they look forward to make object-oriented programming less redundant, easier to understand and based on the user's needs and the architecture design paradigm.

In the case of architecture design, the main idea is to understand what the user needs, what we have built to solve its problem and  how all the elements are connected. When we develop something we need to follow a process that will give us all the activities or requirements of a client, and with that we can build something.  As we have learned, the way to solve these actions is to develop a plan  and to test whatever we find in our way, but the correct way to develop is to define the smallest activity and  from that element  and all what it needs, to create modules and solve the problem.

Following the last idea and connect with the SOLID principles, we now can understand what we have been doing and to make it better for everyone. We might live forever, o we might not, so we need to create something people understands at first sight and that they will make it better, not to destroy it.  I consider that principles such as SOLID should be ground rules to specific programs and that we should test them, as students, for better understanding and to really learn their use. We have learned many rules and we might forget them but if we understand why we need them we might never forget them.

Comentarios

Publicar un comentario

Entradas populares de este blog

What we should do?

Nowadays we think that computer science is a big factory, where even though that our offices are fancy and do not look like an office, we just program to generate more code, so get more money.  In this case, we think that coding is just an alone activity that does not include more activities, such as the whole software engineering process or something like that. As we have known,  there is a process that we should follow to generate code in a more efficient way and something that our users really need and when they need it. As time goes by, there was a point where we thought that cascade method was the ultimate idea and that its use was gonna stay forever and that its use was something that we will need to use for a while. We might get this idea from other engineers where they just get the requirements at one point and to change just for special moments accept the change. The basis is of this idea is that these type of engineers have got just enough time to really see...
Publicar un comentario
Leer más

A kid? A kid just broke my program?

LNowadays is common to think that anyone can use your software. In this group of anyone, there is the group of people who know and people who doesn't. We, as software engineers, need to take I to consideration both sides because just anyone can get access to  information that might not be for them. A clear example of that is Netflix, which includes a restriction for kids, or YouTube and even Facebook. To get to that point we need to think in our users,  and what they could do. In software engineering there are many methods to create these elements and to really analyze if they are really necessary restrictions or add-ons. On the other hand, we need to take into consideration the data that we are managing and to really send it in the correct way  to avoid people who steal our information even though that we are not that famous or important. In the case of the movie  War Games, set at the begining of the internet connection as a service, who anyone can access just by...
Publicar un comentario
Leer más

“God is in the details.”

When we talk about architecture,  what we normally think are buildings, their characteristics, how they make beautiful our city. We do not think about the time architects take to build something big and beautiful, and how changes affect the whole project.   We know that architecture is something that has been evolving since the beginning of time, where people tried to build what they needed. But also, this science has been evolving and the way people build takes more time and there is science behind every decision they make.   When we think about the software we do not identify this process that we need to follow to create something functional, useful and that will be used, we think about the algorithms or complexity of the problem.  We are not used to planning, hear the necessities that people have and even the methodology that we should follow to keep our software for future generations.   I consider that this practice...
Publicar un comentario
Leer más