¿Cómo compartir una base de código entre más de 10 proyectos y minimizar el dolor?

Tengo varias aplicaciones que comparten los mismos datos en la misma base de datos. Para intentar minimizar la redundancia de código, la capa de acceso a datos es un proyecto compartido. Esto evita que cada proyecto necesite volver a codificar su propio acceso a datos, pero esto también crea un gran problema. Cuando un equipo necesita actualizar la capa de datos, todos los demás equipos deben ingresar y probar los cambios para asegurarse de que no hayan roto nada y este es un proceso lento y doloroso.

He pensado en la idea de eliminar la capa de datos compartidos y solo hacer que cada equipo administre su propia capa de datos, pero el problema es que todos los equipos aún acceden a la misma base de datos, por lo que si hay cambios en la tabla, el punto débil sigue ahí porque cada equipo necesita actualizar su código relevante.

Entonces, mi pregunta es, ¿cómo podría diseñar nuestros datos y la capa de acceso de modo que muchos proyectos se desvíen de la misma fuente de datos y minimizar el dolor de realizar cambios en la base de datos o la capa de acceso?

La capa de datos compartidos parece una muy buena idea. La solución para minimizar el dolor es:

1. hacer módulos de prueba que arrojen excepciones (como: todo deja de funcionar, no solo un mensaje) cuando falla alguna prueba.
2. Coloque TODOS los módulos de prueba en la carpeta compartida. Me refiero a que todos los módulos de prueba de más de 10 proyectos deben estar en la misma carpeta (o una ruta fácil de entender).
3. Si un programador quiere editar la capa crítica, debe ejecutar todas las pruebas en esa carpeta, si algo no funciona, no puede confirmar el código.

De esta manera, si hago un fragmento de código, estoy motivado para escribir una buena clase de prueba, como una clase de prueba real porque si mi clase de prueba explota con alguna modificación significa que esa modificación romperá mi código. Por lo tanto, cada programador se ve obligado a escribir una buena prueba (si no lo hago, mi código podría romperse de vez en cuando). Ejecutar las pruebas de todos los proyectos sin errores significa: "está bien, puede comprometerse", cuando algo sale mal significa "no, esas modificaciones romperían el sistema en alguna línea x"

Este es un buen punto porque las cosas de prueba a menudo se dejan atrás en un proyecto ... por supuesto, mantener el código de prueba requiere un esfuerzo adicional.

He experimentado este problema de primera mano. Es difícil, y solo estaba integrando cinco aplicaciones. Puedo ofrecer algunos consejos:

1. Desacoplar la base de datos mediante el uso de servicios RESTful para tantas cosas como sea posible. Esto le permite crear fácilmente múltiples versiones de interfaz si es necesario, y facilita mucho las migraciones de la base de datos.
2. Si el acceso a la base de datos para algunas de las aplicaciones es de solo lectura, cree vistas de la base de datos de los datos necesarios. Si tiene que hacer un proceso por lotes para calcular valores, hágalo en una vista materializada.
3. Piensa cuidadosamente sobre el diseño. Cualquier cambio en la base de datos probablemente romperá otras aplicaciones. ¿Todas las aplicaciones realmente necesitan acceso completo a la base de datos? Si no, divídalos para usar un servicio. Desacoplar cualquier acceso a la base de datos desde cualquier lógica.

La respuesta breve es que debe dedicar MUCHO tiempo a su código compartido para que sea lo más sólido / sólido / confiable posible.

Como está descubriendo, no puede permitirse que su código de biblioteca cambie muy a menudo.

Puede ser necesario dividir su capa de datos en dos partes: una parte de bajo nivel que hace cosas muy simples pero que nunca cambia (es decir, el código compartido) y una parte de alto nivel que puede ser única para cada aplicación.

Para la porción compartida de bajo nivel, debe pensar como un desarrollador de bibliotecas y no como un desarrollador de aplicaciones. Esto significa muchas pruebas unitarias, una interfaz de aplicación muy clara y completamente definida, documentación correcta, completa y útil, y mucho código defensivo: todas las entradas no son válidas hasta que se demuestre lo contrario.

El código compartido debe escribirse para satisfacer las necesidades de las aplicaciones que tiene hoy que usarán el código, pero querrá dedicar tiempo adicional para considerar cómo funcionará este código para las próximas docenas de aplicaciones que no han sido utilizadas. propuesto todavía. Dicho de otra manera, el código compartido resuelve el problema general de exponer los datos de manera significativa a sus consumidores. Si se hace bien, los nuevos consumidores pueden usar esta biblioteca sin cambios.