Descripción general
Un libro de 353 páginas que es difícil llamar un libro completo y que es más bien un suplemento al curso correspondiente de refactorización. El nivel de lectura es fácil. Hay muy poco código, y todos los ejemplos están construidos más como abstracciones mediante diagramas de flujo y diagramas. La primera parte del libro también contiene imágenes que están temáticamente bien seleccionadas y complementan el contenido.
Resumen breve
La primera parte del libro está dedicada a lo que el autor llama "malos olores en el código". En esencia, son señales de que ha llegado el momento de refactorizar cierto código. Las señales se agrupan en diferentes categorías, por ejemplo, la primera se llama "Infladores" e incluye ejemplos como métodos grandes, clases grandes, listas de parámetros largas y cosas similares. Hay bastantes otros grupos también, como "Violación de principios de diseño", "Trabajo con herencia", "Variables temporales" y muchas otras.
La segunda parte está dedicada a formas ligeramente más prácticas de resolver los problemas descritos en la primera parte. Por ejemplo, qué enfoques aplicar cuando las clases o métodos son grandes, cómo dividirlos, cómo extraer código y reemplazar todas las ocurrencias antiguas con código nuevo. Por cierto, todas las prácticas aquí también se agrupan en diferentes categorías y se han recogido bastantes.
Opinión
En el momento de leer este libro, ya llevaba más de 10 años programando profesionalmente, sin contar los montones de años en la universidad y la facultad, así que francamente, no recuerdo mucho haber encontrado algún consejo que fuera nuevo para mí. Por eso no tomé notas para este libro. Sin embargo, sería beneficioso que los programadores principiantes se familiarizaran con el libro, además se lee muy rápido.
Todo el libro es principalmente sobre programación orientada a objetos (POO), y no hay mucha información sobre programación funcional. En general, esto ni es bueno ni es malo, simplemente es una constatación de hecho. Por supuesto, hubo ejemplos con los que difícilmente estaría de acuerdo, pero todo esto es cuestión de gusto. Además, en diferentes lenguajes de programación, los estilos de escritura y los patrones de diseño pueden diferir ligeramente, por lo que el intentó elegir alguna posición intermedia-universal y mantenerse firme en ella. A menudo se pueden encontrar ejemplos donde en una refactorización primero hacemos alguna acción (extraemos una clase separada donde sea lógicamente requerido), pero en otro ejemplo, por el contrario, fusionamos clases y simplificamos la jerarquía. Así, el autor enfatiza que cada situación es única y que ciertos patrones deben aplicarse según la situación, no de forma rígida.
