Metodo doloroso Stupido Nomi in codice legacy: Risolto o lasciato come avvertimento? [duplicare]

È utile come segnale di pericolo? Non proprio. Semplicemente confonderà le persone e sarà difficile da ricordare.

Una funzione ben denominata che dice a qualcuno che non sa cosa sia effettivamente il codice peloso in realtà è molto utile. Il codice cattivo o confuso, che implicitamente è nella funzione, può essere orribile per risolvere il problema. Se lo hai fatto e puoi dare una buona descrizione della funzione nel nome, hai reso il lavoro del programmatore successivo molto più semplice.

Anche commentare ciò che fa è utile, ma i commenti non vengono sempre letti, ma il nome della funzione è.

Le finestre rotte dovrebbero sempre essere corrette. Non fissare il nome lascerà una finestra rotta e incoraggerà il programmatore successivo a non iniziare il re-factoring.

• Grep l'intero codice base per il nome del metodo. Scopri come è pubblico, quante configurazioni lo menzionano, ecc.

• Rinomina il metodo senza pietà (un buon IDE può farlo), grep di nuovo, aggiorna manualmente tutti i riferimenti che l'IDE ha mancato. Aggiungi un commento che spieghi le peculiarità del metodo, se ce ne sono.

• Se il metodo non è pubblico (ha solo visibilità del pacchetto o più ristretto), hai finito!

• Se il metodo è in qualche modo pubblico (esposto a terze parti o ha solo visibilità pubblica senza una ragione apparente), crea un metodo con il vecchio nome che chiama il metodo appena rinominato e logs il fatto. In questo modo scoprirai quali sono gli altri client di questo metodo. Se questi sono sotto il tuo controllo, alla fine fagli usare il nuovo nome.

• Esegui test. Se non hai un test per quel metodo, o per alcuni dei suoi clienti, è un buon momento per aggiungerli.

Rifattalo, ma crea prima un hardprint. Inquadralo. E mettilo su una sala della fama di vergogna.

Come mi avvicinerei a questo:

Se in qualche momento il refactoring si verificherà, lo lascerei come con un commento.

Se viene chiamato solo in alcuni punti e ha una buona copertura di prova, lo cambierei.

Se nessuna di queste situazioni si applica ma ti tiene sveglio la notte, lo cambierei.

Altrimenti, passa a qualcosa di più importante.

Probabilmente lo aggiusterò, specialmente se avessi del lavoro da fare in quell'area ... Non c'è bisogno di lasciare il codice cattivo in giro. Esempi di nomi validi sono esempi di brutti nomi.

Tuttavia, alcune cose che potrebbero influenzare questa decisione sono se posso testarlo per conseguenze indesiderate. Soprattutto se è pubblico e da un'interfaccia in codice legacy.

Mi sono imbattuto in questo oggi, in effetti, in un metodo pubblico e in un'interfaccia, che non sembrava essere referenziato da nessuna parte, finché non ho eseguito l'applicazione e scoperto un framework legacy nella nostra app che è configurata con i nomi dei metodi in XML usato.

Se non potessi confermare che le cose funzionassero ancora correttamente dopo il cambiamento, probabilmente lo avrei lasciato fermentare.

Lo aggiusterei. La domanda inferisce Java, ma io codifico in C # per vivere e possiedo una copia di ReSharper, e quindi cambiare il nome di un membro di codice, da un campo privato fino alla radice dello spazio dei nomi, è piuttosto semplice; destra-click- > Refactor- > Rinomina. Quindi, lo faccio, perché è davvero così semplice (il 99% delle volte, se sto lavorando in librerie condivise tra codebase distinte, potrei essere più cauto poiché un bel po 'del nostro codice legacy non ha build automatizzata in TeamCity).

Non so che tipo di strumenti lungo queste linee siano disponibili per Eclipse, ma JetBrains scrive anche IntelliJ IDEA che ha molti di questi tipi di operazioni di refact incorporate direttamente dentro.