Refinamiento Sucesivo

Si te mostrara ahora un trozo de código y te dijese: “Mira que limpio está” podrías pensar que esto ha salido a la primera de mi cabeza porque soy  muy bueno pero no es así. Cuando escribes un código la mayoría de veces te  pasará que empiezas a hacer cosas “porque funcionan” sin pensar mucho  en las buenas prácticas sobretodo cuando estás empezando con ellas. Pero no por eso debes dejarlo pasar.

Continue reading

Concurrencia

Concurrencia… Aaaah mi amiga la concurrencia, como te quiero y te odio a la vez. Tú junto con la recursividad has sido, de momento, los dos conceptos  que más me ha costado entender en la informática. Es de esas  cosas que o entiendes a la primera o tardas tiempo hasta que un día, hace  “click” en tú cabeza y todo cobra sentido, vamos a por ti ¿eres realmente tan  necesaria?

Continue reading

Las 4 reglas de un buen diseño

Aparición

¿Que pensarías si te contara que existen cuatro simples reglas que te ayudaran a crear buenos diseños según trabajas? Cuatro reglas con las que aparece el buen diseño por si solo y estas son las cuatro reglas de Kent Beck del Diseño Simple, estas las deben de cumplir nuestra aplicación:

  • Pasar todos los test
  • No debe tener duplicidad
  • Expresar la intención del programador
  • Minimizar el número de clases y métodos

Están ordenadas por importancia de las mismas.

1. Pasar todos los test

Lo primero y principal tiene que ser una aplicación testable, esto es importante y creo que sabes porque pero te lo recuerdo. Si nuestro sistema es testable 100% sabremos rápidamente cuando falla y donde falla gracias a los test (si los ejecutamos cada vez, obviamente). Para que nuestro sistema sea testable nos será más sencillo si respetamos el principio de responsabilidad única del que ya hemos hablado en anteriores ocasiones y si usamos técnicas como TDD que se basa en hacer test antes de la propia implementación. Por ello algo tan simple, a primera vista, como que nuestra aplicación tiene que estar testada de principio a final y ejecutar estos test continuamente hará que sea una aplicación más cohesiva y menos acoplada, ambos parte del objetivo principal de la orientación a objetos.

2-3. Refactorizar

Por cada pocas líneas que escribamos debemos pararnos a pensar si realmente se pueden escribir o estructurar mejor, si hay expresiones que extraer como métodos para que sea más legible, si tenemos variables mal nombradas, etc. Esto es mucho más cómodo si tenemos test que nos aseguran que tras cada cambio todo sigue funcionando correctamente. Este paso es bastante importante ya que de primeras podemos darle una solución a una implementación según nos vienen a la cabeza para que pase nuestro test, pero luego, en frío vemos lo que acabamos de escribir y vemos con mayor claridad que es mejorable, si es así, a por ello mejóralo no lo dejes por miedo!

Muchas veces mientras escribimos nuestra solución estamos tan metidos en el problema y estás tan metido en él que comienzas a escribir trozos de código duplicado sin pensarlo, pones nombres a variables con prisas porque solo quieres ver ya después de horas ver ese test en verde y escribes líneas que en unos días te arrepentirás de no haber hecho como es debido. Así que para, lee y piensa mi yo del futuro le gustaría ver esto.

4. Minimizar clases y métodos

Esta regla está al final porque es la que menos prioridad se le da y es porque muchas veces para ayudar a que la aplicación sea más expresiva y no tenga duplicidad de código, creamos clases o métodos minúsculos añadiendo más y más clases y métodos a la aplicación. Pero no te preocupes, si lo has creado y este tiene una razón de ser es porque debe existir. Y como todo en esta vida, la experiencia te va haciendo ver cuando debes y no extraer esa clase o método. Poco a poco se aprende.

Libro original