"...we concluded that several small repositories is the cheaper option."
È fantastico. Dividere e conquistare. Rompi lo sforzo in pezzi logici, dai a ogni pezzo un diverso team di base, lavori come un matto per qualche mese, riunisci tutto e ...
e ...
Beh, sarà un dannato incubo. Sicuramente non sarà più economico. Perché dovrebbe essere?
Il più grande "costo" in qualsiasi progetto software è la comunicazione. Non si risparmia denaro scrivendo il codice più velocemente. Questo è il segreto che i programmatori non ammetteranno. ( Psst. Non dirlo a nessuno. Non importa quanto velocemente scrivi codice. ) Il tempo dedicato alla scrittura del codice è assolutamente sminuito dal tempo trascorso a pianificare e parlare e negoziare e combattere e parlare e incontrando e parlando un po 'di più e compromettendo e rendendosi conto che non dovresti essere compromesso e promettendo di fare meglio e urlare e desiderare e "risolvere" (non è una parola, dannazione) e tornare indietro e fare il ping e parlare e non essere in grado di dormire .
Quindi, rompi il tuo lavoro in pezzi discreti e consegna ogni pezzo a una squadra separata. Che cosa hai appena fatto? Hai aggiunto oneri di comunicazione. Se sei fortunato e i tuoi team sono perfetti, non c'è assolutamente alcuna differenza di costo tra un grande repository e alcuni piccoli repository. Se non sei fortunato (pochi lo sono), irrompere in team separati in realtà costa di più. È abbastanza difficile rimanere sincronizzati quando si è tutti nella stessa base di codice, facendo pressione sulle dita degli altri. Ora immagina quanto sarà difficile quando tre team diversi pensano che i requisiti significhi qualcosa di leggermente diverso (senza alcun modo di correggere rapidamente perché non stanno infrangendo le cose degli altri team), hanno culture leggermente diverse e, alla fine, sono molto motivato ad evitare la colpa quando le cose vanno male, quindi sono più che disposti a buttare le altre squadre sotto il bus.
Lo so, lo so ... le tue squadre sono meglio di così. Ma sono veramente? Sei abbastanza sicuro da scommettere denaro su di esso?
Guarda, in entrambi gli approcci (grande repository / molti piccoli repository) dovrai deridere un mucchio di cazzate all'inizio. Inizi a lavorare cieco. Appena possibile, non appena sono disponibili, si dovrebbe iniziare a utilizzare le implementazioni concrete dagli altri livelli. Questo identificherà presto problemi e incomprensioni. Certo, sarà un po 'accidentato, ma è molto meno accidentato rispetto allo sviluppo indipendente con una specifica tremolante e una stretta di mano, e poi piegare le cose insieme tardi.
Il mio punto è che i grandi repository / piccoli repository non sono il problema. Ciò che conta è come strutturi i tuoi team. Idealmente, i tuoi team hanno piccole identità indipendenti all'interno di un'identità coesiva più ampia. Un po 'come gli organi di un organismo o forse uno muffa di melma . Indipendentemente dal modo in cui strutturi il codice, dai a tutti la possibilità di incontrarti. Rendi la comunicazione facile. Fai insieme gli errori e risolvili presto e spesso.