Asesoramiento en el diseño de aplicaciones web con más de 40 años de vida útil.

Guión

Actualmente, soy parte de un proyecto de atención médica cuyo requisito principal es capturar datos con atributos desconocidos utilizando formularios generados por los usuarios por los proveedores de atención médica. El segundo requisito es que la integridad de los datos es clave y que la aplicación se utilizará durante más de 40 años. Actualmente estamos migrando los datos del cliente de los últimos 40 años de varias fuentes (papel, Excel, Access, etc.) a la base de datos. Los requisitos futuros son:

• Gestión del flujo de trabajo de formularios.
• Gestión de horarios de formularios
• Seguridad / gestión basada en roles
• Motor de informes
• Soporte móvil / tableta

Situación

Solo 6 meses después, el arquitecto / programador senior (contratado) actual ha adoptado el enfoque "rápido" y ha diseñado un sistema deficiente. La base de datos no está normalizada, el código está acoplado, los niveles no tienen un propósito específico y los datos comienzan a faltar ya que ha diseñado algunos beans para realizar "eliminaciones" en la base de datos. La base del código es extremadamente inflada y hay trabajos solo para sincronizar datos ya que la base de datos no está normalizada. Su enfoque ha sido confiar en trabajos de respaldo para restaurar los datos faltantes y no parece creer en la refactorización.

Habiendo presentado mis hallazgos al primer ministro, el arquitecto será removido cuando finalice su contrato. Me dieron la tarea de reestructurar esta aplicación. Mi equipo está formado por mí y un programador junior. No tenemos otros recursos. Se nos otorgó un congelamiento de requisitos de 6 meses en el que podemos concentrarnos en reconstruir este sistema.

Sugerí usar un sistema CMS como Drupal, pero por razones de política en la organización del cliente, el sistema debe construirse desde cero.

Esta es la primera vez que diseñaré un sistema con más de 40 años de vida. Solo he trabajado en proyectos con una vida útil de 3-5 años, por lo que esta situación es muy nueva, pero emocionante.

Preguntas

• ¿Qué consideraciones de diseño harán que el sistema sea más "a prueba de futuro"?
• ¿Qué preguntas deben hacerse al cliente / PM para que el sistema sea más "a prueba de futuro"?

Los datos son el rey

Creo que es un poco irracional esperar que una aplicación web alrededor del año 2013 todavía esté operativa en 2053. Las tecnologías van a cambiar. Las plataformas van y vienen. HTML puede ser una memoria pintoresca para entonces. Pero sus datos seguirán existiendo.

Entonces los datos son su enfoque principal. Mientras sus datos sigan allí, las personas podrán adaptarse a las nuevas tecnologías que surjan. Asegúrese de que sus esquemas de datos estén bien pensados ​​y sean adecuados para la expansión. Tómese su tiempo explicándolos.

Con respecto a las aplicaciones reales, su empresa probablemente tenga razón aquí al tener una directiva de "compilación desde cero". Mantengo un par de aplicaciones web de más de 10 años, y estoy muy contento de que no estén encerradas en los sistemas CMS prevalecientes de 2003. Utilizan marcos muy simples y de cosecha propia. Creo que para algo como esto es mejor que tengas un marco muy básico que crees específicamente para las necesidades del proyecto.

Pero la realidad es que, durante 40 años, la compañía (con suerte) estará haciendo bastantes servicios front-end y back-end para adaptarse a las plataformas en evolución. Entonces, dado eso, apuntaría a una vida útil de 5-10 años para aplicaciones individuales orientadas al usuario.

Producimos software que ha estado en uso pagando a los clientes durante más de 20 años. La base de código ha sobrevivido a varias generaciones de herramientas de control de código fuente. Nuestro software llega a todos sus puntos a excepción de la tableta.

Algunas de las preocupaciones incluyen ESIGN y UETA . Nuestros abogados creen que debemos mantener los registros electrónicos legibles por un mínimo de 10 años. Para los documentos que se conservan en conjunto, usted debe buscar en PDF / A .

