Per esperienza personale, potrei dirti come di solito gestisco il mio codice resp. il codice della nostra squadra, quando sono in carica.
Recentemente abbiamo terminato una grande applicazione per il settore pubblico, raccogliendo dati dai partecipanti (stato lavorativo, stato civile, ecc.) nei progetti.
La parte successiva del progetto stava sviluppando un'applicazione di reporting, che riporta i dati cumulativi. Nel complesso potrebbe raggiungere 2k LOC, cosa lo rende paragonabile ai tuoi (tipici) progetti.
Eravamo due sviluppatori incaricati di questa applicazione, essendo io il "principale".
Per questo progetto ho fissato diversi obiettivi:
1) Produce risultati visibili rapidamente - enfasi sulle parole chiave »veloce« e »visibile« esattamente in quest'ordine.
Per essere veloce devi inventare cose in modo veloce e sporco . Es .: Ho creato un mockup HTML di un risultato finale, incluse caselle di selezione, selettori di data e copiato un dannato insieme di HTML da applicazioni simili.
2) Produce solo un risultato di lavoro minimo per una data iterazione. Come ho detto, per una prima bozza, c'era solo html e una "base" -applicativo che serviva l'html.
Le iterazioni successive sono state passo passo introducendo le dinamiche: compilazione automatica delle caselle di selezione, lettura parziale dei dati dal DB e visualizzazione a pagina ecc.
3) Dopo questa fase "sporca", devi avere la disciplina e rielaborare il tuo codice: metodi di refactoring, prenditi cura della coesione nelle tue classi, scrivi test. Funziona solo se hai sufficiente disciplina e sai come modellare il tuo codice.
Questo non è per le matricole, dal momento che devi avere una certa conoscenza e disciplina da pulire in seguito. (Ho menzionato la disciplina?;))
For example, say you're developing a new application. It easily can get to 3k-5k lines of code before you have anything intelligible and it still may not even work at that point.
Da quanto ho detto sopra, è assolutamente possibile avere meno di 1k LOC e avere l'impressione di un'applicazione "funzionante". Dipende dal tuo stile di sviluppo. Se hai problemi a rivedere il codice in una fase precedente, dovresti cercare di rendere chiare le attività per ogni fase di revisione. Cerca di rendere il tuo codice produrre qualcosa. I risultati sono testabili: la testabilità è la premessa di una revisione del codice. Il codice testabile è revisionabile.
If you code review in smaller/more granular steps, you might have people reviewing things that will change heavily because you're fleshing out the design as you code, so they are reviewing things that you didn't necessarily need their input on yet.
Questo comporta due problemi:
Quando per rivedere cosa ?
Non ha senso esaminare un mock come la versione di produzione . Secondo il mio esempio di cui sopra in Fase (1) e (2), non ha senso fare alcuna revisione del codice. Ho lavorato molto su (3) sul codice.
Ma durante (1) e (2) abbiamo fatto un qualche tipo di recensione:
- Il codice è abbastanza performante ?
Essendo marcio come il codice, i pilastri erano impostati, così, che potevamo fare dei test con un set di dati più grande della dimensione della produzione. Quanto tempo impiega il codice per eseguire esportazioni CSV di diverse centinaia di migliaia di voci? Ciò ha portato a lasciare alcune decisioni architettoniche a favore degli altri.
- Come funziona l'applicazione in questa fase iniziale.
Queste sono domande a cui è possibile rispondere in (1) e (2).
Le revisioni del codice sono significative solo quando il codice è in forma . Più velocemente ottieni risultati da (1) e (2), puoi andare su (3) e stabilizzare il tuo codice. Se (3) è fatto, dovrebbe esserci spazio per una revisione del codice .
To be fair, I tried this and a lot of the questions would revolve around why I'm introducing a certain class, because it wasn't clear without seeing where it was used (even with a unit test). A good portion of the time, I'd wind up reworking how that class worked, removing it or performing other refactorings at a later step that invalidated the initial purpose of the earlier review.
Il problema qui è chiaro: il codice / squadra non è focalizzato (sufficiente).
Dovrebbe essere chiaro, cosa deve fare ogni parte della tua applicazione in una determinata fase del processo di sviluppo. Quello che vedo da ciò che hai scritto è che hai speso un sacco di tempo ed energie in engineering per un caso d'uso che è troppo astratto. Dovresti concentrarti maggiormente su semplici comprensibili risultati .
Il tuo problema non è la revisione del codice di per sé, il tuo problema è mancanza di concentrazione , che rende il tuo codice non specifico e non verificabile.