Team remoti: come costruire una comprensione condivisa di basebase e architettura?

Naviga le tue risposte
1

Situazione:

C'è un team remoto di 6 sviluppatori in 4 diversi paesi. Usa CI, controllo versione, Slack e ha una chiamata di stato settimanale. Eseguono revisioni del codice su ogni richiesta pull (sempre lo stesso revisore). Tuttavia non ci sono regole formali sull'organizzazione del codice, lo stile e il layout. Alcuni membri del team lavorano part-time, quindi una soluzione giornaliera non è un'opzione.

Il problema:

La conoscenza delle funzionalità sviluppate è 'siled' - ogni sviluppatore è generalmente a conoscenza di una parte isolata del codice base su cui sta lavorando. Le attività sono definite in un tracker dei problemi e il team discute ciò che ogni sviluppatore fa sulla chiamata settimanale. Tuttavia, le caratteristiche sono di natura complessa ed è difficile capire veramente cosa sta succedendo senza guardare il codice. Di conseguenza, il team ha rilevato che alcune funzionalità sono state duplicate 3-4 volte. Poiché diversi sviluppatori hanno stili di codifica diversi (ad esempio la profondità di ereditarietà, la lunghezza della linea e così via), alcune funzionalità sono difficili da mantenere e l'evoluzione della base di codice viene trascinata in direzioni ortogonali.

La domanda:

Quali sono alcune procedure specifiche che questo team può implementare, in modo che ci sia una comprensione condivisa del codice base e dell'architettura?

    
posta Alan Stark 27.01.2017 - 09:30
fonte

2 risposte

1

La tua lingua o struttura generalmente ha una guida di stile. A seconda della lingua o del framework utilizzato, potrebbe essere sufficiente per normalizzare lo stile del codice. È possibile integrare la verifica automatica dello stile nel processo di configurazione a seconda di quale tooling è disponibile nella propria lingua, anche se ottenere la base di codice corrente in uno stato che è accettabile per lo strumento può essere una quantità significativa di lavoro.

Per quanto riguarda i silos della conoscenza, potresti provare ad espandere il tuo processo di revisione. Tutti dovrebbero rivedere tutto il codice. Ciò aiuterebbe anche a unificare lo stile utilizzato poiché tutti sarebbero esposti allo stile di tutti gli altri.

Per condividere l'architettura corrente, procurati alcune immagini che descrivono la situazione e prendi il tempo di esaminarle e inoltrare eventuali domande. Si spera di poterli generare dallo stesso codebase.

    
risposta data 27.01.2017 - 14:06
fonte
1

L'intesa condivisa deriva principalmente dalla conversazione condivisa su ciò che costruirai, sul perché e sul come. Anche quando distribuito sarebbe di grande aiuto se potessi avere un incontro insieme dove discuti del lavoro. Soprattutto quando stimare il lavoro in comune 'prima del lavoro' si potrebbe appoggiarsi tende a venire fuori.

Altrimenti, ti aspetteresti che un team guidato mantenga in qualche modo una visione d'insieme e possa iniziare a fare qualcosa mentre indichi il codice esistente che potresti riutilizzare o adottare se necessario.

Il revisore che hai menzionato potrebbe anche considerare come una nuova parte di codice si fonderà con la base di codice esistente, se c'è una duplicazione la recensione potrebbe indicarlo ...

Se il sistema è troppo grande per consentire a una sola persona di mantenere una visione d'insieme, si potrebbe prendere in considerazione l'assegnazione di una persona di "backup" per ogni componente / area che altrimenti sarebbe un silo. Se non si sta codificando attivamente su di esso, la persona di backup potrebbe avere almeno una comprensione di ciò che fa il componente, quali modifiche sono state applicate, per quale motivo e fare revisioni di codice per ottenere una comprensione più profonda di come è stato messo insieme.

    
risposta data 27.01.2017 - 10:28
fonte

Leggi altre domande sui tag

Qual è una buona tecnica per supportare l'ordinamento e il filtraggio con una WebAPI REST Il miglior approccio per imparare OpenCV da usare con Swift? [chiuso]