Para su base de datos, no se preocupe demasiado por la normalización. En cambio, debe preocuparse por registrar todo y tener tablas de auditoría que rastreen los cambios / eliminaciones en los datos. Al actualizar versiones, planifique probar nuevas versiones en paralelo durante el tiempo suficiente para asegurarse de que haya migrado sus datos. Esta prueba de nuevas versiones también incluye nuevos sistemas operativos: hemos tenido algunas sorpresas desagradables a lo largo de los años. Preserve los medios de instalación y las claves de licencia en caso de que sea necesario realizar una reversión. Probar copias de seguridad. Si va a serializar objetos para almacenar en la base de datos, hágalo como XML en lugar de la serialización proporcionada por su marco de desarrollo.

Para su personal, las bases de código a largo plazo necesitan memoria a largo plazo. Idealmente, querrías personas que hayan existido por mucho tiempo. Si eso es institucionalmente imposible, entonces necesita documentar todo en algo así como un wiki. Y mi consejo es un wiki que pueda vincularse con su sistema de seguimiento de errores.

Para su base de código, asegúrese de tener comentarios en su código. La migración de un sistema de control de versiones a otro casi siempre perderá sus comentarios de check-in. Soy fanático de nombrar las pruebas unitarias después de los números de especificaciones y errores. De esa manera, si la prueba de la unidad se Test_Bug_1235 rompe, entonces sabrá qué y dónde rastrear lo que se supone que está probando. No es tan "sexy" como nombrar sus pruebas, Check_File_Save_Networked_Drivespero ese tipo de prueba es difícil de remontar a especificaciones, requisitos o errores a diferencia Test_requirement_54321_case_2.

En lugar de tratar de averiguar cómo esta aplicación seguirá funcionando dentro de 20 años, creo que debería pasar sus seis meses arreglando los problemas que encontró que el arquitecto original causó, estableció una arquitectura sensata y robusta, y avanzar desde allí.

La desnormalización parcial de una base de datos no es necesariamente completamente inesperada en un entorno médico. Algunas partes de las bases de datos médicas tienen características que las hacen adecuadas para el modelo EAV (Entidad / Atributo / Valor) .

Respuesta desde una perspectiva frontal:

No escuche a todos decir que no se puede hacer, porque un servicio web experimental de la Universidad Estatal de San Francisco que coescribí en 1996 finalmente fue a Internet hace un par de años, y nunca necesité una sola solución de compatibilidad de navegador en ese momento ; eso es casi la mitad de tu meta de 40 años. Y este front-end basado en JavaScript que hice en 1998 para un proyecto del Instituto de Investigación de Stanford fue reemplazado por algo más llamativo unos años más tarde, pero no hay razón para que la interfaz de usuario original aún no se pueda ejecutar hoy con pequeñas correcciones de compatibilidad.

El truco es asegurarse de que su aplicación utilice solo estándares W3C / ECMA ampliamente compatibles y que tenga un diseño limpio bajo su control. Si bien muchas de las aplicaciones web escritas para la moderna tecnología de la era de los 90 no funcionarán bien o no funcionan en la actualidad, las aplicaciones web de la era de los 90 escritas con los principales estándares todavía lo hacen. Pueden parecer pasados, pero funcionan.

El objetivo aquí no es escribir una aplicación web que se instale en su servidor y permanezca allí durante 40 años sin que nadie la vuelva a tocar. Es para construir una base que todavía pueda estar en uso décadas después, que puede crecer para admitir nuevas funciones sin tener que reconstruir desde cero.

En primer lugar, debe codificar según las normas oficiales y solo según las normas oficiales. No hay características de JavaScript que no formen parte de un estándar ECMAScript ratificado; ES5.1 es la versión actual y generalmente es compatible, por lo que es seguro apuntar. Del mismo modo, las versiones actuales de HTML5, CSS y Unicode son buenas. Sin funciones experimentales de JavaScript, CSS3 o HTML (las que tienen prefijos de proveedor o sin un 100% de acuerdo entre los navegadores). Y no hay trucos de compatibilidad específicos del navegador. Puede comenzar a usar una nueva función una vez que esté en el estándar y todos la admitan sin prefijos.

