Desarrollando aplicaciones web para una larga vida útil (más de 20 años)

El software de planificación para una vida útil de este tipo es difícil, porque no sabemos qué nos depara el futuro. Un poco de contexto: Java se publicó en 1995, hace 21 años. XmlHttpRequest estuvo disponible por primera vez como una extensión patentada para Internet Explorer 5, publicada en 1999, hace 17 años. Pasaron aproximadamente 5 años hasta que estuvo disponible en todos los principales navegadores. Los 20 años que está tratando de mirar hacia el futuro son casi las aplicaciones web ricas en tiempo que han existido.

Algunas cosas han permanecido igual desde entonces. Ha habido un gran esfuerzo de estandarización, y la mayoría de los navegadores se ajustan bien a los diversos estándares involucrados. Un sitio web que funcionó en los navegadores hace 15 años seguirá funcionando igual, siempre que funcionó porque estaba dirigido al subconjunto común de todos los navegadores, no porque utilizara soluciones para cada navegador.

Otras cosas vinieron y se fueron, principalmente Flash. Flash tuvo una variedad de problemas que llevaron a su desaparición. Lo más importante, fue controlado por una sola empresa. En lugar de la competencia dentro de la plataforma Flash, hubo competencia entre Flash y HTML5, y HTML5 ganó.

De esta historia, podemos recopilar un par de pistas:

• Manténgalo simple: haga lo que funciona ahora, sin tener que usar ninguna solución alternativa. Este comportamiento probablemente permanecerá disponible en el futuro por razones de compatibilidad con versiones anteriores.

• Evite confiar en tecnologías patentadas y prefiera estándares abiertos.

El mundo de JavaScript de hoy es relativamente volátil con un alto flujo de bibliotecas y marcos. Sin embargo, casi ninguno de ellos importará en 20 años, el único "marco" que estoy seguro de que todavía utilizará es Vanilla JS .

Si desea utilizar una biblioteca o herramienta porque realmente facilita mucho el desarrollo, primero asegúrese de que esté basado en los estándares actuales compatibles. Luego debe descargar la biblioteca o herramienta e incluirla con su código fuente. Su repositorio de código debe incluir todo lo necesario para que el sistema pueda ejecutarse. Cualquier cosa externa es una dependencia que podría romperse en el futuro. Una forma interesante de probar esto es copiar su código en una memoria USB, ir a una computadora nueva con un sistema operativo diferente, desconectarlo de Internet y ver si puede hacer que su interfaz funcione. Siempre que su proyecto consista en HTML + CSS + JavaScript simple y quizás en algunas bibliotecas, es probable que pase.

Lo que es aún más importante que su código de supervivencia durante 20 años es que sus datos sobreviven durante 20 años. Lo más probable es que eso sea lo que vale la pena preservar. Si es fácil trabajar con sus datos, será fácil construir un sistema alternativo con tecnología más nueva.

• Comience con un modelo de datos claro y bien documentado.
• Utilice un sistema de base de datos establecido y bien soportado, como Oracle ^[1] o SQL Server.
• Use las funciones básicas, no intente exprimir las nuevas y llamativas.
• Prefiero simple sobre inteligente .
• Acepte que la capacidad de mantenimiento futura puede venir a expensas de aspectos como el rendimiento. Por ejemplo, puede sentirse tentado a utilizar procedimientos almacenados, pero estos podrían limitar la capacidad de mantenimiento en el futuro si impiden que alguien migre el sistema a una solución de almacenamiento más simple.

Una vez que tenga eso, la aplicación de pruebas de futuro es más sencilla, ya que es una envoltura alrededor del modelo de datos y se puede reemplazar si, en 10 años, nadie usa más Javascript, por ejemplo, y necesita migrar La aplicación para WASM o algo así. Mantener las cosas modulares, menos interdependientes, permite un mantenimiento futuro más fácil.

