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

73

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"?
Pete
fuente
59
Las pruebas futuras son una cosa, pero creo que un cliente puede solicitar un software que se espera que tenga una vida útil que sea 10x-20x más larga que el historial actual de computación móvil / tableta o 5x-8x más largo que el historial actual del idioma en uso es ... excesivamente optimista acerca de la estabilidad de un modelo de computación dado.
31
diseñar para ser "a prueba de futuro" de más de 40 años suena como un ejercicio inútil.
whatsisname
10
Para cumplir con el requisito de que una base de datos sea útil durante los próximos 40 años, lo pondría todo en papel. El papel ha demostrado su valía, mientras que el almacenamiento digital en su mayoría ha demostrado cómo perder gran cantidad de datos rápidamente. (pero, por supuesto, preservar todos los datos que deben destruirse)
Pieter B
34
¿Le darán a dos desarrolladores por contrato 6 meses para construir este sistema? ¿Recopilando años de datos heredados y anticipando nuevos requisitos décadas en el futuro? Si aún no te alejas del proyecto, comienza a correr. Esto es mucho más grande de lo que dos personas pueden manejar en cualquier cosa cerca del marco de tiempo asignado. El cliente tiene expectativas completamente irracionales y no está dispuesto a comprometer los recursos adecuados para el proyecto.
Sean McSomething
12
¿6 meses para que 2 personas diseñen e implementen una aplicación que necesita durar más de 40 años? No importa lo bueno que seas, eso suena como una configuración para el fracaso. Si no puede convencer a su organización de lo irracional que es eso, le sugiero que comience a buscar otro empleo lo antes posible.
dsw88

Respuestas:

132

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.

Gran maestro B
fuente
13
"¡posiblemente no usaremos este código en 40 años!" Es por eso que había un error Y2K para empezar. Esperar que su código sea reemplazado es una mala práctica.
DougM
71
El 'error' Y2K fue un problema de datos : se almacenaron 2 dígitos en lugar de 4. Por eso sugiero centrarse en los datos.
GrandmasterB
24
Buen punto. Teniendo esto en cuenta, si alguien realmente espera que sus datos (y posiblemente también la base de datos) estén en uso más de 40 años a partir de ahora, sería mejor diseñar la base de datos con la menor cantidad de características específicas del proveedor posible. Quien tenga que desenredar / reescribir todo su código que se base en Oracle / MS-SQL / cualquier funcionalidad especial dentro de 20 años no estará contento con usted. ;)
FrustratedWithFormsDesigner
44
Este es un consejo sólido. Todavía hay muchos programas Cobol en ejecución que se escribieron originalmente hace 20-30 años. Aunque la tecnología avanza, si sus datos y modelo de objetos son sólidos y los datos siguen siendo interesantes, su código seguirá en uso de una forma u otra.
Bobble
77
Desde que alguien mencionó el Y2K: tenga en cuenta el UNIX Y2K ( en.wikipedia.org/wiki/Year_2038_problem ).
MrFox el
40

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.

Tangurena
fuente
Gracias por compartir tus experiencias. Definitivamente necesito que se realicen algunas de ellas, ya que el arquitecto actual no ha comentado nada de su código ni nos ha proporcionado ninguna documentación. Ha sido una pesadilla logística, pero espero cambiar eso. El PDF / A es algo que definitivamente investigaré, ya que es algo que nuestro cliente necesitará, especialmente para la auditoría. ¡Gracias de nuevo por tu consejo!
Pete
44
Esta es una respuesta integral y bien pensada. Usted hace algunos buenos comentarios sobre la importancia de la auditoría, tanto para los cambios en los datos como para la calidad de los mismos, pero también por razones legales detrás del seguimiento de quién está viendo qué datos, vea HIPAA . Si su software se va a utilizar en los Estados Unidos, tendrá ciertas restricciones y requisitos de seguridad que exige esta ley.
maple_shaft
3
... al menos SVN a git es posible con el historial de confirmación completo.
feeela
No solo SVN a Git, sino la mayoría de los sistemas que no son de la edad de piedra, aunque los antiguos como CVS a menudo necesitan un ajuste manual con reposurgeon. La mayoría de los exportadores también emiten un flujo de exportación git-fast, que es lo suficientemente simple como para que también pueda ser importado por VCS no Git.
Grawity
2
Le sugiero que no nombre las Pruebas solo después de los números de Seguimiento y especificación de errores, ya que: a) los números de error tienden a comenzar desde 0 (ya que a nadie parece gustarle> se intercambian números de 5 dígitos y se intercambia el software de seguimiento de errores; b) las especificaciones tienden perderse (feo pero sucede con bastante frecuencia); c) Los nombres sexys suelen dejarlo lo suficientemente claro. Sin embargo, tener una referencia a la identificación de especificación / error siempre es una buena idea.
bernstein
29

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) .

