Hace muchos años aprendí que la documentación de un sistema de programación debe mantenerse actualizada, y que el código «vivo» tiene cambios. Me parece que empecé a darme cuenta de eso en asuntos legales, también, allá por 1994. Por razones largas de explicar estaba trabajando ya en una segunda cadena de supermercados, teniendo un rol doble entre seguridad y mi puesto oficial. Y por seguridad me refiero a mi capacidad de detectar fraudes. Eso lo hacía en oficinas centrales de recursos humanos, que en ese entonces estaban por Vallejo.
Una de las cosas que hice fue colaborar con dos o tres sugerencias en el reglamento interno de los trabajadores, y además di una revisión casi final sobre ortografía. El borrador final estaba diseñado para ser usado en trípticos, y no era demasiado grande. No quiero ni pensar la aberración actual que debe ser en cuanto a largo. El caso es que en un momento dado, tenía un conocimiento más que estándar del mismo, y cuando en 1995, a principios de febrero, el gerente de la sucursal se dio un tiro en el pie figuradamente hablando, una de mis defensas más fuertes era el conocimiento del reglamento. Ese gerente echó a la basura los bonos de todos los de gerencia (tres o cuatro) y del gerente de zona de todo un año, en un solo día al impedirme hacer mi trabajo. Él no sabía cómo se calculaban sus bonos.
Cuando tres o cuatro días después llegó el gerente de zona a saber qué había pasado, porque yo seguía terco en mostrar que lo que querían hacer estaba prohibido por el reglamento y era de mala fe, llevaba yo como tres días de no hacer mi trabajo sino de apoyar a recursos humanos. No podían hacerme trabajar en lo mío y el apoyo a la de Recursos Humanos era súper bienvenido (básicamente con entrevistas de contratación y exámenes psicométricos). La cara del gerente de zona fue memorable. Y fue la primera vez que me dieron una gerencia definitiva formal. Ya había realizado esas funciones de gerencia durante años, pero resultaba más valioso en el área de sistemas. Y el error es que al no realizar mi trabajo de sistemas, salía afectado el bono de los gerentes de esa tienda, los de otras catorce o quince sucursales y del gerente de la zona responsable y otro gerente de zona extra.
Lo importante de esta historia es el efecto secundario que fue la promoción y la pérdida de bonos ANUALES de unas 50 personas.
En aquella época tenía yo varios sistemas bajo Turbo Pascal con records y objects; no se usaban Bases de Datos ni siquiera dbf; clipper era algo que estaba tratando de impulsar desde unos dos años antes. Solo que ese método de records era muy latoso de hacer cambios a la estructura de datos. Muchas veces era preferible crear archivos secundarios en lugar de campos nuevos. En realidad, tuvo que ver esa etapa muchísimo en mi experiencia de los pros y contras de algo llamado Normalización. Sin meterme en detalles… muchas personas piensan, por ejemplo, que si tienes choferes y una ruta de reparto, los choferes deben ir en la ruta, pero en realidad no. Deben ir en el reparto del día por comisiones, incapacidades y faltas. La normalización excesiva causa problemas mucho más fuertes de los que parecen.
En 2006, aproximadamente, acababa de nacer mi primera hija y empecé a trabajar en una industria, pero no querían que le hiciera cambios al mismo sistema pasado ciertas cosas. Nada de iniciativa propia o áreas de mejora. En realidad era un problema fuerte entre dos grupos «políticos» de funcionarios que se saboteaban solos. Los cambios sí los hice por iniciativa propia, menos en los procesos que querían el control absoluto, que fueron los procesos que fallaron después más feo. El punto de vista era: «déjalo como está; sabemos que los programadores le mueven cuando no hay que hacerlo ya». El efecto secundario de no estar actualizado es que los errores que no corriges cuando se puede se hacen más grandes. Una especie de recargos en la operación y nada que ver con «deuda técnica». Más adelante en la empresa de comunicaciones vía satélite hice un sistema de cero en tres meses, al cuarto mes me pasaron a proyectos especiales cuando me negué a trabajar con una contadora que mentía y que supervisaba factura electrónica. Y aunque la corrieron, pusieron al amigo de un socio que comentaba en otras entradas del blog que se la pasaba en la guitarra eléctrica y él no hizo nada durante casi dos años y medio. Así que de repente tenían mi programa instalado en cientos de clientes, pero sin actualizaciones de los dos años, ni había nada de las cinco a siete áreas de mejoras/requerimientos de cuando me fui a proyectos especiales. Literalmente, además lo instalaron en cientos de máquinas virtuales con clientes y no tenían ya las llaves o claves de acceso. Su solución fue pedirme que hackeara 200 máquinas de clientes, porque aunque conocían mi código y podía exportarse por SOAP la base de datos, no querían aceptar lo sucedido. Primero querían dejarlo como está y luego «No querían dejarlo como está», que corrigiera y regresara al problema original. Su idea era que corrigiera los errores, los pusiera en nueva versión en máquinas virtuales de las que no tenían llave y respaldo (y que por muchas razones no podían actualizarse solas sino bajo demanda por estar en instalaciones del cliente y en un principio el proyecto era que solo 2 estuvieran con cliente y el resto en nuestro servidor. La realidad era como siete clientes en nuestro server y 200 a 300 en virtualización con la versión de dos años antes. ). Me fui porque querían que violara la ley, que lo hiciera gratis, y que corrigiera yo solo en tres semanas el error de cinco personas durante casi tres años y se llevaran ellos el mérito. Coincidió con una muy buena oferta en lo que ahora llamo el cliente problemático. Todo por el «dejarlo como está».
El peor sistema que he visto en legacy es actualmente el seudolaravel 5.2 de los monolitos sobre php 5.6, con hardcoded y puertos cerrados. Ese sistema lo reescribí en base a requisitos funcionales en dos meses. Que yo recuerde del original, ponía siempre mal la «institución origen» ( hardcoded )y ponía una institución alemana, y encontrar cómo y dónde poner el correcto fueron unas 170 líneas de código. Y decidieron no usar mi sistema. Y perdieron el otro por falta de pago de los servidores. Sin comentarios.
En cuanto a lo que viene al caso, es porque recientemente he sido contactado por ofertas de personas o empresas que usan REACT, un framework sobre NODE de 2013. Problema serio: CRA no tiene soporte desde junio de este año, y los use effect y mal uso de los hooks hacen terrible la depuración. Oficialmente es una biblioteca que algunos confunden con un sistema de programación, y además usan para router next.js casi siempre. Pero después de ver varios repositorios de código de 2013 para acá con problemas y confusiones no solo entre versiones, sino entre los protocolos http/https, me pregunto si todos los que cambiaron de angular 2 en adelante a otro lenguaje lo hicieron a React o qué.
Sí, es posible que se puedan hacer partes más eficientes con React, pero en un equipo de varios programadores que se consideran serios, el uso de efectos / useeffects y hooks hacen varias cosas inmantenibles. Y mira que lo dice alguien que ha manejado proyectos de decenas de miles de líneas en c# y .net de versiones mixtas con algo de Xamarin.
Ese caso sí es un «déjalo como está». Si el responsable en entrevista técnica NO SABE qué React está usando, lo he dejado por la paz. Esto no se ve bien a futuro, no por mí, sino por todos esos proyectos. TypeScript y vue.js parece ser lo más decente del mercado que no se inclina por lo .net, pero solo pensar en usar React en manejo de factura electrónica o de información de blobs me da escalofríos.
Para aquellos ajenos a React o a quienes el framework les resulta incomprensible, mi experiencia indica que la mantenibilidad y la depuración en equipos grandes o proyectos grandes es inexistente o insostenible, proyectando su declive en el largo plazo (10 años), principalmente por problemas inherentes al use effect y a la dependencia excesiva de librerías de terceros. Mientras que proyectos de 70 mil a 1 millón de líneas (LOC) son estándar en otros lenguajes, en React el manejo de sistemas que superan las 15 mil líneas resulta, …. interesante.
En sistemas críticos, la mantenibilidad no es un lujo: es la diferencia entre continuidad y desastre. Y frameworks como React, mal usados, pueden ser el principio del desastre.