^[1] La mayoría de los comentarios a esta respuesta adoptan una postura firme en contra del uso de Oracle para una base de datos, y citan muchas razones perfectamente legítimas por las que es un problema trabajar con Oracle. y gastos generales de instalación. Estas son preocupaciones totalmente válidas al elegir Oracle como una base de datos, pero en nuestro caso, no estamos buscando una base de datos de propósito general, sino una en la que la principal preocupación es la capacidad de mantenimiento . Oracle ha existido desde finales de los años 70 y probablemente será compatible durante muchos años, y existe un gran ecosistema de consultores y opciones de asistencia que pueden ayudarlo a seguir funcionando. ¿Es este un desastre demasiado caro para muchas empresas? Por supuesto. Pero ¿mantendrá su base de datos funcionando durante 20 años ? Muy probable.

La respuesta anterior por amon es excelente, pero hay dos puntos adicionales que no se mencionaron:

• No se trata solo de navegadores; Los dispositivos también importan.

  amon menciona el hecho de que un "sitio web que funcionó en los navegadores hace 15 años seguirá funcionando igual" , lo cual es cierto. Sin embargo, mire los sitios web creados no hace quince, sino hace diez años, que, cuando se crearon, funcionaron en la mayoría de los navegadores para la mayoría de los usuarios. Hoy en día, una gran parte de los usuarios no podrán usar esos sitios web en absoluto, no porque los navegadores hayan cambiado, sino porque los dispositivos sí lo hicieron. Esos sitios web se verían terribles en pantallas pequeñas de dispositivos móviles , y eventualmente no funcionarán en absoluto si los desarrolladores decidieran confiar en el evento click de JavaScript, sin saber que el evento tap también es importante. p>

• Te estás enfocando en un tema incorrecto.

  Los cambios tecnológicos son una cosa, pero uno más importante es el cambio de requisitos . Es posible que el producto deba ser escalado, o que deba tener funciones adicionales, o que necesite que se cambien sus características actuales.

  No importa lo que suceda con los navegadores, dispositivos, W3C o ... lo que sea.

  Si escribe su código de manera que pueda ser refaccionado , el producto evolucionará con la tecnología.

  Si escribe su código de manera que nadie pueda entenderlo y mantenerlo, la tecnología no importa: cualquier cambio ambiental reducirá su aplicación de todos modos, como la migración a un sistema operativo diferente, o incluso una cosa simple como Crecimiento de datos naturales.

  Como ejemplo, trabajo en desarrollo de software durante diez años. Entre las docenas y docenas de proyectos, solo hubo dos que decidí cambiar debido a la tecnología , más precisamente porque PHP evolucionó mucho en los últimos diez años. Ni siquiera fue la decisión del cliente: a él no le importaría si el sitio usa espacios de nombres o cierres de PHP. Sin embargo, hubo cambios relacionados con los nuevos requisitos y la escalabilidad.

Usted no planea durar 20 años. Llano y simple. En cambio, cambias tus metas a la compartimentación.

¿Es su base de datos de aplicaciones agnóstica? Si tuvieras que cambiar las bases de datos en este momento, ¿podrías? Es su lenguaje lógico agnóstico. Si tuviera que volver a escribir la aplicación en un idioma totalmente nuevo en este momento, ¿podría hacerlo? ¿Sigues buenas pautas de diseño como SRP y DRY?

He tenido proyectos en vivo por más de 20 años, y puedo decirles que las cosas cambian. Como ventanas emergentes. Hace 20 años podías confiar en un pop-up, hoy no puedes. XSS no era nada hace 20 años, ahora tienes que dar cuenta de CORS.

Entonces, lo que hace es asegurarse de que su lógica esté bien separada y de evitar usar CUALQUIER tecnología que lo vincule a un proveedor específico.

Esto puede ser muy complicado a veces. .NET, por ejemplo, es excelente para exponer la lógica y el método de su adaptador de base de datos MSSQL que no tiene equivalentes en otros adaptadores. MSSQL puede parecer un buen plan hoy, pero ¿seguirá siéndolo durante 20 años? Quién sabe. Un ejemplo de cómo evitar esto para tener una capa de datos totalmente separada de las otras partes de la aplicación. Entonces, en el peor de los casos, solo tiene que volver a escribir toda la capa de datos, el resto de la aplicación no se verá afectada.

