Como nota al margen: busque un nuevo trabajo. Este no mejoraría.
Los objetivos del código que está revisando son:
Para enviar una función, que debería funcionar de acuerdo con los requisitos.
Reducir el crecimiento de la deuda técnica.
El primer objetivo se revisa comprobando que la unidad, la integración, el sistema y las pruebas funcionales están aquí, que son relevantes y que cubren todas las situaciones que deben probarse. También debe verificar las creencias que el autor original puede tener sobre el lenguaje de programación, lo que podría conducir a errores sutiles o al código que pretende hacer algo diferente de lo que realmente hace.
El segundo objetivo es aquel en el que se centra su pregunta. Por un lado, no se espera que el nuevo código aumente la deuda técnica. Por otro lado, el alcance de la revisión es el código en sí mismo, pero en el contexto de toda la base de código. A partir de ahí, usted, como revisor, puede esperar dos enfoques del autor original:
El código externo no es mi culpa. Solo implemento la función y no me importa toda la base de código.
En esta perspectiva, el código copiará las fallas de la base de código, y así inevitablemente aumentará la deuda técnica: más código malo siempre es peor.
Si bien este es un enfoque válido a corto plazo, a largo plazo, daría lugar a retrasos crecientes y baja productividad, y eventualmente llevaría a que el proceso de desarrollo fuera tan costoso y arriesgado que el producto dejaría de evolucionar.
Escribir un nuevo código es una oportunidad para refactorizar uno heredado.
En esta perspectiva, el efecto de los defectos del código heredado en el nuevo podría ser limitado. Además, la deuda técnica podría reducirse, o al menos no aumentarse proporcionalmente al crecimiento del código.
Si bien este es un enfoque válido a largo plazo, tiene sus riesgos a corto plazo. La principal es que, a corto plazo, a veces llevaría más tiempo enviar la característica específica. Otro aspecto importante es que si el código heredado no se prueba, la refactorización presenta un gran riesgo de introducir regresiones.
Dependiendo de la perspectiva que desee fomentar, puede inclinarse a aconsejar a los revisados que refactoricen más o no. En todos los casos, no espere una pieza de código impecable y limpia con una arquitectura y un diseño agradables dentro de una base de código horrible. Lo que no debe alentar es el comportamiento en el que un desarrollador bien informado que tiene que trabajar en una base de código deficiente intenta hacer bien su parte . En lugar de simplificar las cosas, solo las hace más complicadas que antes. Ahora, en lugar de un código incorrecto uniforme, tiene una parte con patrones de diseño, otra parte con código limpio y claro, otra parte que se refactorizó ampliamente con el tiempo y sin unidad alguna.
Imagine, por ejemplo, que está descubriendo una base de código heredada de un sitio web de tamaño mediano. Le sorprende la falta de una estructura habitual y el hecho de que el registro, cuando se hace, se realiza agregando cosas a un archivo de texto a mano, en lugar de usar un marco de registro. Decide que la nueva característica use MVC y un marco de registro.
Su colega está implementando otra función y está muy sorprendido por la falta de un ORM en el que uno tenga el tamaño perfecto. Entonces él comienza a usar un ORM.
Ni usted ni su colega pueden pasar por cientos de miles de líneas de código para utilizar MVC, un marco de registro o un ORM en todas partes. En realidad, requeriría meses de trabajo: imagine presentar MVC; ¿Cuanto tiempo tardaría? ¿O qué pasa con un ORM en situaciones en las que las consultas SQL se generaron caóticamente a través de la concatenación (con lugares ocasionales para la inyección SQL) dentro del código que nadie podía entender?
Crees que hiciste un gran trabajo, pero ahora, un nuevo desarrollador que se une al proyecto tiene que enfrentar mucha más complejidad que antes:
La vieja forma de tratar las solicitudes,
La manera MVC
El viejo mecanismo de registro,
El marco de registro,
El acceso directo a la base de datos con consultas SQL creadas sobre la marcha,
El ORM
En un proyecto en el que estaba trabajando, había cuatro (!) Marcos de registro utilizados uno al lado del otro (más el registro manual). La razón es que cada vez que alguien quería registrar cosas no había un enfoque común para hacerlo, por lo que en lugar de aprender un nuevo marco (que en todos los casos se usó solo en el 5% de la base de código), uno simplemente agregaría otro. ya sabe. Imagina el desastre.
Un mejor enfoque sería refactorizar la base de código paso a paso. Tomando nuevamente el ejemplo del registro, la refactorización consistiría en los siguientes pequeños pasos:
Encuentre todos los lugares donde se realiza el registro heredado (es decir, cuando se accede directamente al archivo de registro) y asegúrese de que todos invoquen los mismos métodos.
Mueva este código a una biblioteca dedicada, si corresponde. No quiero registrar la lógica de almacenamiento en mi clase de carrito de compras.
Modifique, si es necesario, la interfaz de los métodos de registro. Por ejemplo, podemos agregar un nivel que indique si el mensaje es informal o si es una advertencia o un error.
Use los métodos recientemente refactorizados en la nueva función.
Migre al marco de registro: el único código afectado es el código dentro de la biblioteca dedicada.