Hay un viejo dicho en el desarrollo de software. Lo he escuchado muchas veces en mi carrera...

Si no está roto, no lo arregles.

Puede tener problemas para optimizar el código antiguo.

¡Pero también deberías limpiar el código antiguo cuando puedas!

¿Cómo decides: dejarlo o arreglarlo?

Mi código simplemente funciona

Hay un GIF divertido recorriendo Reddit ahora mismo...

¡Subraya el hecho de que a menudo sabemos que nuestro código no se ajusta al dominio!

Con el tiempo, podemos estar bastante seguros de que el código será mal utilizado o ampliado de formas extrañas.

Incluso en el momento de escribir el código, puede que no parezca la mejor solución.

¿Qué hacer?

Sopesando tus opciones

Ya sea un código que acaba de escribir o un código antiguo que necesita una refactorización, ¿cómo decide qué hacer al respecto?

• Por un lado, ¡el código funciona! El software ágil dice que lo suficientemente bueno es suficiente . Debe dedicar su tiempo a actividades que generen más valor.
• Por otro lado, ¡dejar un código desordenado, confuso o mal diseñado para otra persona no es tan agradable! Además, cuando el código base está bien diseñado, los cambios y extensiones futuros son mucho más fáciles.

El desarrollo de software tiene que ver con las compensaciones. Constantemente estarás haciendo juicios. Ya sea para emprender un refactor es una de esas llamadas.

No es tan fácil como parece

A menudo encontrará que el código fundamental es complicado por una razón.

Al principio, parece que hay una manera mucho mejor. Pero a medida que se sumerge en el refactor, descubre que hay casos extremos que no consideró. Este código central se utiliza en más formas de las que esperaba.

Por lo general, la simple limpieza de una parte fundamental del código se desmorona. Lleva días o semanas de esfuerzo dar seguimiento a todas las piezas.

Cuando busque corregir el código fundamental, es fundamental que comprenda el alcance. ¿Qué tan grande será este cambio? ¿A cuántas partes del sistema afectará? ¿Cuánto tiempo puedo razonablemente esperar que tome el refactor?

Yo diría que siempre suponga que tomará el doble de lo que piensa.

Entonces, tienes que preguntarte: "¿Vale la pena?"

Preguntas a considerar

Aquí hay algunas cosas en las que pensar antes de emprender una gran refactorización:

• ¿Este código es fundamental para la aplicación y, por lo tanto, hace que todo el sistema sea más fácil de mantener?
• ¿Un refactor ayudará regularmente a los futuros desarrolladores o este código rara vez se toca?
• Si la refactorización tarda el doble de lo esperado, ¿valdría la pena?
• ¿Hay algún esfuerzo menor que pueda emprender primero para obtener una parte de los beneficios del refactor completo, como una forma de probar qué tan difíciles serán los cambios?
• Si paso tiempo en este refactor, hay un costo de oportunidad para otras funciones, mejoras y correcciones de errores en las que podría estar trabajando. ¿Es este refactor lo suficientemente importante como para justificar eso?

Pero también he estado en equipos en los que un esfuerzo de refactorización deshonesto ha absorbido el tiempo, la energía y la atención de nuestros desarrolladores. Todo por no mucho beneficio.

Por lo tanto, piénselo dos veces y realice sus esfuerzos de refactorización con la mente clara. Tu equipo te lo agradecerá.

Lista diaria

Ayudo a los desarrolladores de software a construir carreras significativas con un propósito.

A diferencia de otros, que recomiendan buscar grandes salarios, trabajos en empresas de élite (FAANG) o una preparación agotadora para la entrevista, yo asesoro a los desarrolladores hacia carreras de software satisfactorias y equilibradas.

Mi objetivo es ayudarte a trabajar en un software que haga del mundo un lugar mejor.

Otros 2000 desarrolladores de software reciben mi publicación diaria, directamente en sus bandejas de entrada.

¡Únete a la lista diaria y obtén acceso instantáneo a mi mejor contenido!

—

Únase a Medium por $ 5 — ¡Acceda a todo Medium + apóyeme a mí y a otros!