Come documentare e progettare peer review in mischia? [chiuso]

Question

Come documentare e progettare peer review in mischia? [chiuso]

#1 da (1 voti)
#2 da (1 voti)

3

Sono uno sviluppatore relativamente nuovo in una piccola azienda (un team di 3 sviluppatori e un ramo QA altrettanto piccolo) che lavora su un sistema di medie dimensioni. L'iterazione corrente è ancora sotto 100k linee di codice (server e client combinati), ma potrei immaginare che, a lungo termine, la dimensione totale potrebbe essere di 200 kLOC o più. Stiamo tentando di utilizzare Scrum per lo sviluppo e stiamo lavorando per una valutazione di livello 2 CMMI.

Stiamo adottando metodi di revisione tra pari per verificare la nostra progettazione del software e il codice sorgente. Sollecitiamo i requisiti software durante la riunione di pianificazione sprint e documentiamo i requisiti software in un SRS principale. Questo ci dà anche un inizio nella progettazione del software, ma non abbiamo un metodo formale per rivedere i concetti di progettazione, come la progettazione OO, la progettazione dell'interfaccia utente, i modelli di progettazione riutilizzabili e altro ancora. Per il nostro codice sorgente, stiamo provando nuove tecniche, come l'utilizzo di fogli di calcolo per documentare recensioni e recensioni pass-around via e-mail, ma può essere difficile per il revisore comprendere i concetti di design semplicemente guardando il codice sorgente.

(Per favore scusami se sto travisando concetti, stiamo provando molto da zero.

Non siamo contrari all'utilizzo di UML per esprimere classi, oggetti, interfacce software, modelli di eventi o altri concetti di progettazione, ma non siamo sicuri di quando o come rivedere i nostri sforzi di progettazione. Spesso, uno sviluppatore può completare il 70% con una storia utente e realizzare che un elemento di progettazione fondamentale deve essere modificato (e, successivamente, sottoposto a peer review).

Nel tentativo di evitare discussioni aperte sull'argomento e promuovere risposte concise, proverò a proporre due domande specifiche:

Qualcuno sa di buone risorse (libri, articoli, articoli) sulle migliori pratiche di peer review dei concetti di design?
Ho letto che il codice stesso è la (implementazione del) design. La revisione tra pari del codice sorgente può essere utilizzata come revisione tra pari del design?

Grazie.

code-reviews documentation scrum cmmi

posta David Kaczynski 05.08.2012 - 18:13

fonte

2 risposte

1

Il design è oggigiorno fatto esclusivamente in UX, hanno vaste risorse su come fare recensioni di design.

Ci saranno un sacco di persone in 10 minuti che ti dicono che non stai facendo Agile bene, dimenticalo: stai facendo software, il software non è una religione, Agile lo è. Fintanto che crea un buon software abbastanza velocemente, va bene.

Personalmente, farei diagrammi di flusso di dati o qualsiasi cosa che assicuri che tutte le informazioni richieste siano disponibili in ogni momento del processo. Il flusso di dati e i suoi amici (diagrammi di flusso arricchiti con manipolazioni di input / output, ecc.) Sono un ottimo modo per acquisire elementi mancanti.

Anche i test collaborativi di UML sono facili: uno di voi si prepara disegnandolo su carta, poi raduna il team e inizia a disegnarlo su una lavagna passo passo, chiedendo se c'è qualcosa di sbagliato nel suo treno di pensieri.

In questo processo, assicurati di

in primo luogo, articolare l'obiettivo dell'utente finale del progetto dato
valuta tutti i requisiti, magari scrivili sulla lavagna
fai il disegno
indica punti problematici durante il disegno, ponendo l'accento su di essi.

Abbiamo avuto queste sessioni di progettazione quasi ogni giorno quando ero in una startup paragonabile a quello che hai ora.

Puoi farlo anche su codice sorgente, ma ricorda sempre: un codice sorgente è lì per spiegare il problema a un computer. A seconda del linguaggio prescelto e del problema in questione, la lingua corrente potrebbe o potrebbe non essere efficace nello spiegarlo agli umani.

risposta data 05.08.2012 - 20:43

fonte

Leggi altre domande sui tag code-reviews documentation scrum cmmi

Il sovraccarico dell'operatore è supportato in C Dove (se c'è) è il glossario IEEE più nuovo del 1990?

score 1 · Accepted Answer

Penso che ci siano 3 cose che aiutano il buon design:

Accoppia programmazione . In questo modo, assicuri che più persone sappiano come funziona il progetto e come cambiarlo se non è più adatto ai requisiti attuali.
Test delle unità . Facendo TDD, puoi assicurarti che il design sia abbastanza semplice da comprendere e successivamente cambiare.
Ora . Nello sviluppo iterativo, il design si evolve nel tempo. Nessuno può dirti se il design è buono o cattivo al momento della creazione. Solo dopo che il design è cambiato alcune volte le persone possono dire se il design è stato facile da capire e modificare.

P.S. Chiediti cosa ti darà la recensione del codice. Agile significa consentire agli sviluppatori di dare loro la libertà di definire il proprio processo. Se non sai cosa aspettarti da un qualche tipo di processo, allora c'è un'alta possibilità che tu non abbia bisogno di quel processo.