Come si fa a decidere quali parti del codice è consolidata / riscritta dopo?

Question

Non si utilizza metriche di prendere una decisione, che parti del codice (classi, moduli, librerie) è consolidata o riscritta dopo?

Answer 1

Non faccio uso di metriche che possono essere calcolati automaticamente.

codice odori e euristica simili a rilevare codice cattivo, e poi ti risolvere il problema nel più breve tempo ho notato. Non ho alcuna lista di controllo per l'esame dei problemi - per lo più si tratta di una sensazione viscerale che "questo codice sembra disordinato" e poi ragionamento che il motivo per cui è disordinato e capire una soluzione. refactoring semplici come dare un nome più descrittivo ad una variabile o l'estrazione di un metodo di prendere solo pochi secondi. Più refactoring intensive, come ad esempio l'estrazione di una classe, potrebbe richiedere fino a un un'ora o due (nel qual caso avrei potuto lasciare un commento TODO e refactoring in un secondo momento).

Un'euristica importante che uso è Responsabilità unico principio . Rende le classi ben coeso. In alcuni casi, io uso la dimensione della classe in righe di codice come euristica per guardare più attentamente, se una classe ha molteplici responsabilità. Nel mio progetto corrente Ho notato che durante la scrittura di Java, la maggior parte delle classi saranno meno di 100 linee lungo, e spesso quando le dimensioni si avvicina a 200 linee, la classe fa molte cose non correlate ed è possibile dividerlo, in modo da ottenere le classi coese più mirate.

Answer 2

Ogni volta che ho bisogno di aggiungere nuove funzionalità che cerco per il codice già esistente che fa qualcosa di simile. Una volta che trovo tale codice penso di refactoring per risolvere sia il compito originale e quello nuovo. Di certo io non decido di refactoring ogni volta -. Più spesso mi riutilizzare il codice così com'è

Answer 3

Io in genere refactoring solo "on-demand", cioè se vedo un concreto problema immediato con il codice.

Spesso, quando ho bisogno di implementare una nuova funzionalità o correggere un bug, trovo che l'attuale struttura del codice rende questo difficile, come ad esempio:

• troppi posti di cambiare a causa di copia & incolla
• strutture di dati non adatti
• le cose hardcoded che hanno bisogno di cambiare
• metodi / classi troppo grandi per capire

Poi mi refactoring.

A volte vedo il codice che sembra problematico e che mi piacerebbe cambiare, ma resistere alla tentazione, se la zona non è attualmente in lavorazione.

Vedo refactoring come un equilibrio tra a prova di futuro il codice, e fare le cose che in realtà non generano alcun valore immediato. Perciò Io normalmente non refactoring se non vedo un bisogno concreto.

Mi piacerebbe sentir parlare di esperienze di persone che refactoring come una questione di routine. Come si fa a fermare se stessi da lucidatura così tanto si perde tempo per caratteristiche importanti?

Answer 4

Cyclomatic_complexity per identificare il codice che deve essere refactoring successiva.

Answer 5

Fonte Monitor e di routine refactoring metodi quando la metrica complessità va aboove intorno 8.0.