La compatibilidad con ES5 significaría abandonar IE8 o anterior, lo que sugiero de todos modos ya que requiere hacks específicos del navegador que serán inútiles en un par de años. Sugeriría el modo estricto de ES5 para la mejor oportunidad de longevidad, que en realidad establece la compatibilidad de su navegador de referencia en IE10 y las versiones recientes de todos los demás . Esos navegadores también tienen soporte nativo para muchas de las funciones de validación de formularios y marcadores de posición de HTML5, que serán útiles durante mucho tiempo.

Las nuevas ediciones de ECMAScript mantienen la compatibilidad con versiones anteriores, por lo que será mucho más fácil adoptar las próximas funciones si su código está escrito de acuerdo con los estándares actuales. Por ejemplo, las clases definidas usando la próxima classsintaxis serán completamente intercambiables con las clases definidas con la constructor.prototypesintaxis actual . Entonces, en cinco años, un desarrollador puede reescribir las clases en el formato ES6 archivo por archivo sin romper nada, suponiendo, por supuesto, que también tenga buenas pruebas unitarias.

En segundo lugar, evite los marcos de aplicaciones de JavaScript modernos, especialmente si cambian la forma en que codifica su aplicación. La columna vertebral estaba de moda, luego SproutCore y Ember, y ahora Angular es el marco que a todos les encanta promover. Pueden ser útiles, pero también tienen algo en común: a menudo rompen aplicaciones y requieren cambios de código cuando salen nuevas versiones y su longevidad es cuestionable. Recientemente actualicé una aplicación Angular 1.1 a 1.2, y tuve que reescribir bastante. Del mismo modo, pasar de Backbone 2 a 3 requiere muchos cambios de HTML. Los estándares se mueven lentamente por una razón, pero estos marcos se mueven rápido y las cosas que se rompen periódicamente son el costo.

Además, los nuevos estándares oficiales a menudo dejan obsoletos los viejos marcos, y cuando eso sucede, esos marcos mutan (con cambios importantes) o se quedan atrás. ¿Sabes lo que va a pasar con todas las bibliotecas de promesa del mundo una vez que se ratifique ECMAScript 6 y todos los navegadores admitan su clase Promesa estandarizada? Se volverán obsoletos y sus desarrolladores dejarán de actualizarlos. Si eligió el marco correcto, su código podría adaptarse lo suficientemente bien, y si adivinó mal, buscará una refactorización importante.

Entonces, si está pensando en adoptar una biblioteca o marco de terceros, pregúntese qué tan difícil será eliminar en el futuro. Si es un marco como Angular que nunca se puede eliminar sin reconstruir su aplicación desde cero, es una buena señal de que no se puede usar en una arquitectura de 40 años. Si se trata de un widget de calendario de terceros que extrajo con un middleware personalizado, reemplazarlo tomaría algunas horas.

Tercero, dele una estructura de aplicación buena y limpia. Incluso si no está utilizando un marco de aplicación, puede aprovechar las herramientas de desarrollador, crear scripts y un buen diseño limpio. Personalmente, soy fanático de la administración de dependencias de Closure Toolkit porque es liviano y su sobrecarga se elimina por completo al crear su aplicación. LessCSS y SCSS también son excelentes herramientas para organizar sus hojas de estilo y crear hojas de estilo CSS basadas en estándares para su lanzamiento.

También puede organizar su propio código en clases de un solo uso con una estructura MVC. Eso hará que sea mucho más fácil regresar varios años en el futuro y saber lo que estaba pensando cuando escribió algo, y reemplazar solo aquellas partes que lo necesitan.

También debe seguir los consejos del W3C y mantener la información de presentación completamente fuera de su HTML. (Eso incluye trucos como dar a los elementos nombres de clase de presentación, como "texto verde grande" y "ancho de dos columnas".) Si su HTML es semántico y CSS es presentacional, será mucho más fácil mantenerlo y adaptarlo a nuevas plataformas en el futuro. También será más fácil agregar soporte para navegadores especializados para personas ciegas o discapacitadas.

Cuarto, automatice sus pruebas y asegúrese de tener una cobertura casi completa. Escriba pruebas unitarias para cada clase, ya sea del lado del servidor o en JavaScript. En la parte frontal, asegúrese de que cada clase se desempeñe de acuerdo con sus especificaciones en cada navegador compatible. Automatice estas pruebas desde su bot de compilación para cada confirmación. Esto es importante tanto para la longevidad como para la confiabilidad, ya que puede detectar errores temprano incluso cuando los navegadores actuales los ocultan. Tanto los marcos de prueba basados ​​en JSUnit de Jasmine y Google Closure son buenos.

