Refactorizar sobre la mejor base posible

La visión de la refactorización no debe ser la de: “trato de cerrar cuanto antes las tareas que tengo asignadas que ya tendré oportunidad después de dedicar tiempo a poner el código un poco mejor”, principalmente por dos razones:

1) La mayoría de las veces, salvo que esté muy interiorizado por el equipo de trabajo y por el programador la necesidad de refactorizar y los beneficios que trae consigo, no se termina dedicando tiempo a realizar estas tareas porque continuamente van a surgir otras que se considerarán más prioritarias y sobre las que recaerá la atención. En este contexto tomar ese tipo de actitudes no es más que querer engañarnos a nosotros mismos: “finalmente no pude poner el código mejor o reducir el acoplamiento entre esas clases porque estoy hasta arriba de trabajo y no tengo tiempo”.

2) Se descuida la programación dejando para más adelante detalles que perfectamente podrían ser resueltos conforme se está trabajando. Todo es susceptible de mejorar de ahí lo útil que resulta refactorizar pero es importante que los esfuerzos dedicados a esa tarea sean los necesarios (y no más).

Es cierto que a veces las restricciones temporales imponen unas condicionen que ni permiten refactorizar y ni siquiera permite cuidar lo que se quisiera la codificación y la arquitectura. En estos casos el contexto del proyecto manda y probablemente para conseguir el resultado final en el tiempo y presupuesto establecidos habrá que sacrificar parte de su mantenibilidad y robustez.

¿Qué se puede hacer en estos casos? Lo que se pueda (realmente la situación de partida del proyecto es la culpable de todo lo demás) pero siempre con la intención de hacerlo de la mejor forma posible.

Anuncios
2 comentarios
  1. Recacha dijo:

    Buenas.

    Estoy totalmente de acuerdo con el fondo de lo que dices. Refactorizar no debería ser una tarea opcional que se hace después de programar una funcionalidad, sino que debería ser el último paso antes de dar por terminada esa tarea.

    Con lo que discrepo un poco es con esta afirmación: “a veces las restricciones temporales imponen unas condicionen que no permiten refactorizar”. En el libro de referencia sobre la materia, “Refactoring”, Martin Fowler argumenta que refactorizar te ayuda a programar más rápido (http://sourcemaking.com/refactoring/refactoring-helps-you-find-bugs). Llevado a la práctica no puede ser más cierto, por lo que si hay poco tiempo para programar algo, más motivo aún tendremos para refactorizar.

    Saludos.

    • jummp dijo:

      Refactorizar consiste en invertir tiempo para reducir deuda técnica, si se hace bien se reducirá la deuda técnica y por tanto la resistencia en la programación será menor.

      Podemos tener clara una inversión y saber que nos producirá beneficios pero para invertir se necesita dinero, si tienes dinero y asumes el riesgo inviertes en caso contrario no podrás invertir aunque quieras hacerlo.

      En el caso de la refactorización es lo mismo, sabemos que produce beneficios (si se ejecuta bien) pero para poder hacer esa inversión se tienen que dar las circunstancias para que lo puedas hacer.

      Es una buena práctica que la refactorización sea el último paso en la realización de una tarea pero, ¿lo vas a poder hacer siempre?, ¿lo puedes garantizar?. Vas a depender del contexto del proyecto, de tu contexto personal, de muchos factores. La refactorización es un instrumento (interesante si se aplica) y no un fin.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: