¿Qué es refactoring?

El objetivo del refactoring es evitar la deuda técnica que se acumula en el código fuente y  generar un código mas limpio y mas fácil de entender.

De igual forma la refactorización es un proceso sistemático de mejorar el código sin crear una nueva funcionalidad, permitiendo transformar las funcionalidades actuales en un código limpio y un diseño simple.

¿Que sería código limpio (clean code) y deuda técnica (technical debt)?

Clean Code

Para que un código se considere limpio se debe tener en cuenta las siguientes características:

  1. El código debe ser fácil de entender para otro programador, tal cual como se interpreta una texto literario.
    1. Nombramiento claro, con respecto a las variables, métodos y clases.
    2. Algoritmos simples de entender.
    3. Sin números magicos.
  2.  No tener código duplicado. 
    1. Hacer uso del diseño de patrones para resolver alguna problema en especifico.
    2. Separar las responsabilidades en paquetes.
    3.  Usar clases utilitarias.
  3. Se debe contener un mínimo de clases y lineas de código. 
    1. Mejora el mantenimiento de las funcionalidades.
    2. Ayuda a encontrar bugs.
  4. Pasar todas las pruebas.
    1. Tener una cobertura mínima de 95% (unitarias e integrales).
    2. Los tests debe ser igualmente mantenible.
  5. ¡El código limpio es más fácil y económico de mantener!

Technical debt

Si nuestro código no se considera limpio (Dirty Code) podemos decir que tenemos una deuda técnica con respecto a nuestro desarrollo, por otro lado, otra deuda técnica considerable es la baja cobertura del código fuente por parte de pruebas unitarias e integrales.

Consideremos las siguientes causas de deuda técnica basados en porcentajes no óptimos:

– Imprecisión del negocio.

– Desconocimientos de los indicadores técnicos.

– De no combatir la estricta coherencia de los componentes.

– Falta de pruebas.

– Falta de documentación.

– Falta de interacción entre los miembros del equipo

– Desarrollo simultáneo a largo plazo en varias ramas.

– Refactorización discontinuo.

– Falta de seguimiento de cumplimiento.

– Desconocimiento del Stack Tecnológico.

¿Cuándo hacer refactor?

– Cuando agregamos una nueva característica.

– Cuando resolvemos un bug.

– Durante el code review.

– Cuando hacemos pruebas unitarias.

– Cuando hacemos algo por segunda vez.

– Cuando hacemos un código similar ya refactorizado.

Pensar en lo siguiente:

Si paso a hacer la refactorización ahora, ¿cuánto tiempo tomaría hacerlo más tarde?

Las refactorizaciones pequeñas son como hacer una inversión de bajo costo que siempre paga dividendos. Aprovecha eso cada vez.

Suscríbete a nuestro blog


Nuestros artículos y noticias de interés te mantendrán al día, actualizado, sobre el mundo de las soluciones TI.