Ho avuto un insegnante di falegnameria da bambino che voleva che ricordassi di assicurarmi che non lasciassi un casino di vernice sui miei progetti completati. Mi diede un nome sciocco per ricordarmi di pulire la vernice prima che si asciugasse, dicendo che se la chiamava qualcosa di carino, me ne dimenticavo, ma un nome sciocco che ricorderei per sempre. Aveva ragione, e fino ad oggi associo la parola "snotters" con gocce di vernice lasciata ad asciugare e rendere un progetto di falegnameria brutto.
C'è potere nel nominare le cose. Lo sappiamo nel modo in cui a volte agonizziamo sul modo in cui dovremmo nominare le nostre classi e variabili nel codice, e come ottenere correttamente i nomi aiuta a definire il contenuto dei nostri metodi. Allo stesso modo sono sicuro che questo è il vero potere nell'usare un'analogia per descrivere un concetto tanto effimero quanto il potenziale di un problema nel codice di lavoro. Agli sviluppatori agili piace metterlo in funzione e quindi fare da refactoring per farlo funzionare meglio, tuttavia è necessario un approccio ragionevole per garantire che si proceda al refactoring per le giuste motivazioni. Poiché Yannis ha correttamente dichiarato (e io parafrasando), ciò che sembra male a una persona potrebbe non essere necessariamente considerato cattivo da un altro, e quindi il potenziale per un problema non implica logicamente l'effettiva esistenza di un problema.
Forse l'analogia non è abbastanza accurata. Forse un tocco, un suono, un gusto o un'analogia visiva sarebbero più diretti. Tuttavia il problema con l'applicazione di un'analogia non olfattiva è che è difficile trovare un buon nome breve per descrivere il codice che potrebbe finire per disturbarti in qualche modo sottile, mentre la parola odore implica una sottigliezza che altrimenti sarebbe stata trascurata se non fosse stato per un fattore che l'ha portato momentaneamente alla tua attenzione. Quello che mi piace dell'uso della parola smell è che offre un modo per descrivere che potrebbe essere necessario guardare qualcosa per ulteriori accordature, mentre non implica necessariamente che ci sia qualcosa di sbagliato ... come una buona e il formaggio blu puzzolente potrebbe avere un odore terribile ma comunque piacevole. È sottile - la frase ... forse meno il formaggio ... o questa analogia!
Forse uno dei motivi per cui code smell sembra essere trattato come una cattiva aria su Programmers.SE (sì, gioco di parole) è che molte domande tendono a chiedere "è questo un odore", eppure senza fornire un contesto sufficiente. Così finiamo con una serie di domande piuttosto inutili che assomigliano al seguente:
Q: Could it indicate a problem?
A: Maybe/Potentially.
Q: Does it indicate a problem?
A: How will we know without reading all of your code?
Forse il problema di fondo con le persone che non amano il termine "odore di codice", o forse più precisamente il motivo per cui molte persone usano impropriamente la frase, è semplicemente perché il loro viene presa da una prospettiva purista, piuttosto che pragmatica, o forse semplicemente fraintendono ciò che l'analogia di un odore di codice è in realtà destinata a rappresentare. In base alla definizione dell'odore di codice di C2-wiki sembra che il significato della frase rimanga sano e il suo utilizzo continui a essere applicabile, mentre la saggezza del mio insegnante di legno ora lamentato rimane valida, perché come Snotters , la frase Codice odore è difficile da dimenticare e probabilmente continuerà ad essere usata - e probabilmente abusata - per molto tempo a venire.