Estoy volviendo a leer este libro que para mi es un clásico de la artesanía de software: Refactoring: Improving the Design of Existing Code. Algo que me gusta es que, en mi humilde opinión, es un libro que permanece en el tiempo ya que no importa si programamos en Turbo PascalECMAScript 2017, muchos de los conceptos y técnicas propuestas nos pueden ayudar a escribir código limpio y diseños extensibles. Quisiera comentar sobre este tema desde 3 aspectos, conocidos como shu-ha-ri.

Shu

O practicar, practicar, practicar. Practicar identificando code smells, aplicando técnicas de refactoring o ambas. Un buen sitio para practicar es codewars (del que hace poco escribió el amigo Salias). Esta es por ejemplo una kata de  refactoring  (la que usa Fowler como introducción en su libro).

Posiblemente en el espacio de trabajo, en el día a día (para aquellos que se dedican a programar), hay un montón de oportunidades para practicar refactoring o entrenar el ojo. Al revisar un pull request, al programar (solo o de a pares), al agregar funcionalidad, al cambiarla, etc. No solo para mejorar la calidad interna del producto que estamos haciendo, sino también para darle forma con nuestras manos a lo que estamos construyendo.

Ha

Incorporada la técnica, conociendo los code smells y sabiendo los pasos de cada refactor, es posible limpiar el código de una manera más eficiente y controlada. Sabiendo qué refactor aplicar en cada caso es más fácil prestarle atención a cosas como minimizar bugs en el proceso, agregar test unitarios en cada oportunidad o descubrir code smells en los test (como indirect testing) y mejorar su calidad. Como decía el sr. Miyagi:

Primero aprender a caminar. Después, aprender a volar. Regla de naturaleza. No mía.

Con el tiempo aprenderemos a variar la longitud de cada paso (refactor, test, refactor, test) según las circunstancias. Quizás con código conocido nos sintamos con confianza dando pasos más largos y usemos los patrones de diseño como destinos de refactoring (1). O notemos que empezamos a adentrarnos en terreno pantanoso, lidiando con varios grados de complejidad a la vez y algo nos dirá que intentemos con pasos más cortos.

Ri

Como suele ocurrir cada vez que tomamos un camino, le estaremos diciendo que si a algo y que no a otra cosa. En este caso, el refactoring puede ser una oportunidad para decirle que NO a la alienación, palabra que significa ajeno a uno mismo. Esto es algo que puede tener sentido para los que la sufrimos alguna vez (o más de una), ya sea por la presión de los tiempos, por estar tan enfocados en lo que hacemos que nos cuesta dejar de mirar al frente y mirar al costado, o no permitirnos hacer una pausa o andar a un ritmo más lento, o la razón que sea.

Y le diremos que SI a lo que nos pasa a nosotros como artesanos / artistas, a la posibilidad de disfrutar de lo que hacemos mientras lo hacemos, a la capacidad de ver la obra de nuestras manos y dialogar con ella desde la contemplación. Y desde ese lugar, quizás, como nos cuenta Caloi en la historieta de tapa, podamos dar nuestra última y característica pincelada.

 

(1) “In the GoF book we claimed that design patterns are targets for refactorings. This book finally shows that we didn’t lie. By doing so, Joshua’s book will deepen your understanding of both refactoring and design patterns.” —Erich Gamma, Eclipse Java Development Tools lead, IBM

compartir...Tweet about this on TwitterShare on FacebookShare on Google+Email this to someone