También querrás ejecutar pruebas funcionales de IU completas, en las cuales Selenium / WebDriver son buenos. Básicamente, usted escribe un programa que recorre su interfaz de usuario y lo usa como si una persona lo estuviera probando. Conecta esos al robot de construcción también.

Por último, como otros han mencionado, sus datos son el rey. Piense detenidamente en su modelo de almacenamiento de datos y asegúrese de que esté diseñado para durar. Asegúrese de que su esquema de datos sea sólido, y asegúrese de que también se haya probado exhaustivamente en cada confirmación. Y asegúrese de que la arquitectura de su servidor sea escalable. Esto es aún más importante que cualquier cosa que hagas en la parte delantera.

Dejando a un lado los problemas de las expectativas irrazonables de su cliente y centrándome en los problemas de diseño, no llegaría a 40 años, pero el problema que parece tener, de evolución a largo plazo, es precisamente para lo que REST fue creado. . Con eso realmente me refiero a REST como un estilo de arquitectura, no el desarrollo impulsado por palabras de moda que comúnmente se asocia con el término en estos días.

Hasta cierto punto, la gente se equivoca de REST porque no pude incluir suficientes detalles sobre el diseño de tipo de medios dentro de mi disertación. Eso es porque se me acabó el tiempo, no porque pensara que era menos importante que los otros aspectos de REST. Del mismo modo, sospecho que muchas personas se equivocan porque leyeron solo la entrada de Wikipedia sobre el tema, que no se basa en fuentes autorizadas.

Sin embargo, creo que la mayoría de la gente comete el error de que debería ser simple diseñar cosas simples. En realidad, el esfuerzo requerido para diseñar algo es inversamente proporcional a la simplicidad del resultado. A medida que avanzan los estilos arquitectónicos, REST es muy simple.

REST es un diseño de software en la escala de décadas : cada detalle está destinado a promover la longevidad del software y la evolución independiente.

http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven#comment-724

Mencionó que tiene la intención de utilizar una interfaz RESTful. Ese comentario en sí mismo sugiere que debería hacer una investigación seria al respecto e intentar comprender de qué se trata REST realmente. Probablemente lo esté asociando simplemente con la asignación de métodos HTTP a operaciones CRUD que la mayoría de la gente piensa que es REST, pero no tiene nada que ver con eso.

Piense en REST como una formalización de la arquitectura de la web en sí. De una forma u otra, hay muchas partes de la web escritas hace una década o más que todavía están disponibles y se pueden usar con un cliente creado hoy, por lo que obtuvimos algo correcto en ese departamento. Será mucho trabajo, te lo garantizo, porque hacer REST correctamente es difícil, pero los beneficios a largo plazo valen la pena.

Después de leer la pregunta y las otras respuestas (muy bien pensadas), pensé que también dejaría mis dos centavos. Nota: No tengo que mantener ninguna aplicación / software realmente antiguo. Lo que uso como referencia es mi propia aplicación web de pasatiempos de trabajo en progreso que toma algunos datos abiertos del gobierno, los analiza y los muestra en diferentes formatos. La aplicación comenzó como un proyecto en el que no estaba solo y donde el gobierno acaba de anunciar que ofrecerá estos datos de alguna manera. Así que estaba claro que muchas cosas cambiarán con el tiempo. Y lo hicieron. Lo que aprendí de esto:

