40% of the code is reused and 60% customized feature made to particular company
Questo potrebbe richiedere un po 'di tempo per arrivare al punto in cui puoi farlo, ma penso che dovrebbe essere un obiettivo estrarre quel 40% e renderlo il proprio repository. Questa è la tua libreria / framework principale da cui lavorare.
Quindi, quell'altro 60% può essere in repository dedicati su base client.
Sembra che il tuo codice base si qualifichi come "legacy", quindi consiglio vivamente di prendere in considerazione Lavorare efficacemente con il codice legacy di Michael Feathers per te e il tuo team. Fornisce le tecniche per portare il codice sotto test, che può anche essere usato per creare un piano per estrarre il codice in una libreria.
Come faresti a fare questo a partire da adesso? Ecco cosa farei:
- Trasforma ogni client nel proprio repository (o, se stai utilizzando qualcosa come Github o Gitlab per gestire i repository git e hai diversi repository per un client, puoi creare un'organizzazione per client, ma supponiamo 1 repository per client).
- Prendi un corso che riuso molto ed estrailo (assumendo un approccio orientato agli oggetti, sebbene uno funzionale dovrebbe avere principi simili). Lo useremo per avviare il repository della libreria (ciò lo rende utile dal primo giorno). Se non hai ancora classi complete, allora è qui che entra in gioco il libro di Feathers, che ti mostra come creare classi con codice non classificato. Mentre ci siamo, possiamo aggiungere alcuni test di base per assicurarci che faccia ancora ciò che ci aspettiamo che faccia.
- Impegnare questa estrazione come propria cosa e utilizzarla come modello per replicare la modifica su tutti i repository.
- Quando incontro parti condivise, le estraggo e le aggiungo al deposito di questa libreria.
- Man mano che la libreria cresce e trovo le cose che vengono utilizzate da alcuni client, ma non da altri, posso lavorare su un approccio modulare, in cui le funzionalità più estese vengono estratte nei loro repository e incluse come "moduli" o "plug-in" "al sistema principale. In alternativa, se ci sono temi per particolari gruppi di elementi (come un gruppo che si occupa di autenticazione o elaborazione dei pagamenti), posso estrarli nei loro repository. Come vai, esattamente, in questa fase dipende dalla natura del tuo codice e dalla direzione che vuoi seguire.
Il vantaggio di questo sistema è che tutto ciò che devi fare è aggiungere quell'elemento condiviso nella libreria e collegare tutti gli hook necessari per farlo funzionare, ed è disponibile per tutti i client, non è necessaria la copia-pasta!
Perché questo invece di rami? Mentre tecnologicamente, le filiali non sono molto diverse dai repository autonomi, le convenzioni differiscono tra loro. Un repository è un progetto completo (con riferimenti di qualche tipo, tramite sottomoduli o script, alle dipendenze), mentre un ramo è generalmente un dato stato del progetto. Si dirama quando si desidera aggiungere una funzionalità, correggere un bug o apportare un altro tipo di modifica, ma il sistema stesso è considerato lo stesso. Crei un nuovo repository quando il progetto è considerato diverso (in questo caso, per un client diverso, con le sue personalizzazioni e quant'altro).
Un buon esempio di questo è Oracle OpenOffice vs LibreOffice. LibreOffice è un fork di OpenOffice, ed è mantenuto anche dalle stesse persone. Tuttavia, LibreOffice, anche quando era tecnologicamente identico a OpenOffice (quando era stato inizialmente biforcato), era considerato un prodotto diverso. Il team ha quindi rimosso il marchio Oracle e avviato il percorso di sviluppo di LibreOffice, che ora è distinto da OpenOffice. Mentre le modifiche apportate a LibreOffice potrebbero essere entrate in una diramazione in OpenOffice, dal momento che LibreOffice è considerato un progetto diverso, ha invece bisogno del proprio repository.