Garantire l'integrità concettuale nel progetto Python con più programmatori

Mi piace la risposta di GlenH7, e credo che là ci sia la verità.

Tuttavia, la mia prospettiva è che la risposta ai tuoi problemi è la proprietà del codice.

Se cinque grandi team stanno riutilizzando le stesse classi di modelli e vogliono accumulare inutili schifezze su di loro, allora l'unica via d'uscita è dire "Il Team X possiede questo codice, se vuoi cambiarlo parla con loro ". Oppure, "John possiede questo codice, se vuoi cambiarlo, parla con lui."

Hai ancora bisogno di comunicazione, ma la sua natura cambia. Il presupposto è che la tua richiesta di cambiamento verrà abbattuta a meno che non ci sia un buon motivo per inserirla. Inoltre, questo crea un organo decisionale con una parola finale, piuttosto che un codice di proprietà condivisa modificato da un "comitato di progettazione" (che spesso porta al caos o alla paralisi dell'analisi).

Considera anche questo: non c'è nulla di magico nelle interfacce Java. Forniscono alcuni suggerimenti di design dall'architetto (si spera intelligente), ma non proteggono da qualcuno che ha bisogno di un trucco rapido per entrare e cambiare le interfacce comunque. L'unica cosa che protegge davvero da questo è il controllo del codice, la proprietà del codice e un certo grado di responsabilità personale.

Quindi, se stai affrontando una follia di "interfaccia", designare persone responsabili per questo e allocare la proprietà del codice. Assicurati che queste persone svolgano il loro lavoro.

Penso che ti stia concentrando troppo sulla lingua che stai utilizzando e non sulla vera sfida che devi affrontare con te e il tuo team. Ricorda che non ci sono proiettili d'argento.

In definitiva, il tuo problema è la governance. Poiché la governance è davvero l'unico modo per ensure conceptual integrity per qualsiasi progetto.

La necessità di governance segue un percorso lineare o esponenziale correlato alla dimensione della squadra. Quando aggiungi divisioni geografiche e culturali, stai semplicemente accumulando un bisogno di governance.

Ci sono alcuni semplici modi per iniziare.

Se nessuno vuole scrivere tutta una serie di documenti, assicurati che il codice sia commentato in modo libero e corretto. Evita di sporcare con i tuoi commenti, ma assicurati che gli altri comprendano i contratti che ogni sezione di codice soddisfa.

Se non vuoi che gli altri accedano a parti specifiche del codice e non riesci a incapsularlo, dovresti inserire dei commenti in quelle aree per indicare cosa può e non può essere utilizzato. Anche se il linguaggio non lo supporta direttamente, puoi comunque prendere in giro interfacce e oggetti chiusi all'interno del codice. FWIW, ho scritto codice stile OO in C. può essere fatto.

Uno dei modi in cui si applica l'incapsulamento è la revisione del codice. Gli anziani tribali di ogni squadra devono rivedere tutto il nuovo codice prima che sia permesso alla build. Se hai un architetto, devono essere in costante comunicazione con gli anziani della tribù per assicurarsi che capiscano la visione e che tutti siano d'accordo su come verrà costruito il progetto.

La direzione deve sostenere l'architetto e gli anziani alla prima scaramuccia. Qualcuno infrangerà le regole e insisterà perché è dietro la scadenza. Non farlo Schiaffeggia gentilmente il polso del violatore; costringerli a risolvere il codice; quindi consentire il commit. La direzione deve rinunciare alla scadenza per garantire l'integrità del progetto. Sì, hai perso una scadenza ma devi concentrarti sull'obiettivo a lungo termine.

Come menzionato nei commenti; tutti dovrebbero scrivere test unitari per il loro codice. Assegnare quell'attività a una singola persona sta configurando il progetto in modo errato. Usa quei test per rafforzare l'incapsulamento e le regole necessarie per stabilizzare il tuo progetto. Se il nuovo codice non ha un test unitario, non consentire che il requisito sia contrassegnato come completo.

Garantire l'integrità di un progetto è responsabilità di tutti, ogni livello assume diversi aspetti in base alla propria funzione lavorativa.