• Divide las cosas en miniaplicaciones. Cada uno completamente capaz de cumplir su tarea por sí mismo. Esto hace que cambiar una sola pieza sea muy rápido, muy seguro y muy fácil. Y cuando tiene que regresar, no es realmente difícil entender por qué suceden las cosas y cómo suceden. Si usted u otra persona tendrán que cambiar algo más adelante, es más fácil reemplazar una sola parte que un conjunto completo de cosas.
• Obtenga un middleware / capa constante sólido que se use para la comunicación entre las diferentes partes. En este caso, utilicé JSON, pero XML, ini o estándares similares también estarían bien. Es fácil de repetir y se puede transformar en casi cualquier cosa. Todos son estándares probados que sobrevivirán bastante tiempo. Incluso si los datos subyacentes y / o el modelo de almacenamiento cambiarán. Cada una de las aplicaciones puede usar su propio almacenamiento de datos para su tarea específica. Esto hace que la cantidad de datos escaneados para una tarea sea más pequeña, por lo tanto, más fácil de manejar y mantener y es más fácil de intercambiar.
• No te preocupes por las decisiones del lenguaje de programación. Esos cambiarán con el tiempo. Solo asegúrate de usar el idioma con el que te sientas cómodo o que se ajuste mejor a una tarea.
• Asegúrese de que su almacenamiento de datos sea "escalable horizontalmente" y que sea fácil conectar módulos de almacenamiento adicionales.
• Obtenga un punto común (en mi caso, son URI) donde se llaman las mini aplicaciones y / o intercambian datos.

En resumen: lo que más me importa es la separación de las preocupaciones y la capacidad de intercambio de las partes asignadas para las tareas. Simplemente sabe que en 40 años (incluso en 5 o 10) el hardware, las interfaces, el almacenamiento, etc. cambiarán mucho. Y los desarrolladores posteriores tendrán que reaccionar ante esos cambios e intercambiar partes de su aplicación, ya sea el contenedor de datos o partes de la interfaz de usuario.

Para hacer las cosas tan "a prueba de futuro" como sea posible, planifique el cambio. Es decir, haga todo lo posible para no optimizar para otra cosa que no sea la capacidad de cambiar fácilmente. Por lo tanto, no hay normalización, no hay validación estricta y un acoplamiento flojo en abundancia.

• Utilice las principales tecnologías de código abierto. Para los datos, los sistemas de código cerrado son una fuente importante de riesgo, ya que no se puede planificar a qué empresas se someterán o cambiarán las estrategias, llevando consigo todo el acceso a los datos. Además, los proyectos menores de código abierto sin una comunidad vibrante también tienen más probabilidades de perder apoyo.

• Use una base de datos NoSQL sin esquema. El tipo de datos no estructurados que se utilizan está casi directamente fuera del libro de texto para un almacén de documentos como MongoDB. Las bases de datos relacionales tradicionales y su normalización son buenas cuando sabes cómo se estructurarán tus datos, pero eso es realmente una ficción, especialmente aquí. Los costos de cambiar el esquema en un RDBS simplemente aumentan a medida que el sistema se expande. Sepa que cualquier estructura que se elija ahora va a terminar cambiando.

• Desacoplar el sistema en gran medida utilizando estándares ampliamente aceptados. Romper todos los datos de acceso y mutación en los servicios web es un paso hacia esto. La combinación de eso con las colas de mensajes para enviar cambios y demás ayudará a las partes individuales del sistema a cambiar idiomas o tecnologías con el tiempo.

Bien, entonces voy a decir algunas cosas aquí que probablemente serán bastante impopulares, pero quédese aquí conmigo.

Como este es su primer proyecto en el que se supone que los datos y / o la aplicación durarán más de 20 años, y usted es el líder del proyecto, debe dar un paso atrás y pensar cuáles son las probabilidades de que este proyecto tenga éxito . Porque están básicamente al lado de cero.

Debe dedicar una gran cantidad de tiempo a centrarse en el diseño de la base de datos y hacerlo bien. Para que este proyecto tenga éxito, debe incorporar un arquitecto de datos al proyecto, y más temprano que tarde. Sin alguien que tenga experiencia en el diseño de bases de datos y que tenga una buena práctica para ver cómo se pueden usar los datos en el futuro, las probabilidades de que los datos sigan siendo útiles después de 5 años, mucho menos 40 años, son escasas o nulas.

Es de esperar que dos personas (una de las cuales tiene el título de jr. Dev) construyan algo desde cero que se espera que dure 40 años, probablemente no tendrá éxito. Debe haber un equipo de personas, muchas de las cuales tengan experiencia en trabajar con proyectos grandes como este, que trabajen en el diseño de datos, el diseño de API y el diseño de la aplicación. Algo como esto no es un proyecto de 2 personas.