En otras palabras, piensa en ello como un auto. Tu coche no lo va a hacer en 20 años. Pero con neumáticos nuevos, motor nuevo, transmisión nueva, ventanas nuevas, electrónica nueva, etc. Ese mismo auto puede estar en la carretera por mucho tiempo.

Las respuestas de @amon y algunas otras son geniales, pero quería sugerir que mires esto desde otra perspectiva.

He trabajado con grandes fabricantes y agencias gubernamentales que confiaban en programas o bases de códigos que se habían utilizado durante más de 20 años, y todos tenían una cosa en común: la compañía controlaba el hardware. Tener algo funcionando y extensible por más de 20 años no es difícil cuando controla en qué se ejecuta. Los empleados de estos grupos desarrollaron código en máquinas modernas que eran cientos de veces más rápidas que las máquinas de implementación ... pero las máquinas de implementación se congelaron a tiempo.

Su situación es complicada, porque un sitio web significa que necesita planificar dos entornos: el servidor y el navegador.

Cuando se trata del servidor, tiene dos opciones generales:

• Confíe en el sistema operativo para varias funciones de soporte que pueden ser mucho más rápidas, pero significa que el sistema operativo debe estar "congelado en el tiempo". Si ese es el caso, querrá preparar algunas copias de seguridad de la instalación del sistema operativo para el servidor. Si algo falla en 10 años, no querrás volver loco a alguien tratando de reinstalar el sistema operativo o reescribir el código para que funcione en un entorno diferente.

• Utilice bibliotecas versionadas dentro de un lenguaje / marco dado, que son más lentas, pero se pueden empaquetar en un entorno virtual y probablemente se ejecuten en diferentes sistemas operativos o arquitecturas.

Cuando se trata del navegador, deberá hospedar todo en el servidor (es decir, no puede usar un CDN global para hospedar archivos). Podemos asumir que los futuros navegadores seguirán ejecutando HTML y Javascript (al menos por compatibilidad), pero eso es realmente una suposición / suposición y no se puede controlar eso.

El núcleo de la mayoría de las aplicaciones son los datos. Los datos son para siempre. El código es más prescindible , modificable, maleable. Sin embargo, los datos deben ser preservados. Así que concéntrate en crear un modelo de datos realmente sólido. Mantenga el esquema y los datos limpios. Anticipe que una nueva aplicación podría estar construida sobre la misma base de datos.

Elija una base de datos que sea capaz de imponer restricciones de integridad. Las restricciones no aplicadas tienden a ser violadas a medida que pasa el tiempo. Nadie se da cuenta. Aproveche al máximo los recursos, como las claves externas, las restricciones únicas, las restricciones de verificación y posiblemente los desencadenantes para la validación. Existen algunos trucos para abusar de las vistas indizadas para imponer restricciones de unicidad entre tablas.

Entonces, tal vez deba aceptar que la aplicación se volverá a escribir en algún momento. Si la base de datos está limpia, habrá poco trabajo de migración. Las migraciones son extremadamente caras en términos de mano de obra y defectos causados.

Desde una perspectiva tecnológica, podría ser una buena idea colocar la mayor parte de la aplicación en el servidor y no en un formulario de JavaScript en el cliente. Probablemente podrá ejecutar la misma aplicación en la misma instancia del sistema operativo durante un tiempo extremadamente largo gracias a la virtualización . Eso no es realmente bueno pero es una garantía de que la aplicación funcionará dentro de 20 años sin costosos costos de mantenimiento y hardware. Al hacer esto, al menos tiene el respaldo seguro y barato de continuar ejecutando el código antiguo y funcional.

