Review de Refactoring: improving the design of existing code

La semana pasada, para preparar decentemente la charla que impartí en Luce I.T., leí Refactoring: improving the design of existing code de Martin Fowler y Kent Beck. Refactoring es un libro que tenía pendiente desde hace tiempo y no me ha defraudado.

Estructura

El libro comienza explicando el concepto básico de Refactoring mediante un ejemplo práctico. De esta forma introduce rápidamente las ventajas de aplicar refactorización. Posteriormente, en capítulos posteriores, introduce las definiciones, ventajas e incovenientes y consejos de cuando aplicar refactoring.

El gran núcleo del libro se dedica a los code smells y a la lista de posibles refactorings con guías de aplicación paso a paso. El libro se completa con tres capítulos escritos por invitados, uno sobre general sobre refactoring, otro de la herramienta específica de Smalltalk y un capítulo final escrito por Kent Beck.

Un pequeño resumen destilado está en estas slides (pulsa ‘c’ para ver los comentarios).

Citas destacadas y comentarios

Comento algunas citas que han gustado o provocado especialmente (el resto las he dejado en quotista.com):

“Any fool can write code that a computer can understand. Good programmers write code that humans can understand”

Sobre la importancia de refactoring y del naming concretamente. Esta cita ya la había visto con otras formas.

“With refactoring you find the balance of work changes. You find that design, rather than occuring all up front, occurs continuously during development”

Sobre refactoring y diseño. Ante el BDUF, Martin Fowler defiende una mejora del diseño continua, la refactorización soluciona el deterioro del diseño a lo largo del tiempo de vida del proyecto.

“Here’s a guideline Don Roberts gave me: The first time you do something, you just do it. The second time you do something similar, you wince at the duplication, but you do the duplicate thing anyway. The third time you do something similar, you refactor.”

La polémica regla de la tercera vez… discuss!

“The other time you should avoid refactoring is when you are close to a deadline. At that point the productivity gain from refactoring would appear after the deadline and thus be too late.”

El problema de este tipo de sentencias es que sirven para justificar nuestros pecados.

“It is better to write and run incomplete tests than not to run complete tests. You should concentrate on where the risk is. Look at the code and see where it becomes complex.”

Mejor algo que nada…

Conclusiones

Me ha gustado especialmente el capítulo de Kent Beck, sobre la importancia de establecer objetivos claros y saber parar. Martin Fowler menciona el problema de ‘cavar demasiado’ y refactorizar sin un rumbo claro y recomienda la suma de pequeñas refactorizaciones para lograr el mismo objetivo.

A lo largo del libro se menciona la importancia de saber con certeza la actividad que estás realizando en todo momento, con una metáfora de sombreros (llevar puesto el sombrero de refactoring o de desarrollador) y no mezclar en el mismo instante las dos activades.

Me gusta especialmente la lista exhaustiva de refactorings, de code smells y las razones por las que refactorizar, cuando, los problemas y qué contar al jefe (si no le importa la calidad, no se lo cuentes y hazlo!).

Por poner pegas al libro, las guías de refactorización pierden un poco el sentido ante el avance de los entornos con refactorizaciones automatizadas (aunque no para todos los lenguajes) y echo de menos alguna refactorización más larga (estilo Clean Code).

Son pequeños comentarios a un libro editado en 1999 que sigue totalmente vigente. Lectura recomendada.