Soy Developer, ¿y ahora qué?
“Todo en el software cambia. Los requisitos cambian. El diseño cambia. El negocio cambia. La tecnología cambia. El equipo cambia. Los miembros del equipo cambian. El problema no es el cambio en sí mismo, puesto que sabemos que el cambio va a suceder; el problema es la incapacidad de adaptarnos a dicho cambio cuando éste tiene lugar.” Kent Beck.
“Todo en el software cambia. Los requisitos cambian. El diseño cambia. El negocio cambia. La tecnología cambia. El equipo cambia. Los miembros del equipo cambian. El problema no es el cambio en sí mismo, puesto que sabemos que el cambio va a suceder; el problema, es la incapacidad de adaptarnos a dicho cambio cuando éste tiene lugar.” Kent Beck.
Me presento, “Yo soy… Américo”, un chiste muy coloquial :S.
Soy Américo Faúndez, titulado en Diseño y Programación Multimedia, y hoy, cursando el último año de Ingeniería en informática y gestión.
Desde hace un tiempo a la fecha, (unos dos años creo) se instauraron en mí las ganas de avanzar en el Desarrollo de Software, y bueno, ahí me cuestioné lo que quería hacer, aprender nuevos Framework, certificarme en lo que sea, aprender más de lenguajes de programación. Quería darle un valor extra a mis desarrollos.
Fue en ese entonces que un compañero de trabajo me comentó de SOLID y de un famoso “Uncle Bob”.
Mis dolores de cabeza
Cuando inicié con el estudio de los Principios SOLID me di cuenta que la mayoría de estos principios estaban ahí, implícitos en los desarrollos, tal vez no cumplidos en su totalidad, pero, ahí estaban.
Al igual que los patrones de diseño, muchas veces los aplicamos sin saber que lo estamos haciendo. No creo que eso esté muy bien.
Como Developer, deberíamos saber y entender lo que estamos desarrollando, porque, aplicarlos sin saber, dice que vamos bien encaminados, que estamos haciendo las cosas bien, pero, también habla que no sabemos lo que estamos haciendo con claridad, solo “…echamos código” para resolver el problema que se nos presenta, sin tener una visión más alta, sin pensar en cómo va a evolucionar después el sistema o cómo el código se va a adaptar a los cambios que se produzcan.
Alternativas que encontré para resolver mis dolores de cabeza.
Lo primero que debemos entender, es el valor que nos da como profesionales conocer los distintos patrones de diseño, principios, metodologías, etc, que nos ayudan a escribir un código más “limpio”.
Existen muchas prácticas con nos ayudan a abordar y entender este mundillo de hacer las cosas bien.
Una que me gusta bastante es XP (Extreme programming). Esta metodología formulada por Ken Beck, parte de la base que todo cambia (como la canción) y como Developer debemos saber afrontar estos cambios en nuestro desarrollo. Este es un muy buen inicio para comenzar a estudiar buenas prácticas para sostener todos los cambios que se puedan presentar.
Sobre esto mismo, podemos encontrar principios que nos sirven de guías para mirar desde un nivel más alto nuestros desarrollos. Estos, son una buena manera para resguardar nuestro código para futuros cambios, para tener un código fácil de mantener y escalar.
Al comenzar a aprender estos principios, es fácil caer en el desafío de querer cumplir todo lo que leamos. En la práctica es muy difícil, en el caso de los principios SOLID, llegar a cumplirlos todos, es una tarea casi imposible. Creo que debemos ir sacrificando algún principio en mayor o menor medida, en pos de cumplir con otro que tenga mayor relevancia, esto según el contexto que uno se encuentre, las definiciones de negocio, las decisiones tomadas, etc.
Otra de las cosas importante que considero al momento de comenzar a desarrollar y que me resulta primordial como Developer, es nunca caer en el exceso de complejidad en el código, y para esto los invito a leer sobre KISS, es más, el valor base de XP es la simplicidad en todo orden.
También, como buen inicio, los invito a revisar TDD (Test-Driven Development), esta práctica también del ya conocido Robert C. Martín, nos dice que debemos comenzar el desarrollo escribiendo las pruebas (test unitarios) y desde ahí escribir el código que resuelva esa prueba.
Tiene el siguiente ciclo de vida (extraído de Wikipedia):
1. Elegir un requisito: se elige de una lista el requisito que se cree que nos dará mayor conocimiento del problema y que a la vez sea fácilmente implementable.
2. Escribir una prueba: se comienza escribiendo una prueba para el requisito. Para ello el programador debe entender claramente las especificaciones y los requisitos de la funcionalidad que está por implementar. Este paso, fuerza al programador a tomar la perspectiva de un cliente considerando el código a través de sus interfaces.
3. Verificar que la prueba falla: si la prueba no falla es porque el requisito ya estaba implementado o porque la prueba es errónea.
4. Escribir la implementación: escribir el código más sencillo que haga que la prueba funcione. Se usa la expresión “Déjelo simple” (“Keep It Simple, Stupid!”), conocida como principio KISS.
5. Ejecutar las pruebas automatizadas: verificar si todo el conjunto de pruebas funciona correctamente.
6. Eliminación de duplicación: el paso final es la refactorización, que se utilizará principalmente para eliminar código duplicado. Se hace un pequeño cambio cada vez y luego se corren las pruebas hasta que funcionen.
7. Actualización de la lista de requisitos: Se actualiza la lista de requisitos tachando el requisito implementado. Asimismo, se agregan requisitos que se hayan visto como necesarios durante este ciclo y se agregan requisitos de diseño (P. ej que una funcionalidad esté desacoplada de otra).
De manera más simple se basa en 3 partes: Arrange (Preparar), Act(Actuar), Assert (Afirmar).
Seguir esta práctica nos ayuda también tener una mejor visibilidad de lo que estamos desarrollando e inclusive ayuda a cumplir con los principios SOLID.
Pero hasta aquí, no he dicho que es el acrónimo SOLID, son 5 principios básicos para desarrollo bajo el paradigma orientado a objeto y estos son:
Single responsability principle (SRP)
Open/closed principle (OCP)
Liskov substitution principle (LSP)
Interface segregation principle (ISP)
Dependency inversion principle (DIP)
Todos son igual de importantes y muchas veces se entrelazan unos con otros y como ya también expuse, muchas veces tendremos que sacrificar un principio por sobre otro. Pero me quiero detener un poco en el primero de la lista SRP.
Principio de responsabilidad Única (Single Responsability Principle o SRP).
“Una clase debe tener solo una razón para cambiar.”
A mi parecer es el principio que tiene la definición más simple, pero más difícil de aplicar, aún me cuesta aplicarlo bien. Al cumplir bien este principio se obtiene una clase con una alta cohesión, esto quiere decir que la clase solo hace lo que debe hacer.
Cómo validamos que nuestra clase está haciendo solo lo que debe, pues bien, podemos apoyarnos en algunas prácticas que nos propone Clean Code, como ejemplo una buena manera de mantener una coherencia en nuestra clase, es dándole nombre con sentido a nuestras variables, y que los nombre de los métodos describan bien su funcionalidad. ¿Qué logramos con esto? Tener una visión clara de lo que está haciendo la clase.
Algunas maneras de saber que no se está cumpliendo con este principio son:
· Clases que tienen varias capas de arquitectura mezclada, suele suceder que se agrega lógica de negocio en capas que no corresponden, entre otros casos que pueden ser síntomas también.
· Cantidad de imports en la clase, una gran cantidad de imports puede ser sinónimo de que se están haciendo muchas cosas.
· Métodos muy extensos, el dicho “divide y vencerás”, puede ser aplicado tanto en clases como en los mismos métodos que tengan estás, así como la clase debe tener una única responsabilidad, los métodos también deben cumplir con este principio, así los métodos muy extensos, pueden ser síntomas de incumplimiento de SRP
Otro punto importante a mi consideración, y que tiene mucha relación con SRP es perder el miedo a crear clases, esto es primordial.
Muchas veces sucede que creamos clases “Utils” las cuales tienen una infinidad de responsabilidades y razones de cambio, a veces, es necesario tener una clase que nos brinde apoyo, pero inclusive estas clases, deben cumplir con SRP.
Al igual que los principios SOLID, están los patrones GRASP ( General Responsibility Assignment Software Patterns) así como dice Wikipedia, más que patrones, son buenas prácticas aplicables al desarrollo de software. a mí parecer son totalmente complementarios con los principios SOLID e incluso varios patrones GRASP resuelven las mismas problemáticas que trata de resolver SOLID.
No entraré más en detalle, pero los invito a revisar el SIGUIENTE VIDEO
Conclusión
Puedo decir que antes de comenzar a desarrollar, debemos tener muchas consideraciones según el contexto al cual se presente nuestro código, lo ideal es resguardar nuestro código con test unitarios y en el caso que nos toque ver código legado, revisar qué principios se están rompiendo y cómo podríamos refactorizar este código para mejorarlo (regla de boy scout).
También tener presente cumplir con una alta cohesión y un bajo acoplamiento.
— Alta Cohesión
La información que tiene una clase debe ser coherente y debe estar relacionada con la clase. En la práctica es cumplir con el principio de responsabilidad única.
— Bajo Acoplamiento
Tener las clases lo menos ligadas entre sí que se pueda. De tal forma que en caso de producirse una modificación en alguna de ellas, se tenga la mínima repercusión posible en el resto de clases, potenciando la reutilización y disminuyendo la dependencia entre las clases.
Lo mejor de comenzar a manejar estos conceptos, es que son agnósticos al lenguaje que se esté utilizando, además estos ayudan a afrontar de mejor manera los desafíos que se presenten asegurando una mejor calidad a nuestro código.
Link de Interes
Para los que se manejen bien en inglés y quieran saber más de SOLID. Una conferencia dada por el mismo creador de los principios y autor del Clean Code.
También para los que no somos tan bi-lingues, hay opciones de lectura y bien explicado cada uno de los principios.
Un poco de TDD.
Un buen resumen del libro.
Una descripción más afondo de GRASP.