El deseo de vincular el proyecto con algo como Drupal muestra por qué el proyecto necesita personas que estén acostumbradas a trabajar en este tipo de proyectos. No desea vincular la aplicación a nada que pueda pasar de moda en unos pocos años. Si lo hiciera, encontrar a alguien para trabajar en el sistema en 5-10 años podría ser muy difícil muy rápidamente.

Tomaría este consejo a la gerencia y les explicaría que necesita atraer a más personas de alto nivel en el proyecto. De lo contrario, el proyecto está condenado al fracaso, y probablemente terminará siendo el único responsable.

La aplicación no necesita sobrevivir 40 años sin ninguna evolución. Pero, debido a que debería o debería construirse desde cero, aún podría estar 'funcionando'.

Lo más importante es la 'arquitectura de datos' que permite cierta estabilidad y gobernanza, además de extensible.

Hemos diseñado una arquitectura de datos y una taxonomía que casi podría sobrevivir al fin de la humanidad pero que aún podría ser extensible. Debe encontrar una verdadera persona de TAXONOMÍA DE DATOS / ARQUITECTURA DE DATOS para que haga esto por usted.

La clave aquí es centrarse en la base de datos (como han dicho varios arriba). Esto debe ser coherente y describir completamente la operación. Necesita crecer con la operación a medida que cambia. Si no es fácil cambiar, se quedará desactualizado y ese es el beso de la muerte. El resto es relativamente menos importante.

No estoy de acuerdo con los anteriores que sugieren que la normalización no es importante, aunque siempre hay casos en los que los sistemas actuales no están a la altura. En estos casos, desnormalice pero asegúrese de que la base de datos maneje las escrituras / cambios adicionales como parte de una transacción atómica. De esa manera, puede ignorar el problema de manera efectiva hasta que pueda solucionarlo.

La compañía para la que trabajé antes de la jubilación está ejecutando un sistema que fue escrito desde cero y que ha crecido casi continuamente durante 25 años, y cubre prácticamente todos los aspectos de un minorista mediano. Los aspectos de este sistema que considero importantes son:

• La integración es vital.
• La base de datos debe ser tan correcta y comprensible tanto para TI como para el resto del personal, por lo que se requiere un énfasis casi paranoico en los nombres. Tenemos tablas de mnemónicos definidos que luego se combinan para formar nombres de tablas y campos y todos los "códigos" también se nombraron como constantes y se almacenaron en una estructura de tabla EAV.
• Encapsulamos la lógica empresarial en desencadenantes de bases de datos. Esto es doloroso al principio y requiere un trabajo adicional para transmitir mensajes de error a los clientes y permitir que los disparadores se cambien de manera flexible sin bloquear toda la tabla en algunos sistemas, pero esto rápidamente se convierte en un gran ahorro de tiempo y obliga a la base de datos a ser mucho más correcta que de lo contrario.
• Suponga que mantendrá al menos tablas de referencia (idealmente todas, excepto las transacciones más rápidas y menos importantes) durante la vida útil del sistema, incluso cuando se "elimine" para que sus referencias sean correctas.
• Debido a lo anterior, asegúrese de que los identificadores únicos y los números de transacción tengan el tamaño a largo plazo. (Originalmente sugerí en broma que debían durar hasta que me retirara).

Sugeriría usar el abastecimiento de eventos y la segregación de responsabilidad de comandos y consultas . Esto se debe principalmente a que lo único de lo que puede estar seguro es de los eventos que ya aparecieron. Pueden venir nuevos tipos de eventos. Por lo tanto, incluso si piensa mucho en un modelo, es seguro que quedará desactualizado. La migración de todos los datos con cada versión puede no ser factible. Por lo tanto, lo mejor es tener un modelo que se adapte a sus necesidades actuales y que se calcule a partir de eventos ya registrados cada vez que lo necesite y luego pasar eventos que se calculan a partir del estado actual de ese modelo.

También tenga en cuenta las pruebas. Si la aplicación está en uso dentro de diez años, los evaluadores deben asegurarse de que todavía está haciendo lo que se supone que debe hacer. Así que haga que la prueba de integración de su aplicación sea lo más fácil posible.