Cualquiera que sea la elección, resista la tentación de no pagar.
El desarrollo de software es un campo que no carece de debate. Pero si me costara elegir el más acalorado, sería el concurso de “refactorizar o reescribir”. Como puede mostrar una búsqueda rápida en Google, hay tantas opiniones como desarrolladores de software, por lo que llegar a un entendimiento es algo cercano a la utopía.
Sin embargo, los equipos de ingeniería de software se enfrentan a esta elección con más frecuencia, por lo que no es raro que las personas recurran a estas opiniones en busca de ayuda. Pero debido a que los puntos de vista son tan variados, hacerlo termina pareciendo un acto de fe.
Yo (o cualquier otra persona) no puedo dar una respuesta directa porque no la hay. Como ocurre con muchas cosas en el desarrollo de software, todo depende de varios factores que son específicos de cada situación. En otras palabras, no existen reglas generales sobre si se debe refactorizar o reescribir el código, incluso cuando muchos expertos o desarrolladores experimentados afirman que uno u otro es el mejor curso de acción.
En mi opinión, es mejor desarrollar una mentalidad crítica para abordar cualquier proyecto que pueda refactorizarse o reescribirse. Armado con él, puedes evaluar cualquier escenario que encuentres en la naturaleza y definir el mejor camino a seguir. Continúe leyendo para descubrir qué cosas debe tener en cuenta. Pero primero, asegurémonos de que estamos en la misma página.
Refactorizar y reescribir
| Criterio | Código de refactorización | Reescribir código |
|---|---|---|
| Papel principal | Mejorar el diseño del código existente sin cambiar su comportamiento externo. | Reemplace el código existente con una nueva versión que proporcione la misma funcionalidad |
| Tareas clave | Limpieza de código, optimización, eliminación de redundancia, mejora de la legibilidad | Comenzando desde cero, diseñando, codificando y probando |
| Habilidades requeridas | Comprensión del código base, buen conocimiento del lenguaje de programación, técnicas de refactorización. | Fuerte conocimiento del lenguaje de programación, principios de diseño de software. |
| Consumo de tiempo | Generalmente requiere menos tiempo y se realiza de forma incremental. | Consume más tiempo y es necesario reescribir todo el código base |
| Riesgo | Menor riesgo ya que los cambios son pequeños e incrementales | Mayor riesgo, el nuevo código puede introducir nuevos errores |
| Costo | Generalmente menor ya que no requiere una reescritura completa. | Más grande ya que requiere una remodelación completa. |
| Errores existentes | Puede ayudar a identificar y corregir algunos errores existentes. | Los errores existentes se pueden eliminar, pero se pueden introducir otros nuevos. |
| Entendiendo el código | Aumenta la comprensión de los desarrolladores sobre el código base. | Puede mejorar o disminuir la comprensión dependiendo de la complejidad del código. |
| Impacto en la funcionalidad | No agrega nuevas funciones, se centra en mejorar el código existente. | Puede agregar nuevas funciones y mejoras además de reescribir el código existente. |
| Prueba | Requiere pruebas, pero generalmente menos extensas debido a pequeños cambios incrementales. | Requiere pruebas completas de todas las funciones. |
| Mejor para | Bases de código que necesitan mejoras menores o tienen problemas de mantenimiento | Bases de código que son difíciles de mantener, comprender o que están mal estructuradas |
| Resultado | Mejor calidad del código, mantenibilidad y rendimiento potencialmente mejor | Nueva base de código, potencialmente con mejor estructura, rendimiento y nuevas características |
Uno de los problemas más comunes que encontrará en los artículos que abordan este debate es que sus autores a menudo no aclaran lo que quieren decir con refactorizar y reescribir. Tal vez sea porque creen que los desarrolladores saben de lo que están hablando. Si bien esto puede ser cierto (cualquier desarrollador conoce estas prácticas, independientemente de su experiencia), el problema es que no existe una definición universal de ellas.
Así que, para evitar confusiones, os contaré lo que pienso de ellos. Puede ser diferente a su definición, y eso está bien. No estoy tratando de convencerte de que uses estas definiciones. Es principalmente para aclarar de qué hablaré cuando me refiera a ambos más adelante.
Soy más de la escuela de Martin Fowler cuando se trata de reestructuración . Esto significa que siempre que hablo de refactorización, me refiero a cambiar el diseño de algo sin afectar su comportamiento. Se trata de retocar el código para aumentar su calidad mientras el software sigue siendo el mismo. Entonces el resultado es el mismo, pero ofrece mejor rendimiento, seguridad, se integra mejor con tecnologías más nuevas y es más escalable, entre otras cosas.
Una reescritura, por otro lado, consiste en eliminar todo el código existente y empezar desde cero para llegar al mismo lugar (o incluso a un lugar mejor). Esto significa comprender el software tal como es y recrearlo mediante un código nuevo. Podríamos decir que ésta es la “opción nuclear”, en el sentido de que nos deshacemos de lo que tenemos para ofrecer una alternativa mejor.
En general, a los desarrolladores les encanta reescribir cosas. Hay varias razones para esto: es más fácil empezar desde cero, no tiene que preocuparse de que las cosas se rompan porque está modificando partes específicas del código, puede crear un mejor producto, incluso puede escribir mejor documentación para él. ¡mientras lo reescribes! Sin embargo, creer que reescribir es superior debido a estas cosas significa ignorar intencionalmente otros aspectos cruciales que acompañan a la decisión de reescribir en primer lugar.
Veamos algunos de ellos.
Además de reescribir el canto de sirena
Todas las razones que mencioné anteriormente son las primeras cosas que les vienen a la mente cuando los ingenieros de software se enfrentan a software antiguo y de bajo rendimiento. Todo termina de la misma manera: los ingenieros quieren reescribir y empezar desde cero. Sin embargo, los desarrolladores rara vez son los únicos que deciden el destino del software. De hecho, algunas consideraciones suelen ser más importantes a la hora de decidir qué camino tomar.
De ellos, los impulsores de empresas encabezan la lista. Una reescritura (especialmente de software complejo) puede ser una tarea que requiere mucho tiempo y puede terminar costando mucho dinero sin ninguna ventaja real desde una perspectiva empresarial. Quizás reescribir el software requiera demasiados recursos que impidan que el equipo se concentre en tareas más valiosas. Quizás el software reescrito no tenga suficiente retorno de la inversión para justificar la reescritura en primer lugar. Como tal, las reescrituras a menudo pueden ir en contra de los objetivos comerciales, una de las principales razones por las que se rechazan.
Esto nos lleva a los riesgos asociados con la reescritura. Quizás reescribir todo el software pueda tener un impacto en el negocio, pero en el tiempo que lleva completarlo, permite a la competencia lanzar un producto similar al mercado más rápido. Es posible que haya nuevos competidores en el mercado una vez que complete la reescritura. O quizás el dinero que inviertes en reescribir te impide invertir en un activo más estratégico (ya sea tecnológico o no).
Finalmente, hay ciertos aspectos directamente relacionados con el propio software. Quizás el software que desea reescribir no sea fácil de mantener, pero es resistente, ofrece mucha seguridad y tiene un rendimiento excelente. Si no está completamente seguro de poder replicar todo esto, reescribirlo podría resultar contraproducente. Es posible que termine con un software de mantenimiento más fácil que no sea tan resistente, seguro o que funcione peor que el que tenía antes.
Presentar estas consideraciones no significa que reescribir sea una mala opción (estoy tratando de evitar los extremos a toda costa). Más bien, proporcionan la información necesaria que se debe tener en cuenta a la hora de tomar una decisión. Por lo tanto, ayudan a pintar una imagen más realista de lo que podría significar la reescritura.
Diseñar un enfoque crítico
Dado que la reescritura es lo que la mayoría de los ingenieros de software consideran cuando necesitan mejorar un sistema existente, es esencial comenzar por ahí. Tener en cuenta los impulsores del negocio y los riesgos asociados puede ser una excelente manera de decidir si una reescritura es adecuada para usted. En términos simples, necesita determinar si reescribir es una opción viable para usted antes de considerar los aspectos técnicos de todo esto.
Sin embargo, hay algo complicado al hacer esto. Es posible que esté considerando reescribir o refactorizar porque tiene una gran deuda técnica o su software está casi obsoleto. En este escenario, ambas opciones son arriesgadas. Si permanece igual simplemente porque las cosas funcionan, corre el riesgo de que su software no dure mucho, no se pueda mantener en un futuro cercano o no sea escalable. Si lo reescribe, es posible que no obtenga las mismas funciones.
Esto significa que no existe una opción libre de riesgos: considera la tuya y sé consciente de ellos, pero no bases tu decisión únicamente en los riesgos (o la falta de ellos), simplemente porque no existe ningún escenario en el que estés libre de ellos. .
Entonces, en mi opinión, la mejor manera de ver esto es la siguiente:
- Considere las implicaciones comerciales de cualquiera de las opciones. ¿Cuáles son sus posibles consecuencias?
- Analizar y valorar los riesgos. Una de las opciones puede ser más riesgosa que la otra, pero no necesariamente. ¿Entiendes lo que significa seguir un camino u otro?
- Describe las razones por las que quieres refactorizar o reescribir. ¿Qué está tratando de lograr?
- Identifique qué tan lejos está su software actual de estos objetivos. Hazlo lo más detallado posible.
- Establece un camino claro que te lleve desde donde estás hasta donde quieres estar. ¿Es siquiera posible? Quizás haya incompatibilidades con las nuevas tecnologías o no haya formas de transformar software obsoleto en hardware moderno.
- Divida los dos procesos siguiendo este camino. ¿Qué implica la refactorización de código? ¿Y cuáles son los que se incluyen en una reescritura? Esta es una parte clave de la evaluación, así que no intente expresar el proceso en cuánto tiempo cree que llevarán ambos procesos. En lugar de ello, intenta pensar en las tareas y sus complejidades, ya que esto te permitirá comparar mejor las dos opciones.
- Compara los caminos frente a ti. Es posible que descubra que, aunque la refactorización puede requerir más pasos, estos pasos son más fáciles que los menos pasos incluidos en la reescritura. O quizás quede claro que la refactorización es un esfuerzo insuperable debido a las muchas tareas que conlleva.
- Con una visión más clara de ambos caminos, reevalúe los factores y riesgos de su negocio. Una vez que tenga en cuenta todas estas consideraciones, estará mejor preparado para tomar una decisión final.
El debate entre refactorización y reescritura es estéril cuando se trata de operaciones diarias, ya que a menudo se desvía hacia el terreno teórico. Como no hay dos proyectos iguales, es vital repasar estos pasos prácticos para abordar mejor el tema y determinar si un camino es mejor.
Una última recomendación de mi parte. Incluso si descubre que un enfoque proporciona mejores resultados para sus proyectos, resista la tentación de optar por esa opción, ya que puede encontrarse con un proyecto específico que podría beneficiarse del otro enfoque. Puede parecer agotador hacer este análisis cada vez que trabajas con código antiguo, pero te garantizo que es la única forma de obtener los mejores resultados para tus proyectos.
Fuente: BairesDev
