Understanding the SOLID Principles

The article called "Understanding the SOLID Principles" written by Edward Guiness is a brief summary that present us the definition of the "SOLID Principles" which is a set of principles that seeks to implement best practices in the creation of objects and classes in specific cases depending on the situation that is presented in the moment. The SOLID word is an acronym that is used to include the Single Responsability Principle (SRP), Open/Closed Principle (OCP), Liskov Substitution Principle (LCP), Interface Segregation Principle (ISP) and the Dependency Inversion Principle (DIP).

The first principle, the Single Responsibility Principle is a principle that focuses on the creation and verification of classes that should have exactly one responsibility which makes the classes more clean in the sense that the classes have only ONE well defined responsibility to do which is a practice that prevents that the modifications implemented in one class cause problems in other areas that apparently are detached of the principal responsibility of the modified class. 

The second principle, the Open/Closed Principle establishes that a class or function should be open for extension but closed for modification which show us that a class have to be constructed in order to be flexible and adaptable for the conditions that exist in the particular situation and that this class doesn't have to be internally modifiable from outside.

The third principle, the Liskov Substitution Principle on the other hand establishes that two classes can be interchangeable where these two classes have an inheritance link between them which provides a characteristic of flexibility to the function.

The fourth principle, the Interface Segregation Principle establishes that is worse to have an interface that to have to do a lot of tasks that many interfaces that have these tasks spread between them causing that the work accomplished for one specific interface is only the required work and the fifth principle , the DIP, establishes that a class have to use interfaces or abstract classes instead of refer to actual classes making with this that the dependency between the classes is diminished and that the class that implements the interfaces can use another interface in an easy way, which is related with the objective of the LCP in the way that the two promote the adaptability of the classes. 

After reading this five principles I can say that when programming we should be aware of them because they help us have a more structured code, cleaner and therefore more readable. Also with these techniques we learn other things about programming and we can make better programs with better quality.

If you're interested in reading this article, here is the link: Understanding the SOLID Principles.

Software Craftsmanship with Bob Martin

Bob is a software developer but he is also an architect, but what he do love is developing software. He thinks architecture is really worth doing, but he thinks architects should be also coders because otherwise they don't connect with the code decisions, "they don't connect with the keyboard", they just forget the code, and doing it that way the architect just forgets about the keyboard and it's really hard to manage a team like that.

The software craftsmanship according to Martin is the way where new people that are involved in the development world can learn from the more experimented people in the industry, the people that can be named a "master" or "mentor" which tasks are share all the knowledge, skills and tools with the newest individuals in the industry in order to create a system where the community can grow from inside being powered by its own people. This idea is really amazing because like Bob says, is very cool that being a programmer can be equal to be a lawyer or doctor, where all the knowledge is flowing from one person to another changing the way in that the community works, transforming it in an environment where solidarity and the teamwork can help to reach the individual and collective success. 

Some important things that the implementation of a system like this can bring in a positive way is that the professionals can learn the correct ways of developing some type of product, improving and honing their programming skills in order to change their habits, turning them into disciplined people concerned about the way how they work and think, moving this into the practice where it can see it reflected in the product quality. 

Now, the "Manifesto of Software Craftsmanship" is a good example of how very important advices can be written in a few lines of text where the important ideas are summarized in four principal advices that tell us like programmers that if we want to be better professionals following the software craftsmanship we have to be aware of helping others to do quality software, response to the change and add value to the product with it, strengthen the community of professionals with my contribution and search a good productive partnerships in the projects. 

One of the key points in here is to test in development, that gives them a lot of points. They run unit tests, every line of code is tested. It reduces danger.

Something really interesting that he explained is that all programers should know at least one funcional language, dynamic language, static language and logical language, in order to have a good knowledge of everything that industry may ask.

Nowadays there are dynamic languages like ruby or python that use this type of tests, and they're dynamically typed. What the author recommends is to learn as much languages as possible, that is, to be able to write code in that language, that gives many points in software craftsmanship, you improve your own skills and in that way you improve your craftsmanship. You should learn at least one dynamic language and one static and he thinks that everybody should learn Lisp.

If you are interested in listening to this podcast here is the link: Software Craftsmanship with Bob Martin

Is Design Dead?

Programming is an activity that involve a lot of dedication and passion because in most of the cases the fact of doing a good program from scratch is something that can be a really easy or difficult task, all of this depending of the person that it's in charge and its abilities involved in the planning and design of how to do the task.

Like Fowler (2004) mentions in his article "Is Design Dead?", that in the software development context exist to ways that the person in charge of developing a program can choose which are "evolutionary design" and "planned design", where the first means that the design of the system grows as the system is implemented and The other approach is called planned design, where the designers think about the big issues in advance, there's no need of coding, they just build the general part, and they handle the result to other team, let's say "the programmers team" to actually code the design. Of course, it is practically impossible to think of all the issues you may have, before actually having something, so when you are programming there are questions that emerge about the design, and changing the whole design, yes that's also a lot of work and not all the time works, cause, what if the designer is gone and you cant understand?. So we have a big problem here and it is called "changing requirements". Some say that building the design kinda flexible, leads us to a good way to change our requirements. Thanks to some practices provided by the XP (Extreme Programming) as continuous integration, testing and refactoring, among others, this way can be a very good option.

The XP uses evolutionary design but with the underlying assumption that it is possible to flatten the change curve enough to make this design work, so that for example a change made in analysis for $1 doesn't cost thousands to fix in production. So, in XP they need several things to get this working correctly, first of all they need continuous integration to keep the team in sync, refactoring, which makes the code more understandable and finally, testing; with these three things, XP can achieve its results using evolutionary design.

One of the most important things XP relies on, is "Do the simplest thing that could possibly work" and "You ain't going to need it". So what I understood here is that we don't have to code features that are not gonna exist yet, because we don't even know if we are gonna need them in the future, and the design becomes more complex if we do this. To make our code simpler, XP gives us a criteria for our system: it runs all the tests, has no duplication, reveals all the intention and has the fewest number of classes or methods. Another point here is to refactor, because even though it doesn't add function, it makes our code simpler, so we should refactor every time we can.

Now, all the above is information that proof that the design is not dead, is like Fowler says "changing" and this give us to the programmers the idea that the design doesn't have to be avoided of the process of how to do the task of making some program because the design is the warranty that the program is going to result as a high quality product where the software entropy doesn't exist or is very small. This also proof that the software architecture is a very basic aspect of a process where is involved the development of a program because this activity allows to include the foundations in which all the rest of the elements are going to be based and related which is something that secure the good quality of a software product.

If you're interested in reading this article, here is the link: Is Design Dead?.