How do I apply Payday Loans But now, you have an extra

¿Refactorizar o reescribir?

Máquina de escribirEl objetivo de refactorizar y reescribir es "limpiar" el sistema mediante la mejora de la legibilidad, estructura y la claridad del código. Un código limpio es más fácil de mantener y mejorar. Sin embargo, en muchas ocasiones los equipos pasan en cierto tiempo decidiendo entre los dos enfoques. 

Michael Dubakov sugiere las siguientes razones por las qué el código se deteriora con el tiempo: 

  • Más y más funcionalidades. Esto conduce a una mayor complejidad. 
  • Atajos e improvisaciones para apoyar cosas como "Necesitamos esta pantalla de búsqueda en agosto. ¡Y punto final!" 
  • Rotatividad. Los nuevos desarrolladores no saben todas las decisiones y las ideas clave detrás de la arquitectura. Inevitablemente, el conocimiento se pierde en la transición. 
  • Crecimiento del equipo. Más gente, menos comunicación. Menos comunicación, mas decisiones. 

Michael sugiere que a pesar de que refactorizar y reescribir llevan a un código más limpio, ambas técnicas llevan al caos al sistema existente. Refactorizar es una actividad incremental, ya que afecta sólo una parte del sistema a la vez. Eso crea caos en el plano local, que puede ser fácilmente contenido. Por otro lado, reescribir es un cambio más invasivo, que resulta en un gran caos en el sistema. Debido a su mayor impacto, el período de estabilización de reescribir y mucho mayor que el de la refactorización. 

Tenemos el sistema antiguo durante la reescritura, por lo que el caos es constante. Después del "release", el caos aumenta de manera significativa. Muchos nuevos (y viejos) errores y comportamientos extraños son esperados y así el período de estabilización es mayor

Peter Schuh sugiere que algunas veces los equipos usan esas palabras de forma cambiada, resultando en una mayor confusión y caos. Los equipos deben entender que reescribir es una propuesta más arriesgada en comparación con refactorizar y por lo tanto debe utilizarse la terminología correcta. Según él,

Es sólo semántica. Bien, es sólo semántica hasta que alguien se lastima! Reescribir código es algo arriesgado y a veces doloroso. No siempre termina bien. Si ejecutamos una reescritura, pero lo llamamos refactorización y las cosas no salen "redonditas", ningún usuario se va a detener a pensar en la semántica. Ellos sólo van a tener miedo la próxima vez que oigan la palabra refactorizar

Guido AJ Stevens hace una observación interesante. Él sugiere que la cuestión no es elegir entre refactorizar y reescribir, pero si entre o: refactorizar, o: reescribir y refactorizar. Él sugiere que, incluso cuando el equipo decide reescribir, eventualmente tendrán dos sistemas en paralelo. El antiguo sistema, que puede requerir refactorización el nuevo sistema que está siendo reescrito. Esa combinación crea una tarea extremadamente compleja. Según él, 

Mantener una base de código que está envejeciendo, y escribir un nuevo sistema, puede "chupar" sus recursos. Su equipo se divide y va a incurrir en atrasos. Tenemos que planificar y ejecutar cuidadosamente la transición. Mientras tanto, sus competidores, no tienen el problema de corto plazo para ponerel producto en el mercado, tratarán de tomar a sus clientes. Si mantenemos esa realidad en vista e incluso apostamos por la reescritura, tenemos la oportunidad de tener éxito. 

Naresh Jain tiene las siguientes sugerencias específicamente para el código legado. Refatorizar cuando el código es difícil de entender y el equipo no está seguro de lo que hace. Reescribir cuando está claro lo qué hace el código, pero es difícil de entender. 

Así, refactorizar es la forma preferida de mejorar el sistema de forma incremental. Sucede en paso lento, aumenta la calidad con pequeñas y constante mejoras. Reescribir tiene sus ventajas, pero en muchas situaciones es una opción más arriesgada y los equipos nunca están seguros del resultado. Según lo propuesto por Joel on Software

Es importante recordar que cuando se comienza desde cero no hay absolutamente ninguna razón para creer que vamos a hacer un trabajo mejor que la primera vez.

De Refatorar ou Reescrever?
Compartir
  • No se han encontrado comentarios

Deja tus comentarios

0

El nuevo Dos Ideas.

Nuevo logo, nuevo buscador, nueva portada, podcast mensual... ¡y muchas novedades más!

Más novedades en Dos Ideas

Los Comentarios.

Javi
Se están cargando Java. Están mezclando un montón de cosas que no son orientadas a objetos y esta sa...
es increíble como una situación mala negativa me trajo hasta este sitio para saber que yo era una pe...
Hola. Muy bueno el post. Quisiera saber que versión de REST es recomendable. RestEasy (JBoss) jerse...
Muy bueno, super claro y lo mejor funciona y deja super claro te felicito
jrg
me gustaría empezar a utilizar Zk, alguien puede decirme como configurar ZK en un proyecto simple.
Tihuilo
Soy nuevo en el desarrollo de software y he escuchado sobre el tema paro no se por donde iniciar, co...

Inspiración.

"Si tú tienes una manzana y yo tengo una manzana e intercambiamos las manzanas, entonces tanto tú como yo seguiremos teniendo una manzana cada uno. Pero si tú tienes una idea y yo tengo una idea, e intercambiamos las ideas, entonces ambos tendremos dos ideas"

Bernard Shaw