También, encuentro que algunas pilas de tecnología son más estables que otras . Diría que .NET tiene la mejor historia de compatibilidad hacia atrás posible en la actualidad. Microsoft es muy serio al respecto. Java y C / C ++ son realmente estables también. Python ha demostrado que es muy inestable con los cambios de ruptura de Python 3. JavaScript realmente me parece bastante estable porque romper la web no es una opción para ningún proveedor de navegadores. Sin embargo, probablemente no deberías confiar en nada experimental o funky. ("Funky" se define como "Lo sé cuando lo veo").

Las otras respuestas tienen sentido. Sin embargo, creo que los comentarios sobre la tecnología del cliente están sobre complicando las cosas. He estado trabajando como desarrollador durante los últimos 16 años. En mi experiencia, siempre que mantenga el código de su cliente intuitivo, debería estar bien. Así que no hay "hacks" con marcos / iframes, etc. Solo use funciones bien definidas en los navegadores.

Siempre puedes usar modos de compatibilidad en los navegadores para que sigan funcionando.

Para demostrar mi punto, hace solo unos meses solucioné un error del milenio en el código javascript para un cliente que llevaba 17 años ejecutando su aplicación web. Todavía funciona en máquinas recientes, base de datos reciente, sistema operativo reciente.

Conclusión: mantenlo simple y limpio y deberías estar bien.

Algunos axiomas:

• La verdad sobrevive. En este contexto, serían los algoritmos y los modelos de datos, lo que verdaderamente representa el "qué" y el "cómo" de su espacio problemático. Aunque, siempre existe el potencial de refinamiento y mejora, o una evolución del problema en sí.
• Las lenguas evolucionan. Esto es tan cierto para los lenguajes informáticos como para los lenguajes naturales.
• Toda la tecnología es vulnerable a la obsolescencia. Es posible que algunas tecnologías demoren más que otras

Las tecnologías y estándares más estables (aquellos menos vulnerables a la obsolescencia) tienden a ser los que no son de propiedad y se han adoptado de forma más general. Cuanto más amplia sea la adopción, mayor será la inercia contra casi cualquier forma de cambio. Los "estándares" propietarios siempre son vulnerables a las fortunas y los caprichos de sus propietarios y las fuerzas competitivas.

Veinte años es mucho tiempo en la industria informática. Cinco años es un objetivo más realista. Dentro de cinco años, todo el problema que su aplicación debe resolver podría redefinirse por completo.

Algunos ejemplos para ilustrar:

C y C ++ han existido durante mucho tiempo. Tienen implementaciones en casi todas las plataformas. C ++ sigue evolucionando, pero las características "universales" (aquellas disponibles en todas las plataformas) están casi garantizadas para que nunca queden obsoletas.

Flash casi se convirtió en un estándar universal, pero es propietario. Las decisiones corporativas de no admitirlo en las plataformas móviles populares básicamente lo han condenado en todas partes: si está creando para la web, quiere que su contenido esté disponible en todas las plataformas; No querrá perderse el gran mercado en que se ha convertido el móvil.

WinTel (Windows / x86) a pesar de ser propietario de Microsoft e Intel, comenzó en una plataforma menos que óptima (16 bit interno / 8 bit externo 8088 versus Apple Macintosh contemporáneo 32 bit interno / 16 bit externo 68000) y la erosión de Apple en el mercado de consumo sigue siendo una opción de facto para las plataformas empresariales. En todo ese tiempo (25 años), el compromiso con la compatibilidad con versiones anteriores ha obstaculizado el desarrollo futuro e inspirado una confianza considerable en que lo que funcionó en la caja antigua seguirá funcionando en la nueva.

Pensamientos finales

JavaScript podría no ser la mejor opción para implementar la lógica empresarial. Por razones de integridad y seguridad de los datos, la lógica de negocios debe realizarse en el servidor, por lo que el JavaScript del lado del cliente debe limitarse al comportamiento de la interfaz de usuario. Incluso en el servidor, JavaScript podría no ser la mejor opción. Aunque es más fácil trabajar con otras pilas (Java o C #) para proyectos pequeños, carece de la formalidad que puede ayudarlo a escribir soluciones mejores y más organizadas cuando las cosas se vuelven más complejas.