Opinion sobre codigo
 

Hola! (perdon que no tengo tildes!)
Me pregunto si me podrian dar un feedback honesto sobre este codigo.
Lo que adjunto son los dos archivos principales de un programa desarrollado por mi suegro. El trabajo en investigacion de nutricion de animales, y en base a eso luego desarrollo una aplicacion Delphi de simulacion de digestion de vacas. Ahora me pregunto si habria posibilidad de vender el codigo a otra empresa.

El tema es que no tiene documentacion de ningun tipo... ni del modelo de simulacion que hay detras, de la idea de como una cosa conecta con la otra (en la vaca), ni tampoco ninguna documentacion del codigo, que en su parte principal es miles de lineas en un solo procedure (tambien hace acceso a archivos, a base de datos, muestra de graficas, etc)

Si pueden dar una mirada bien rapida al codigo y decirme que piensan, si es posible (y cuanto trabajo requeriria) entenderlo, hacer documentacion inversa y eventualmente entender el modelo, exportar partes de la logica a otro software, etc.

Muchas gracias! :)

(adjunto el codigo)

Pides cosas muy amplias, genéricas y algunas no tienen nada que ver con otras.
El código, si funciona, bien está. Si hace lo que se espera que debe hacer y funciona correctamente y sin errores, y si le sirve a alguna empresa/persona... pues estupendo.
En cuanto al código, lo que me ha llamado la atención es la cantidad impresionante de variables globales.
Documentar y demás, pues has de saber lo que hace cada opción, porque alguien ajeno no puede hacerlo, solamente la persona que lo ha hecho.

Bueno, imagino que tu suegro debe ser investigador y experto en nutrición, no informático, porque el código como tal, a mi entender deja bastante que desear (sólo evaluándolo desde el punto de vista informático).
Sólo viendo las variabnle globales (como comenta Casimiro) o la función NutrientSupply (que tiene unas 4000 líneas) a mi se me ponen los pelos de punta.

Que conste que no quito valor al trabajo de tu suegro, por eso comento que no debe ser informático, o si lo es, debe ser de la vieja escuela.
El trabajo que hay en ese código es tremendo (sólo hay que mirar las líneas de código generadas), pero informáticamente es bastante mejorable.




Si funciona, siempre puedes venderlo.

Si es un modelo que no cambia, puedes utilizarlo.

En ese caso tendrías que pactar con la empresa qué pasa con el código, quien lo modifica o qué obligaciones tiene cada cual.
Puedes vender el código "tal cual". Si la empresa es consciente de ello, pues adelante. Todo depende de cual sea el acuerdo.




Entiendo que eso sólo puede hacerlo alguien que entienda de este tema (nutrición y modelos de simulación).
En ese caso, imagino que repasándolo se podría hacer una idea. contando que los nombres utilizados en las variables y los pocos comentarios le pueden ayudar a hacerse una idea genérica.
Para alguien sin esos conocimientos lo encuentro muy difícil o imposible.

La cosa no parece fácil el libro de Refactoring de Martin Fowler https://refactoring.com/ es un buen comienzo para reorganizar código siguiendo los micropasos de su catálogo. La cosa es que lo primero para poder hacerlo bien es tener una batería de test unitarios que "te chive" cuando rompes algo mientras realizas los cambios.



Para mí aquí tenemos la pescadilla que se muerde la cola, una vez tengas los test unitarios te pueden servir de documentación. Cualquiera podrá ver fácilmente lo que tiene que hacer el código, pero claro para hacer los test tienes que saber que tiene que hacer el código. Me temo que por mi parte no he encontrado aún ningún texto que ayude a enfrentrarse a este problema mecánicamente. Yo me pondría a seguir esos micropasos buscando cada code smell y siguiendo el catálogo sin test unitarios hasta conseguir tener un código más fácil de entender pero hay que tener claro que eso es trabajar sin red. Sin test unitarios no es realmente Refactoring y el peligro de ponerse a cambiar código sin red es cambiar el comportamiento de la aplicación sin darnos cuenta.



No digo que se deba tener miedo pero sí extremar el cuidado. La idea de los micropasos es modificar el código de forma rápida siguiendo el catálogo, casi "sin pensar", eso no puede ser así cuando no se tienen esos test para que ante cualquier despiste te salte el chivato rojo.