El principio clave del Refactoring

el-principio-clave-del-refactoring

La idea de los refactorings es que partiendo de un software que tiene buenas pruebas unitarias podemos modificar su estructura para hacerlo más mantenible: más sencillo de entender y de cambiar.

En este proceso podemos realizar muchos tipos de refactorings, que hemos estudiado en Algoritmos Mantenibles, como por ejemplo:

  • Extraer variables
  • Renombrar variables
  • Eliminar código duplicado
  • Extraer métodos
  • Extraer objetos y sus pruebas unitarias
  • Extraer parámetros a un parameter object

El principio clave es:

Cada refactoring debe ir acompañado de la ejecución exitosa de todas las pruebas unitarias del proyecto donde trabajamos y del elemento específico que estamos modificando.

Es decir, cada refactoring es un paso pequeño y seguro, acompañado de un éxito en verde.

Este principio nos puede ayudar a tomar decisiones prudentes en cualquier situación, como por ejemplo:

  1. Al extraer objetos, extraigo primero todos los objetos y luego programo todas las pruebas unitarias?
  2. Al extraer parameter objects, ¿los extraigo todos y al final ejecuto las pruebas unitarias?

Estos dos casos son de especial interés pues en la práctica noto que es una dificultad recurrente. El principio nos guíará a responderlas así:

  1. Deberíamos extraer un objeto a la vez y realizar sus pruebas unitarias antes de continuar con cualquier otro objeto.
  2. Deberíamos extraer el parameter object de un objeto a la vez, lograr la compilación y ejecutar sus pruebas unitarias, igualmente antes de continuar con cualquier otro objeto.

Si somos disciplinados, los refactorings nos darán un ritmo seguro. En ocasiones tendemos a apresurarnos pensando que la disciplina es innecesaria. Nos decimos a nosotros mismos:

“Yo jamás podría cometer un error aquí”

Sin embargo, casi siempre nos equivocamos en algún detalle, y por no haber seguido el principio clave tardamos mucho buscando dónde está el error.

En un software fácil de cambiar, los errores los podemos encontrar más rápido y cada error se halla contenido en un objeto de responsabilidad única que modificamos un minuto atrás. Además, el error evidenciado explicado por una prueba unitaria muy bien enfocada.

También deberíamos considerar que aunque nuestras pruebas unitarias estén en verde, no implica que haya un defecto allí escondido y que en seis meses alguien tendrá que ir a corregirlo. si fuimos metódicos, el trabajo del colega del futuro será más sencillo. ¡Y ese colega podríamos ser nosotros mismos!

Entonces, si el desarrollo completo se hace más eficiente con esta disciplina, evitemos la tentación de apresurarnos, hagamos y ejecutemos las pruebas unitarias con cada refacoring.

La próxima vez que nos hallemos navegando de un archivo de texto hacia otro, leyendo y buscando un error, podríamos preguntarnos “¿me habría ahorrado este dolor con una mejor disciplina de refactoring?”.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión /  Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión /  Cambiar )

w

Conectando a %s