Sta cercando frammenti di codice casuali utili per determinare rapidamente la qualità di un progetto?

Quanto sarebbe facile per me correggere un errore in questo codice?

Ogni volta che incontro un nuovo codice base mi pongo questa domanda.

Familiarizzarmi rapidamente con il codice mi consente di identificare un terreno comune con gli sviluppatori che lo hanno creato. Tendo a cercare quanto segue (in nessun ordine particolare):

• uso coerente delle convenzioni di denominazione
• un'avversione a rendere complesso il codice - aderendo al principio KISS
• unit test che funzionano fuori dalla scatola
• un breve file readme che descrive il progetto con suggerimenti utili per comprendere
• buoni commenti
• uso di schemi di design dove appropriato
• stile coerente nei commenti e nel layout del codice
• uso di librerie di supporto note e rispettate (ad es. Boost, Guava ecc.)
• presenza di idiomi linguistici

Quanto più di quanto sopra è presente, tanto maggiore è la mia fiducia nelle capacità e nell'esperienza degli sviluppatori, così quando l'inevitabile WTF ?! Il momento è che sono molto più incline a guardare a me stesso per la mancanza di comprensione del dominio del problema che a supporre che lo sviluppatore originale abbia commesso un errore.

Se fai una sola scelta, probabilmente lo fai male. :) Oltre a ciò questo è essenzialmente un campionamento casuale , un approccio piuttosto rispettabile per raccogliere informazioni in casi come quelli che descrivi. Per ulteriori dettagli scientifici su come ciò potrebbe essere fatto, studia il metodo Monte Carlo .

Per quanto riguarda le cose da cercare, considera la ricerca, lo studio e la personalizzazione per le tue esigenze specifiche alcuni code-review checklist.

Alcuni aspetti che meritano di essere presi in considerazione durante la valutazione di un progetto sono elencati di seguito ( elenco di controllo riepilogato dalla mia esperienza passata ):

• Rilascia (insieme a changelog), controllo delle versioni e pubblicazione della disciplina
  In genere è molto più facile indagare sui problemi quando si può dire che è stato trovato un bug nella versione 1.2.3, disponibile per il download a some URL di oh due anni fa qualcuno mi ha inviato una mail con binario allegato .

• Documentazione per gli sviluppatori, esempi di riferimento e esempi di API
  Aiuta a evitare sforzi sprecati per reinventare la ruota e le basi di apprendimento per tentativi ed errori.
  Nota che questi possono anche essere campionati casualmente per uno studio veloce.

• Monitoraggio dei bug
  Se non c'è traccia, è un'enorme bandiera rossa; se ce n'è uno, considera di controllarlo rapidamente usando lo stesso approccio campionamento casuale come fai per il codice sorgente

• Feedback positivo
  Scopri gli utenti del progetto e prova a fare uno campionamento casuale del loro feedback.

Penso che questo metodo mostri piuttosto le abilità stilistiche e la capacità di rendere leggibile il codice, ma non dice nulla sulle capacità logiche, analitiche e di risoluzione dei problemi degli sviluppatori che lavorano sul codice.

Quindi quando analizzi il codice in questo modo, ottieni informazioni solo su come "buono" appaia il codice e se sia leggibile o meno. Ma ancora non hai idea se il codice è ottimizzato, se funziona bene, se è ben strutturato, ecc.

Le caratteristiche su cui presti attenzione sono molto importanti. Mostrano se il codice è leggibile e mantenibile. Ma ci sono molti programmatori che offrono soluzioni eccellenti ma non prestano molta attenzione ai commenti e allo stile (che ritengo sia molto più facile da imparare rispetto alla programmazione stessa).

Sì, penso che sia una buona idea. I progetti che sono scritti male hanno più probabilità di essere abbandonati.

Ma non basare la tua decisione su questo. la storia del codice sorgente di imho e il numero di committer sono un fattore molto più importante.

Penso che guardare piccole sezioni di codice sia un ottimo modo - se è codificato bene, le variabili / classi / metodi sono ben definiti e commentati bene, quindi capire cosa fa una piccola sezione e quale dovrebbe essere il suo scopo facile. Se hai una grande difficoltà nel capire un piccolo blocco (come qualsiasi cosa di coppia), allora probabilmente non è codificato molto bene.

a meno che i campioni siano molti e grandi, ci sono ottime possibilità che non otterrai una buona sezione trasversale del codice base. Potresti finire con i pochi pezzi buoni o le poche mele marce abbastanza facilmente.