L'ho spostato da Stack Overflow e questo era il posto suggerito da chiedere. Questo è stato contrassegnato come possibile duplicato di una domanda sul merito della composizione sull'ereditarietà . Non sto facendo questa domanda, sto cercando strategie per gestire lo sviluppo dato il codice che abbiamo.
Il contesto della domanda è un insieme di applicazioni scritte in C ++ con Qt. Lavoriamo in modo pseudo agile, cioè abbiamo scatti di 2 settimane ma non abbiamo rilasci frequenti.
Sono tutte variazioni di un tema, ma ognuna modifica quella precedente.
Questo non è uno scenario ideale ma con cui devo lavorare.
Quindi l'applicazione A usa Alib. l'applicazione B usa Blib e Alib; la maggior parte delle classi in Blib sono discendenti di quelli in Alib. Allo stesso modo l'applicazione C usa Alib Blib e Clib, che sottoclasse principalmente da Blib ma anche occasionalmente da Alib.
Usiamo CVS ed è un vero e proprio dolore al collo ramificare le nostre build in quanto i progetti MSVC non si fondono mai correttamente.
Ciò che accade attualmente è che uno sviluppatore che lavora su Alib può causare problemi imprevisti sia in Blib che in Clib a meno che non adottiamo alcune strategie per la revisione o regole sullo sviluppo.
Abbiamo molta pressione sul tempo e al momento non abbiamo il tempo di riorganizzare il codice, quindi sono alla ricerca di cose che possiamo fare nel quadro attuale.
Se usassimo git sarebbe più semplice suddividere il codice per ogni dev, ma di nuovo non ci siamo ancora al momento (è nella pipeline).
Sto pensando lungo la linea di richiedere tutti i nuovi sviluppi che alterano (al contrario di aggiungere) la funzionalità in ALIB per sottoclasse tale comportamento.
Altre opzioni di cui ho letto includono "fallire spesso", cioè essere sfacciati nel commettere / cambiare le cose in Alib e assicurarsi che Blib e Clib siano rivisti abbastanza spesso da tenere il passo con le modifiche.
Simile a questo è frequente revisione del codice (uno sviluppatore (io) ha una buona conoscenza di tutte e tre le librerie quindi dovrebbe essere in grado di individuare i potenziali effetti downstream in anticipo), che pone la domanda prima o dopo il commit.
Modifica: Grazie per l'ampia gamma di soluzioni, vorrei poter contrassegnare un paio di queste come risposte, ma sono andato con la risposta di John Wus. Ha articolato il mio dilemma abbastanza bene nel terzo punto - cercando di ridurre la ripetizione di noi stessi (cioè non violiamo DRY) pur avendo un certo isolamento per ogni lib. In ultima analisi, un refactor del codice è in ordine, ma più (alcuni!) Test unitari dovrebbero evidenziare il codice rotto. Uno dei problemi che abbiamo riscontrato è che lo sviluppatore di Alib avrebbe visto le loro modifiche influenzare Blib e Clib e andare a modificarle in modi che gli sviluppatori di Blib e Clib non apprezzavano esattamente. Quindi una regola sul mantenimento del codice chiuso (estendere ma non modificare) è anche molto pertinente.