Robert Harvey
fuente
2
@ user2708395 Tenga cuidado con el diseño de EAV ya que podría no ser el más eficiente o fácil de consultar. También podría no ser una buena opción para informar.
maple_shaft
@maple_shaft Eso es lo que he leído también. Voy a ser muy cauteloso con eso, ya que escuché algunas historias de horror donde la gente lo usa en exceso. Analizando el uso de alguna base de datos de informes para facilitar la consulta, ya que el cliente solo genera informes una vez al mes.
Pete
44
@maple_shaft: por lo general, los datos se extraen del esquema / base de datos EAV a un esquema / base de datos de informes por separado.
FrustratedWithFormsDesigner
@FrustratedWithFormsDesigner Ese es un excelente punto. La flexibilidad en su esquema que proporciona EAV no tiene comparación, pero ciertamente no es una bala de plata para toda persistencia.
maple_shaft
Si bien concederé que se pueden usar EAV, te sorprenderías de las relaciones que puedes encontrar. Dicho esto, los atributos adicionales que a menudo aparecen para este tipo de industrias (atención médica, relaciones con los clientes, etc.) tienen que ir a algún lado ... Solo asegúrese de respaldarlo con una tabla de claves de atributos, para obtener una lista canónica de atributos.
Clockwork-Muse
13

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.

Richard Connamacher
fuente
1
El buen consejo sobre 'marcos JS' se aplica también a los marcos de back-end. Vea el consejo del tío Bob Martin .
Brian Low
Francamente, sería cauteloso con JS por completo dado el contexto. Me imagino que HTML estará en 40 años; No confiaría en el convertidor que se esté utilizando para admitir necesariamente JS de la manera que desee (y considere que su JS posiblemente está haciendo lo incorrecto ya que el dispositivo de salida preferido puede ser inimaginablemente diferente).
Eamon Nerbonne
10

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.

Pedro Werneck
fuente
¡Esto es muy útil! Gracias. Estaba investigando un poco más sobre REST y puedo ver sus enormes beneficios y cómo se puede extender más allá de los métodos HTTP. Es algo muy poderoso y estoy muy emocionado de trabajar con él. Gracias por el enlace también! ¡Solo desearía tener más tiempo!
Pete
9

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.

emperador
fuente
1
Muy buen consejo! Gracias. Definitivamente estoy de acuerdo con la separación de tareas y la creación de mini aplicaciones. La compilación actual está unida, lo que dificulta la integración de nuevas características y requisitos. Espero usar una interfaz RESTful y usar JSON. No me quejo, pero cuando me uní por primera vez, el arquitecto offshore no me dejó usar JSON. Así que le dije que estaba pasando "cadenas" y omití la parte de que estas cadenas estaban en formato JSON. :)
Pete
7

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.

phlogisticfugu
fuente
Desafortunadamente, el uso de una base de datos sin esquema no significa que la reestructuración y la reorganización de los datos tengan un costo cero.
Alex D
4

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.

mrdenny
fuente
3

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.

Alex S
fuente
Creo que el fracaso de este proyecto desde el principio es que se inició sin un arquitecto de datos adecuado. Este es definitivamente un buen consejo.
Pete
Es hora de llamarme y contratarme :) Haciendo algo de gobernanza de datos y taxonomía para algunas empresas mientras hablamos :)
Alex S
3

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).
Bush Al
fuente
2

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.

SpaceTrucker
fuente