He usado internet desde 1995.

Allá por el 2014 o 2015 Se habló con el cliente problemático de un sistema de control de Inventarios. Está terminado desde 2017 con un alcance mucho mayor que el original, con dos o tres veces mas complejidad que la esperada, desarrollado en tres mees, y no han comprado básculas.

Domingo, casi las dos de la mañana. Mi esposa hace yunos reportes para un cliente de la empresa de Lunes a Sabado, después de la venta. Terminó como a las doce o doce y media de subir los 250mb de excel. Yo me desperté.

Estoy pensando desde hace unas horas como mejorar un server y un sitio de mas de 80 mil SLOC en el contexto de la cuarentena. Una parte de mi piensa en Ruby y Sinatra (aproximadamente un framework de ruby) como Alternativa.

Pero …

Hay ocasiones donde los PSR no tienen sentido. Mis proyectos normales no tienen LOC de relleno. La mayor parte son reales, con una razón de ser. Aunque tengo proyectos como el sistema de tickets multiempresas que usan clientes desde hace doce años ,con solo 2000 SLOC, y que tengo varios proyectos de 4000 a 10000 SLOC, pienso en otros proyectos que son los que me dan de comer en realidad. EL sistema de suministros, que hice en 1995 ya n ome da ingresos pero al final eran unas 90 a 140 mil SLOC, con características de C, ASM, OBJ y Clipper. EL «reemplazo» por terceros no solo era mas lento, sino que solo hacia el 10% .

Tengo frente a mi dos aplicaciones ssimples que hice los dos ultimos años, para mostrar datos obtenidos por SWAGGER. Una es de 1119 SLOC que podría reducirse con unos bucles (llama en dos procesos 50 lineas de contenido de una base de datos, que podría ser un bucle por la bae de datos peor no quiero que procese otros registros que esos asi que se dehja como esta), y la segunda es de unos 10 a 12 archivos que netotal son unos 10 mil SLOC que podría pasar a laravel si quisiera perjudicarlos, o a simfony si pudieran pasar a 7.0. pero con problemas de pago de servidor no le veo caso a cmbiar a simfony, y habiendo tenido que depurar sistemas ajenos en laravel 4 , 4.2 y 5.3 es algo que no le deseo a nadie aunque sería «cumplir maliciosamente»

El contador interno del SLOC del proyecto que me da mi entrada principal por desarrollo me dice que son 76581 en versión LEGACY con pantallas amarillas y 187583 en la no Legacy probablemente por los diversos manejadores de PDF. Calculo que son unas 60 mil SLOC propias.

El problema es que la mayor parte de los programadores de sistemas de gestión usan contextos de 10 mil SLOC máximo. Aqui estoy hablando de seis veces eso. EL módulo de routes son unas 400 a 600 lineas en el equivalente de Lambdas. manejar eso en laravel volvería locos a la mayoría. Cuando tienes un servicio que esta siendo usado de manera concurrente a bajo costo por unos 60 usuarios full time, algo estas haciendo bien.

Pero es el mismo principio detras de los dos proyectos propios de Swagger, que tienen menos usuarios en realidad. Que Node.JS/express suenan bien menos cuando crean problemas a los otros 59 usuarios.

Hacia donde ?

Solo puedo pensar que RoR no escala bien cuando hay 1600 consultas de factores agregados. y usar INNER JOIN complejos cuando una tabla tiene millones de registros y bases de datos de 6 Terabytes, no es la mejor opción y menos si el cliente tiene computadoras antiguas o internet inestable.

Y me lleva a lo mismo. Quizá Sinatra, o Python.

No le veo caso a una refactorización / normalización cuando lo actual funciona y el problema que tienes es que un usuario clave de un cliente se murió y no han registrado apgos de sus clientes los ultimos 25 dias. Es un error de personas, no de software.