Come condividere una base di codice tra più di 10 progetti e minimizzare il dolore?

Il livello di dati condivisi sembra una buona idea. La soluzione per minimizzare il dolore è:

1. crea moduli di test che generano eccezioni (come: tutto smette di funzionare non solo un messaggio) quando alcuni test falliscono.
2. Metti TUTTI i moduli di test nella cartella condivisa. Voglio dire che tutti i moduli di test di 10+ progetti devono essere nella stessa cartella (o un percorso facile da capire).
3. Se un programmatore desidera modificare il livello critico, deve eseguire tutti i test in quella cartella, se qualcosa non funziona non può eseguire il commit del codice.

In questo modo, se faccio un pezzo di codice, sono motivato a scrivere una buona classe di test, come una vera classe di test, perché se la mia classe di test esplode con qualche modifica significa che quelle modifiche infrangeranno il mio codice. Quindi ogni programmatore è costretto a scrivere un buon test (se non lo faccio il mio codice potrebbe rompersi di volta in volta). Eseguire i test di tutti i progetti senza errori significa: "ok puoi commettere", quando qualcosa va storto significa "no, quelle modifiche potrebbero rompere il sistema in qualche riga x"

Questo è un buon punto perché i test sono troppo spesso lasciati indietro in un progetto ... ovviamente mantenere il codice di test richiede un ulteriore sforzo.

Ho sperimentato questo problema di prima mano. È difficile e stavo solo integrando cinque applicazioni. Posso offrire alcuni suggerimenti:

1. Disaccoppia il database utilizzando i servizi RESTful per quante più cose possibile. Ciò consente di creare facilmente più versioni dell'interfaccia, se necessario, e semplifica notevolmente le migrazioni dei database.
2. Se l'accesso al database per alcune applicazioni è di sola lettura, creare visualizzazioni del database dei dati necessari. Se devi eseguire un processo batch per calcolare i valori, fallo in una vista materializzata.
3. Pensa attentamente al design. Probabilmente qualsiasi modifica al database interromperà altre applicazioni. Tutte le app necessitano davvero di un accesso completo al database? In caso contrario, interromperli per utilizzare un servizio. Disaccoppia qualsiasi accesso al database da qualsiasi logica.

La risposta breve è che hai bisogno di dedicare molto tempo al tuo codice condiviso per renderlo il più affidabile / solido / affidabile possibile.

Come stai scoprendo, non puoi permetterti di cambiare molto spesso il codice della tua biblioteca.

Potrebbe essere necessario suddividere il livello dati in due parti: una parte di basso livello che fa cose molto semplici ma che non cambia mai (cioè, il codice condiviso) e una parte di alto livello che potrebbe dover essere univoca per ogni applicazione.

Per la porzione condivisa di basso livello, devi pensare come uno sviluppatore di librerie e amp; non uno sviluppatore di applicazioni. Ciò significa un sacco di test unitari, un'interfaccia dell'applicazione chiaramente definita e completa, una documentazione corretta, completa e utile e un sacco di codice difensivo - tutti gli input non sono validi fino a prova contraria.

Il codice condiviso dovrebbe essere scritto per soddisfare le esigenze delle applicazioni che hai oggi che useranno il codice, ma vorrai inserire il tempo extra per considerare come funzionerà questo codice per le prossime dozzine di applicazioni che hanno è stato proposto ancora. In altre parole, il codice condiviso risolve il problema generale di esporre i dati in modo significativo ai suoi consumatori. Se fatto bene, i nuovi consumatori possono utilizzare questa libreria senza modifiche.