Come valutare la qualità del codice Rails?

In genere è facile determinare la qualità del codice e non ha nulla a che fare con Rails o Ruby.

1. Tutte le funzioni devono essere comprese tra meno di 8 righe.
2. Nessuna funzione dovrebbe avere più di due livelli di rientro.
3. I nomi dovrebbero essere comunicativi ed espliciti.
   3a. Le variabili in corto raggio dovrebbero avere nomi brevi. 3b. Le variabili con scope lunghe dovrebbero avere nomi lunghi. 3c. Le funzioni con scope lunghe dovrebbero avere nomi brevi. 3d. Le funzioni in ambiti ristretti dovrebbero avere nomi lunghi.
4. Il codice dovrebbe leggere come una prosa ben scritta e avere pochi commenti.
5. Mentre leggi il codice non dovresti cercare le definizioni delle variabili e delle funzioni chiamate. Dovrebbero essere ovvi.
6. Le chiamate di funzione dovrebbero avere 3 o meno argomenti, con una preferenza per meno.
7. La copertura del test unitario dovrebbe essere vicina al 100% e il programmatore dovrebbe conoscere il numero di copertura.
8. I test unitari dovrebbero essere brevi, facili da leggere e facili da capire. Dovresti essere in grado di capire il programma leggendo i test.
9. I test dovrebbero essere eseguiti molto rapidamente. I test di lunga durata sono un sintomo di noncuranza.

Cerca i segni di incuria come il codice commentato, i commenti senza senso, i nomi abbreviati inutilmente, le funzioni lunghe, le lunghe liste di argomenti, ecc.

Chiediti se il codice assomiglia al programmatore.

Se vuoi qualcosa di specifico su Rails - guarda se ci sono regole di business negli oggetti attivi. Questo è un sintomo di un design disattento.

Ho convenuto che è importante non reinventare la ruota, ma non sarei troppo critico sui moduli che scelgono. La tua pignoleria su RSpec / Test :: Unit ti farà probabilmente perdere qualche buon codice. Allo stesso modo con un hpricot / nokogiri, ecc. Potresti percepirne uno che si allontana dall'altro, ma potrebbe non essere la percezione di uno sviluppatore di talento (o forse hanno implementato funzioni interessanti rispetto alla scrittura del modulo stantio).

Per quanto riguarda una lista di controllo di qualità, sbaglio dal lato della bellezza:

• Il codice sembra abbellire sulla pagina? (Mi rendo conto che questo è soggettivo, ma a qualcuno che "ottiene" ritengo che sia la migliore misura di eccellenza.)
• La semantica è coerente per tutto il progetto?
• ActiveModel se appropriato
• Le migrazioni sono sfruttate al massimo del loro potenziale?
• Ambiti e relazioni nel contesto appropriato?
• Utilizza gli attributi virtuali?
• La creazione di oggetti complessi viene gestita in fabbrica?
• Utilizza in modo efficace la meta-programmazione per rendere il progetto pulito e ordinato?
• Le viste sono prive di logica?
• Infine, un altro elemento soggettivo ma importante: il codice si sente come se lo sviluppatore amasse il progetto e volesse fornirlo con la massima cura possibile.

Tutto ciò che devi valutare è se il codice è facile da capire , ben strutturato e sufficientemente logico per qualcuno che ha ottenuto buoni voti nei corsi di scienze delle scuole superiori.

Tutto ciò che hai menzionato riguarda la conoscenza o l'esperienza, ed è quindi qualcosa che qualcuno che vuole scrivere buoni programmi imparerà prima di allora.

La mancanza di esperienza è qualcosa su quali accordi sulla compensazione possono essere fatti durante l'assunzione. Incuria, complessi geniali, mancanza di pensiero logico, ecc. Sono fuori dal campo di applicazione.

Per negazione: se il codice utilizza tutti gli idiomi e le librerie corretti, ma non è possibile eliminarlo facilmente, almeno chiedi al ragazzo perché il suo codice è così difficile da capire prima dell'assunzione.

Per qualsiasi codice open source, specialmente se è disponibile su Github, puoi clonare il repository ed eseguire metric_fu su di esso. Confronta i punteggi con un pezzo di codice che hai scritto che pensi sia buono.

In secondo luogo, cerca le solite pratiche:

• Controller magro, modello grasso
  • Ancora meglio è se lo sviluppatore non aderisce rigorosamente a un controller su un'architettura di modello
  • Ancora meglio se lo sviluppatore scoppia parti della logica aziendale fuori dal modello
• Buona copertura di test del modello e del controller
• Buon approccio alla gestione delle chiamate Ajax
• Buon approccio ai problemi che non sono CRUD

L'esecuzione di metric_fu ti aiuterà a segnalare eventuali bandiere rosse.

Metric_fu is a set of metric tools that make it easy to generate metrics reports. See the list of metrics the gem includes It's designed to integrate easily with CruiseControl.rb by placing files in the Custom Build Artifacts folder...