Hace un tiempo que estuve pensando en cómo explicar cuál es el mejor momento para hacer un refactoring, y cómo explicar cuál es el momento para hacer el refactoring, y cómo explicar cómo explicar cuál es el momento para hacer el refactoring....
Bueno, ustedes captan la idea.
Y esta es la explicación que elaboré.
Hacer un refactoring es como cambiar el botellón del dispenser de agua de la oficina.
¿Por qué?
- No vas a ganar más plata por cambiar el bidón.
- Generalmente cambiar el bidón es un dolor de huevos.
- Pero peor es no cambiarlo (y quedar sediento).
Bueno, ¿y cuándo conviene cambiar un bidón del dispenser?
Definitivamente no cuando todavía queda agua en el mismo.
Tampoco es una buena idea cambiarlo después de que deje de salir agua del dispenser, porque cuando quieras sacar agua caliente va a estar tibia y cuando quieras sacar agua fría va a estar tibia.
¿Entonces cuándo hay que cambiarlo?
Cuando se vació el bidón, pero queda agua en el tanque que está adentro del dispenser (y las cañerías). Entonces no desperdiciamos agua y el agua sale fría y caliente cuando lo queremos.
Hacer refactorings es algo parecido. Hacer un refactoring antes de tiempo es hacer "boiler-plate", y por lo tanto una pérdida de tiempo. Hacer un refactoring tarde (o no hacerlo) que suframos un diseño feo y que apenas lo hagamos tengamos que arreglar todas las cosas que se hicieron mal porque el diseño anterior no lo permitía de otra manera. En cambio, hacer el refactoring justo antes de necesitar esa flexibilidad en el código por primera vez, es como cambiar el botellón cuando queda agua dentro del dispenser pero no en el botellón.
¿Y cómo nos damos cuenta cuándo estamos por necesitar una flexibilidad en el diseño? La verdad es que soluciones mágicas no conozco (si alguien sabe alguna, por favor que avise). Pero en mi experiencia programar test-first ayuda mucho.
Eso es todo, y espero que hayan disfrutado de las ilustraciones,
Aureliano.
