Descontrol en refactoring

El refactoring es un riesgo. No cabe duda. Y sobre todo si no se hace metódica y controladamente.

Muchas veces pasa que, intentando refactorizar, documentando código, haciendo pequeños ajustes, de alguna parte del sistema, se empieza a divergir y acabas con un monstruo, que no compila. O si compila, tiene un resultado incierto, en la forma de cambio de comportamiento en ejecución. Esto es resultado de subestimar esta tarea, en la que no sólo debe lidiarse con ingeniería de software, sino que además, partiendo de algo ya (mal) implementado.
Lo que puede comenzar documentando un fichero cpp, o alguna rutina en particular, puede provocar un cambio en el código fuente. Una variable que se puede ahorrar, un código que se puede sacar como factor común, una rutina que se puede encapsular en alguna función o alguna clase, algún código plano que se puede meter en bucle, intentos por exportar a script o poner como constantes o defines factores numéricos, etc.

Y es que el principal problema en todo esto no reside en saber hacerlo o no. No está tanto en saber cómo cambiar las cosas, o tener ideas de cómo hacerlo. Más bien creo que está en saber qué se está haciendo en cada momento y cuáles son tus objetivos.
Es importante saber qué tienes que hacer y saber discernir entre optimización, documentación, refactoring o simplemente cambiar el layout del código.

Existen libros interesantes al respecto como “Refactoring: Improving the design of existing code“, o incluso el “Code Complete Second Edition“, pero creo que mucho se tiene ganado con un poco de sentido común y con orientación y supervisión de tu encargado, en la forma de dejarte claro qué se necesita hacer, y qué no puedes hacer. Porque es importante saber en qué parte del proyecto se está modificando el código.
Podemos estar en una etapa de producción, en una etapa de corrección de bugs, o de documentación. O en una etapa de refactoring. O en una de sacar las ideas obtenidas de un código (toma de análisis).

Y gracias que existen aplicaciones de control de versiones. A veces, existe un código que está pésimamente estructurado. Con código duplicado. Con números mágicos, variables sin utilizar, trozos gigantes de código comentado, y sin pizca de documentación. Pero resulta de que este código puede que haya sido terminado en una etapa del proyecto un tanto acelerada y con presión. No voy a entrar en valorar que este tipo de desarrollo sea el correcto, o que con una cierta organización y experiencia desde el principio, las cosas se hagan mejor.

Lo que sí creo que podría decir es que realmente existen un peligro en refactorizar este tipo de códigos sin un objetivo en mente, si están funcionando. Muy fácilmente se puede “meter la pata” y hacer que deje de compilar o que el resultado no sea el esperado. Mucho peor si se hace a finales del proyecto. Y puede provocar algún que otro susto si se llega a subir al servidor de versiones.

Otra cosa que también a veces ocurre, son los cambios en cadena. Un ejemplo puede ser: Se quiere documentar un código. Documentando, tarea de la que me gustaría dedicar una entrada aparte, puede requerirse cambiar el layout o estructura del código (craso error ya, estabas documentando). Cambiar el orden de dos sentencias es más potencialmente dañino de lo que pueda parecer en un principio. Puedes querer cambiar una parte de código que estaba utilizando una tecnología o técnica antigua en tu sistema y quieres que ahora utilice la nueva que se ha desarrollado. Esto puede provocarte que tengas que cambiar la interfaz. Cambiar la interfaz es sumamente peligroso. Puede hacerte cambiar aquellas otras partes que hagan uso de ella. Y empiezas a cambiar en cadena.
Todo esto es un caso hipotético, y totalmente desaconsejado. Denota falta de experiencia por parte de un desarrollador, o falta de supervisión / orientación por parte de su encargado, pero que puede llegar a pasar.
En estos cambios que suceden en cadena, yo personalmente, primero evaluaría qué cambios implicaría. Luego acudiría a mi lead y discutiríamos los cambios. Puede que él te asesore y te indique que no hacen falta tales cambios. Que con uno simple en un sitio se consigue solucionar lo que buscamos. E incluso puede que sean necesarios tales cambios, pero no ahora. Se aparcan y se dejan para después de terminar el proyecto, en fase de post-análisis.

A veces, por muy evidentes que parezcan ser ciertos cambios en código, a veces no son posibles de realizar en una cierta etapa de proyecto. Y también, los cambios más ligeros pueden llevar a sobre-refactoring o refactoring extremo y descontrolado, lo cual es peor que dejar el código tal cual está.

Pero claro, todo esto depende del proyecto y de sus desarrolladores.

Fuente: Gyakoo blog