Come si spiega il refactoring a una persona non tecnica?


52

Come si fa a spiegare il refactoring (e il debito tecnico) a una persona non tecnica (in genere un PHB o un cliente)? ("Cosa, mi costerà un mese di lavoro senza alcuna differenza visibile ?!")

AGGIORNAMENTO Grazie per tutte le risposte finora, penso che questo elenco fornirà diverse analogie utili a cui possiamo indicare le persone appropriate (anche se la modifica dei riferimenti ai PHB potrebbe essere saggia!)


Non ricordo come Apple abbia convinto così tante persone a passare da Leopard a Snow Leopard. Probabilmente il prezzo: $ 100 in meno del solito al momento.
mouviciel,

Questa domanda potrebbe fornire alcune risposte sorprendentemente utili a chiunque lavori con il codice nell'industria. Prestare attenzione alle persone.
joshin4colours,

perché sarebbe saggio?
Louis Rhys,

Risposte:


53

Quando hai un grande home theater e aggiungi delle cose, lentamente ma sicuramente un grande ratto si forma nella parte posteriore.

Se spesso sostituisci parti, a volte vale la pena raddrizzare tutta quella roba.

Certo, se lo fai, funzionava prima, e non funzionerà meglio di quando hai iniziato, ma quando dovrai farlo di nuovo, le cose saranno molto più facili.

In ogni caso, probabilmente è meglio fare un paragone simile con un'area tematica che il PHB o il cliente ha già familiarità, ad esempio auto o costruzione o qualcosa del genere ...


1
Non la migliore analogia perché la fa sembrare roba cattiva che striscia spontaneamente nel tuo teatro, al contrario delle cose cattive che appaiono come un risultato diretto della costruzione continua del tuo teatro.
doppelgreener,

21
@Axidos: "rats nest" è un idioma inglese che significa "un apparentemente impossibile da aggrovigliare" (in questo caso, di cavi e cavi dietro il centro di intrattenimento)
HedgeMage

8
Concettualmente è abbastanza buono - ha bisogno di "cavi" dopo "nido di ratti"
Murph,

2
@Peter: Penso che tutti abbiamo dovuto andare dietro la TV almeno una volta però. Spiegalo come cento volte peggio e gira un filo di cavi dappertutto e tiralo e tiralo e scopri una civiltà morta da qualche parte nel caos.
doppelgreener,

3
Se qualcuno non riesce a relazionarsi, mostragli questo: google.com/images?q=do+not+touch+any+of+these+wires
Steve S

41

Il re-factoring è proprio come il processo di reimballaggio di una valigia fino a quando tutto si adatta perfettamente. A volte, nel processo, ti chiedi perché stavi cercando di ottenere così tanta spazzatura per cominciare.


1
Avevo intenzione di pubblicare qualche analogia con un garage o un capannone, ma questo è meglio.
Matt Ellen,

O a volte vai a comprare qualche altra valigia e ti rendi conto che pagare le spese in sovrappeso non è un grosso problema, dal momento che i costi del software non sono uguali a quelli del mondo fisico. Quindi puoi davvero inserire tutto perfettamente e il vincolo di una singola valigia si è rivelato arbitrario e assurdo.
Dan Rosenstark,

+1 Questo è fantastico. Oltre a fare in modo che le cose occupino meno spazio, ci sono cose che ti rendi conto di non aver nemmeno bisogno e che quindi possono tralasciare.
Robbie Dee,

21

Non spiegherei il concetto di debito tecnico, perché non è necessario. Concentrati invece sul refactoring: stai cambiando il design del tuo programma, non necessariamente in modo che sia "migliore" o "migliorato", lo stai cambiando in modo che possa accettare un cambiamento che devi apportare.

Un'analogia con un'auto potrebbe adattarsi: è necessario aggiungere un condizionatore d'aria a un'auto, ma non è stato originariamente progettato per uno. Non solo devi creare uno strano condizionatore a forma di L, ma devi anche spostare prima altre cose e cambiare il sistema di ventilazione.

Penso anche che sia una strategia migliore per il refactoring quando si stanno adattando nuove funzionalità: altrimenti si potrebbe cambiare il design in qualcosa che sembra solo "migliore", ma che in realtà potrebbe non essere adatto alle circostanze che circondano l'aggiunta della prossima funzione.


Spostare le parti in un'auto per offrire prestazioni migliori o una manutenzione più semplice: funziona per chiunque abbia sollevato il coperchio della propria auto, ma quanti PHB lo hanno fatto?
Peter Boughton,

3
Mi piace questo perché sottolinea che il refactoring è in corso per rendere più facile (o possibile) una modifica richiesta. Il refactoring di solito non dovrebbe essere fatto per se stesso, ma per raggiungere un obiettivo specifico.
Kristopher Johnson,

Quindi, la risposta breve diventa: non dirglielo! Basta considerare il tempo in nuove funzionalità e refactor di conseguenza.
Jonathan van de Veen,

12

Uso il termine debito tecnico e lo metto direttamente in relazione con qualcosa che comprendono: il debito aziendale. Il debito tecnico è come contrarre un prestito. Paghi gli interessi su di esso. Ad esempio, puoi costruire una nuova fabbrica e pagarla per intero o puoi ottenere un prestito per questo. Se ricevi un prestito, in realtà ne pagherai di più a lungo termine, ma ha senso finanziariamente se i termini sono corretti .

Tuttavia, se stai pagando il 25% di interesse su tale prestito, ti metti in una posizione non sostenibile. Questo è lo stesso con il debito tecnico. A volte ha senso assumersi qualche debito tecnico. Tuttavia, arriva un punto in cui l'interesse è troppo elevato e deve essere ripagato. Alcuni debiti tecnici sono come un mutuo per la casa e altri come un debito con carta di credito. In caso di emergenza il debito con carta di credito è un bene importante e prezioso. Tuttavia, può anche rompere la banca (o la famiglia se si sceglie) se utilizzato in modo non corretto.

Un altro esempio: puoi pagare $ 10.000 per un drop di mail di marketing per guadagnare più lead per le vendite in futuro. Stai pagando "debito di vendita". Questa è una spesa con payoff a lungo termine. Paragonalo al motivo per cui vorresti "spendere" denaro ora refactoring di un pezzo di codice. In entrambi i casi non vi è alcun profitto immediato, ma ti stai preparando per prestazioni migliori in futuro.

Tendo a usare il termine "debito xxxx" come analogia quando parlo con chiunque sia il pubblico target. Ad esempio, debito operativo - La macchina da stampa che abbiamo ora funziona bene, ma interrompendo la produzione per un giorno (o una settimana) e aggiornando a una nuova macchina possiamo aumentare la produzione del 25%.

EDIT - Ecco un'altra opinione su questo


1
+1 per una risposta ben motivata che dimostra un'economia realistica. Il debito è a volte razionale e i puristi mancano troppe opportunità se non possono tollerarlo.
Macneil,

1
E la gente capisce che stipulare prestiti per pagare gli interessi sui prestiti più vecchi non è sostenibile.
Christopher Mahan,

1
Questa è la mia preferenza per la spiegazione, perché mi piace fare riferimento alla demolizione di tutto e alla riscrittura (che spesso è l'unica opzione rimasta a causa di così tanto debito tecnico) come il fallimento tecnico
Wayne Molina,

4
Questa è una risposta terribile. (1) Questo è più complicato della spiegazione tecnica del refactoring. (2) Questo non spiega il "perché" del refactoring; spiega i "quando" del refactoring (ovvero: quando è conveniente). O forse non capisco davvero questo post, e quindi il punto (1).
Thomas Eding,

2
@ThomasEding (1) Questa non è una spiegazione del refactoring, è una spiegazione del debito tecnico. (2) Questo spiega il perché di quando refactoring - a un uomo d'affari. Onestamente, a loro non importa della ragione tecnica, vero. Vogliono un motivo giustificabile per cui stai lavorando a qualcosa di diverso dalla prossima funzione che guiderà le vendite. Questo è il motivo per cui la maggior parte dei programmatori non può parlare con il proprio capo e lamentarsi che il capo sia stupido. Non sono stupidi, hanno solo driver diversi da te.
Nemi,

8

Pulizie di primavera.

Non stai apportando modifiche alla casa. Stai solo spostando le cose in giro e liberandoti di un po 'di polvere. Magari buttando via alcune cose che non usi più o che non ti servono più. ma non stai aggiungendo nulla.


1
+1: Questa è la migliore risposta imo: e praticamente chiunque può relazionarsi. "Vivi a casa tua, le cose si sporcano / polverano / modestamente - periodicamente devi fare una pulizia profonda."
Steven Evers,

7

"Hai mai giocato a Mouse Trap ? Mentre inseriamo nuove funzionalità, cambiamo le interfacce e correggiamo i bug, il codice può iniziare ad assomigliare molto a questo. Arriva un punto in cui dobbiamo spendere molto capitale (tempo e fatica) , il che equivale a denaro) assicurandoci che tutte le parti mobili giochino bene con ogni nuova modifica o aggiunta, oppure possiamo invece dedicare del tempo per riformattare il progetto, con conseguente riduzione delle parti mobili che dobbiamo gestire ogni volta che effettuiamo una modifica. può sembrare , dal punto di vista dell'utente finale, che il refactor non abbia alcun vantaggio, ma il vantaggio si verifica ogni volta che una nuova funzionalità viene aggiunta dopo il refactoring. Il processo è più veloce, introduce meno bug ed è successivamente economico, per non parlare del fatto che il codice refactored è spesso complessivamente più efficiente.

Potresti chiederti perché abbiamo lasciato che iniziasse a sembrare Mouse Trap in primo luogo:

  • A volte fare qualcosa in questo momento significa che dobbiamo sacrificare l'eleganza e l'efficienza per "farlo funzionare".
  • Le funzionalità linguistiche e le altre tecnologie disponibili a noi come programmatori cambiano spesso. A volte nuove funzionalità ci consentono di sostituire un miscuglio fine di sei parti mobili con una.
  • Spesso, quando aggiungiamo la funzione C alle funzioni A e B, non sappiamo che alla fine B verrà eliminato e D aggiunto. Un modo per ottenere C può funzionare molto bene con B, ma non molto bene con D.

Nel tentativo di continuare a costruire una trappola per topi migliore, dobbiamo costantemente tornare indietro e trovare luoghi per ridurre la complessità e semplificare ciò che abbiamo. È la differenza tra avere semplicemente un software con molte funzionalità e avere un software di alta qualità ".


6

testo alternativo

Questa è una versione leggermente più grafica dell'analogia dell'home theater.

Se vuoi aggiungere un altro nuovo dispositivo [aka, nuova funzionalità], con un pizzico puoi probabilmente inserirlo in qualche luogo.

Se vuoi aggiungere un altro apparecchio, puoi acquistare un cavo di prolunga, che ti farà guadagnare un po 'di tempo.

Ma ad ogni aggiunta, diventa più difficile trovare una soluzione. E ti stai esponendo a un rischio 1 di incendio [aka bug], e dovrai tirare fuori i grossi soldi per pagare qualcuno per mettere nuove prese nel muro, il che potrebbe molto probabilmente aumentare fino al principale circuito, o anche di più.

1 Un'altra cosa che i PHB non si lamentano molto bene: "Beh, se solo potesse succedere, di cosa ti preoccupi?"


5

Refactoring - è come organizzare il tuo armadio per vestiti / Cassetto degli attrezzi.

  • Non buttare via i vestiti / gli strumenti solo perché sono ovunque.

  • Si potrebbe sostenere che non dovrebbero mai essere disorganizzati. Ma lo fanno.

Proprio come fa il codice. Soprattutto quando cresce nel tempo.

E se non lo pulisci, continuerai a chiederti cosa è successo a quella maglietta che amavi o a quella chiave che ti serve sempre ma che non riesci mai a trovare!


4

Direi "manutenzione del codice" . È importante usare parole che la persona non tecnica ha familiarità e che hanno senso per una visione del mondo non tecnica. Se una persona non tecnica (cliente) ha familiarità con la manutenzione dell'applicazione, è facile fare parallelo alla manutenzione del codice e alla manutenzione dell'applicazione. Anche se non sono gli stessi, puoi spiegare che i clienti finali qui sono sviluppatori o coloro che gestiscono il sistema.


1
Le persone non tecniche hanno familiarità con la manutenzione dell'applicazione? Ho chiesto a mia nonna: non è ans è la persona più non tecnica che ho trovato. Inoltre: poiché una persona non tecnica non conosce la differenza tra codice e applicazione ("Se il codice è l'applicazione, l'applicazione è codice") la tua analogia non funzionerà.
Martin,

2
nei luoghi in cui ho lavorato, i tipi di marketing e projman hanno inteso che "manutenzione" significa "correzioni di errori dopo il rilascio", e sarebbe disonesto affermare che il refactoring sta risolvendo i bug.

Per me la persona non tecnica è il cliente. Se il cliente sa quale sia la manutenzione dell'applicazione, deve anche comprendere la manutenzione del codice.
Amir Rezaei,

La "manutenzione del codice" suona come se il tuo codice fosse soggetto a usura o si esaurisse. Un'auto deve essere mantenuta, perché l'uso normale stressa i suoi componenti, consuma fluidi, ecc. Un'applicazione non è così - il codice che si trova su un disco rigido non "invecchia" o "va male" da solo.
Dan Ray,

Ti fornirò alcuni esempi di manutenzione: problemi di prestazioni. Il componente, l'intero sistema o l'applicazione è scritto in VB e Microsoft smette di supportarlo. Il sistema operativo non supporta la tecnologia su cui si basa il codice. Problemi di sicurezza. La manutenzione su questi problemi non aggiunge alcuna nuova funzionalità che l'utente finale potrebbe notare, tuttavia sono fondamentali per mantenere viva l'applicazione.
Amir Rezaei,

4

Supponiamo che tu sia un meccanico specializzato nella personalizzazione di automobili, anche costruendole da zero se il cliente lo richiede. C'è questo cliente che torna di tanto in tanto nel tuo negozio per mettere sempre qualcosa di nuovo lucido nella sua limousine di grandi dimensioni.

Una volta arrivato, ha installato un bel sistema audio. Si esegue diligentemente l'attività passando i fili e collegando tutto correttamente. Esce il giorno dopo, è felice e paga profumatamente, come al solito.

Il mese successivo ritorna, ma questa volta vuole installare un home theater in piena regola. Ancora una volta, prendi la limousine. Essendo un professionista rivisiti il ​​sistema audio e ne semplifichi la manutenzione installando un sistema di tubi per far passare i cavi intorno all'auto. In questo modo i fili sono protetti e più facili da estrarre e, se è necessario aggiungerne altri, sarà anche facile da eseguire. Quindi strappate i vecchi fili, installate i tubi e passate il sistema audio e i fili extra per il cinema, chiudete tutto e il gioco è fatto.

Rendendoti conto che il cliente non ti ha chiesto di sostituire il vecchio sistema audio, gratta via un po 'del costo delle sostituzioni e dei tubi. Comunque guadagni ancora dall'affare, non tanto quanto avresti avuto se avessi appena lanciato il sistema come hai fatto la prima volta.

Un mese dopo torna, questa volta vuole un sistema di illuminazione e vuole che i nuovi altoparlanti abbiano danneggiato quelli vecchi all'inizio della settimana.

Poiché hai mantenuto tutto in ordine e pulito, puoi far passare rapidamente i nuovi cavi di illuminazione attraverso il tubo, installare il sistema e sostituire l'altoparlante. Questa volta, tuttavia, hai terminato molto più velocemente, il re-factoring ti ha ripagato mantenendoti in cima al tuo gioco.

Il tuo concorrente che stava ridendo di te per aver strappato cavi perfettamente buoni e installato tutti questi tubi extra sta ancora lottando per soddisfare i suoi clienti. Certo, è stato fatto più velocemente di te la maggior parte delle volte, ma col passare del tempo i suoi clienti si lamentano del fatto che ci sono sempre più ritardi e la qualità generale del lavoro è degradante.

Guardando questo, ti rendi conto che il tuo obiettivo non solo di rimanere nel business, ma di essere il migliore è bilanciare ciò che fai per soddisfare le esigenze del cliente e ciò che fai per semplificarti la vita lungo la strada. Molto raramente un cliente paga per entrambi, quindi devi gestirlo da vicino. Scommetti che facendo le cose proattivamente nel modo giusto anche a costo di fare le cose due volte manterrai i costi di manutenzione ad una percentuale controllata e stabile della tua produttività.

Il software è lo stesso, tranne per il fatto che i programmatori possono giocare con il nastro isolante digitale per MOLTO tempo prima che gli effetti e le sensazioni di clienti e manager siano realmente percepiti. Sfortunatamente a quel punto il costo di rifare le cose giuste cresce esponenzialmente rispetto alla quantità di nastro isolante presente e all'età media di detto nastro isolante.

Questo è il motivo per cui è importante continuare a ricodificare il sistema. Molto spesso l'esperienza ci mostrerà un nuovo modo più efficiente di fare la stessa cosa o potremo combinare funzionalità simili e sfruttare ridondanze invece di copiarle. Questo è il modo in cui manteniamo il sistema snello e cattivo. Il tempo mostrerà che il costante re-factoring del sistema per soddisfare le richieste manterrà costante la produttività controllando la quantità messa in manutenzione.

Il posizionamento del nastro adesivo aumenterà momentaneamente la produttività a costo di trasportare un sistema non ottimale. Il debito tecnico si manifesta ogni volta che viene favorita la produttività immediata a scapito degli altri aspetti di un sistema. L'analogia del debito è buona perché proprio come gli interessi sul capitale preso in prestito mangiano via i profitti il ​​tempo preso in prestito rendendo le cose rapidamente comporta una maggiore manutenzione e aumenta la fragilità del sistema costringendo una squadra a spendere risorse aggiuntive per mantenere piuttosto che creare. Proprio come il suo parente finanziario, se l'indebitamento continua senza sosta, la maggior parte delle risorse viene impiegata per il rimborso degli interessi lasciando pochissimi miglioramenti. Il debito tecnico divorerà le risorse tecniche fino al punto in cui la maggior parte delle risorse viene spesa semplicemente mantenendo il sistema in esecuzione per fermare tutti gli altri possibili miglioramenti.

Quindi alla fine la domanda non è che dovremmo o non dovremmo farlo, ma è etico lasciare che manager e clienti credano di poter fare affidamento su cifre di produttività artificialmente gonfiate con l'uso del nastro adesivo digitale. Alcuni penserebbero che sia una decisione commerciale, ma francamente questo è così solo perché i manager non lo capiscono. Alla fine, qualcuno dovrà pagare il debito attraverso un pesante factoring o migrando verso un nuovo sistema. In definitiva, per noi programmatori, mantenere i sistemi mantenibili, non dovresti chiedere di ricodificare in quanto parte integrante del lavoro, non riuscire a capire questo non riesce a capire in cosa consiste l'ingegneria del software. Detto questo, mi rendo conto che ci sono sistemi là fuori che hanno già contratto un debito importante e il pagamento di questo debito richiederà decisioni da parte dei pagatori. Il tuo lavoro è tale situazione è almeno fare la tua parte per smettere di prendere in prestito. Questo debito è stato sostenutoDAGLI STATI UNITI forse perché non lo sapevamo meglio, perché eravamo spinti a farlo, tuttavia, abbiamo assunto questo debito e molto spesso le persone a cui abbiamo ceduto il debito non lo capiscono, quindi non possono gestirlo correttamente.

Ecco il tuo software, tutto fatto, spero che ti piaccia .... A proposito, ho raggiunto il limite della tua carta di credito facendolo, spero non ti dispiaccia ... cya


3

Il punto del re-factoring è semplificare la progettazione e rimuovere le inefficienze. Ciò semplifica la correzione di bug e l'aggiunta di nuove funzionalità in futuro.

Il debug è due volte più difficile della scrittura del codice in primo luogo. Pertanto, se si scrive il codice nel modo più intelligente possibile, per definizione non si è abbastanza intelligenti da eseguire il debug.

Se continui ad aggiungere nuove funzionalità al codice, il re-factoring si ripagherà rapidamente. Ciò sarà visibile con un tasso di errore inferiore, un debug più rapido e correzioni più rapide.


Ma clever == 0così 2 * clever == 0...
Thomas Eding,

3

Scrivere software è molto simile a scrivere un grande libro di saggistica o un'enciclopedia.

La prima bozza fa sempre schifo. Può sempre essere migliorato riorganizzandolo, rimuovendo le sezioni che non hanno bisogno di essere lì e garantendo uno stile coerente in tutto.

Ogni volta che devi rivedere, la cosa più semplice da fare è solo aggiungere una nuova sezione, cambiare qualche parola e così via. Ma mentre le revisioni si accumulano, il libro inizia a perdere la sua organizzazione. Quindi devi fare ulteriori passaggi di riorganizzazione. In caso contrario, il libro diventa un miscuglio insensato.


3

Prendi il tuo computer desktop per esempio. Hai una torre, monitor, tastiera, mouse, stampante, scanner e altoparlanti. Alla fine tutto ciò che vuoi è una bella scrivania organizzata. Quindi basta collegare le cose alla cieca, e pochi minuti dopo, ecco, tutto è sistemato nel modo desiderato. Beh ... quasi come lo vuoi tu.

Il giorno dopo, quando si modifica il bilanciamento degli altoparlanti, si rende conto di posizionare accidentalmente gli altoparlanti sinistro e destro nelle aree sbagliate, quindi si desidera scambiare le loro posizioni. Ma oh no! C'è una giungla di corde aggrovigliate; quando si procede a spostare gli altoparlanti, il cavo del mouse viene agganciato e ora il mouse viene trascinato insieme agli altoparlanti. Inoltre, la tua tastiera ora non ha alcun gioco: in passato eri in grado di spostarla dalla scrivania in grembo.

Bene, potresti semplicemente scollegare il mouse e la tastiera e reinserirli in modo che tutto sia risolto. Ma questo non aiuterà con future riorganizzazioni e aggiunte future. Anche intrecciare i cavi del mouse e della tastiera nella giungla è una seccatura.

La soluzione migliore è ricollegare tutto per ricollegarli in un modo pulito e ordinato in cui ogni cavo non interferisce con un altro. Ora i cambiamenti futuri sono facili e continuano ad essere facili. Investi un po 'in anticipo per grandi guadagni in seguito.

Il punto chiave è che la soluzione originale ha funzionato principalmente. Questo è il refactoring: per cominciare funziona, ma è necessario cambiare il modo in cui le cose già esistono per apportare facilmente cambiamenti futuri (spostare gli altoparlanti).


2

È un po 'come pulire la casa dopo una festa selvaggia e folle della sera prima.

Diciamo che il soggiorno è stato completamente spazzato via. La casa è ancora una casa, il soggiorno è ancora un soggiorno. Funziona ma non è come potrebbe essere. Dopo aver fissato il disordine, ti rendi conto che deve essere pulito.

Quindi, inizi a insaccare la spazzatura. Sembra già meglio. Quindi, ti guardi intorno nella stanza e decidi di raddrizzare i mobili. Metti un pezzo indietro, poi il successivo e il successivo. Caspita, la stanza sembra davvero bella. Sei orgoglioso

Tua sorella entra e dice che la stanza sembra spazzatura, dovresti sistemare la libreria e aspirare il tappeto. Lei ha ragione. La stanza sembra davvero molto bella.

Ti guardi intorno e vedi che le tonalità della finestra apparirebbero molto meglio se fossero tutte alla stessa altezza. Fatto. Caspita, la stanza è fantastica.

Tratta il tuo codice allo stesso modo.


1
Mi piace, ma lo cambierei per pulire la cucina. Non cucinare per un po ', ma le cose andranno meglio dopo. I PHB potrebbero avere difficoltà a organizzare una festa durante l'orario di lavoro :)
Jaap,

Analogia discreta, ma c'è un difetto di cui i lettori dovrebbero essere consapevoli: se non pulisci la tua casa, la tua casa diventa letteralmente meno utilizzabile nel tempo. Considerando che con un programma, questo non accade.
Thomas Eding,

1

Facile!

Prendilo con un esempio ... nella vita ognuno ha scritto una lettera a una persona cara. Deve essere una persona cara perché in quelle lettere di solito prestiamo attenzione anche alla composizione.

Quindi, hai il tuo testo, ... il significato andrà in entrambi i modi, ma vuoi che l'intera cosa suoni bene! Giusto?

Refactoring, stessa cosa ... stesse informazioni, più o meno, ma la composizione è migliore. E probabilmente si tradurrà in una migliore recensione da parte del lettore.

Un altro esempio: scrivere un articolo per una rivista. Due scrittori, entrambi sanno "le loro cose", l'unica differenza è che uno sa "come scrivere" e l'altro scrive come ha imparato a scrivere da risposte come queste.

Di chi ricorderai l'articolo?


1

Tutte le analogie con le cose nel mondo fisico - come la costruzione di un teatro - sono, IMO, terribili.

Devi spiegare che il codice di refactoring è come ... codice di refactoring. Il software è malleabile come non lo sono gli analoghi fisici. Man mano che le cose diventano sempre più complesse, si deve reagire (o ripetere, come si desidera) parti grandi o piccole di una base di codice in modo da poter continuare ad aumentare la complessità senza impazzire.

Perché refattiamo? Perché il codice che non viene mai refactorizzato costa più al minuto per mantenere e cambiare, e alla fine diventa più problematico.

La cosa così interessante del refactoring è che rifare la base di codice ma, almeno all'inizio, la funzionalità rimane la stessa.


/ Tutte le analogie /? Sono fortemente in disaccordo. Devi solo essere più creativo. Inoltre, non risponde alla domanda del PO.
Thomas Eding,

@ThomasEding grazie per il tuo commento. Non sono d'accordo sul secondo punto: sto, in effetti, rispondendo alla domanda. Tuttavia, ora eseguirò una modifica solo per te.
Dan Rosenstark,

0

Il re-factoring equivale a ripulire qualcosa e dare alle cose un nuovo posto dove "stare"

Semplice semplice e qualcosa che può richiedere molte volte. A volte aggiungo che quella persona X ha lasciato un casino enorme di cose e devo ripulirlo.


0

Ho pensato a un altro esempio, che apparentemente nessuno qui ha menzionato: il refactoring è praticamente lo stesso di riorganizzare un'equazione in matematica (anche se questo potrebbe non rientrare nell'ambito di "persona non tecnica, immagino).

Quando riorganizzi un'equazione, devi semplicemente "spostare le cose in giro" per renderla più leggibile e più utilizzabile, senza cambiare il significato .


1
quindi se sono un PHB o un cliente (chi pagherà per questo sforzo di refactoring), perché dovrebbe importarmene? Il codice funziona (dal mio punto di vista)
Dan Pichelman,

0

Dai loro una semplice equazione matematica. Per esempio:

Qual è più semplice?

y = x + x

o

y = 2x

Il refactoring è un concetto simile tranne che invece di semplici equazioni matematiche, si inseriscono algoritmi. L'idea principale è che puoi scambiare due modi di fare le cose perché produrranno lo stesso risultato.

Il refactoring più semplice che si può fare è rinominare.

doX() { ... }
{
   doX()
}

Ora perché non vogliamo davvero che le cose vengano chiamate doX perché non sappiamo davvero cosa significhi, lo rinominiamo in qualcos'altro che è più autoesplicativo e lo sostituiamo ovunque lo abbiamo usato.

doBusinessTransaction() { ... }
{
   doBusinessTransaction()
}

Ciò consentirà di risparmiare denaro in seguito in caso di problemi o miglioramenti poiché riduce il tempo per le persone di comprendere e correggere l'applicazione. Per risparmiare ulteriormente, ci sono strumenti gratuiti che fanno questo lavoro per te automaticamente a seconda della lingua che stai usando. Questi strumenti sono anche concessi in licenza in modo tale da non essere restrittivi e richiederebbero di fare qualcosa di speciale oltre a riconoscerlo se lo si utilizza direttamente.


1
Mi piace molto questa analogia perché è comprensibile a tutti e molto simile al codice stesso.
Venkat D.

Grazie, l'ho anche pubblicato sul mio blog trajano.net/2013/05/refactoring-explained
Archimedes Trajano

0

Un'immagine dice più di mille parole. Ad esempio, il refactoring ha due casi d'uso:

  • Quando le cose non vengono fatte bene la prima volta:

refactoring quando le cose non vengono fatte bene la prima volta

  • Quando le cose sono noiose:

refactoring quando le cose sono noiose

Riferimenti


XKCD vale la pena ignorare il fatto che rendere più efficiente un'attività di routine può significare che finisci per fare molto di più di quanto avresti altrimenti. Quindi è necessario considerare il valore che si ottiene dalle prestazioni extra dell'attività.
bdsl

@bdsl Questo è coperto su workplace.se
Paul Sweatte,

0

Considera una risposta fornita in Refactoring e non spiegarla a una persona non tecnica. Il refactoring è un'attività tecnica che non è necessario conoscere:

Naturalmente, molte persone affermano di essere guidate dalla qualità ma più guidate dal programma. In questi casi do il mio consiglio più controverso: non dirlo!

Sovversivo? Io non la penso così. Gli sviluppatori di software sono professionisti. Il nostro compito è costruire software efficace il più rapidamente possibile. ... Un manager guidato dai programmi vuole che io faccia le cose nel modo più veloce possibile; come lo faccio sono affari miei. Il modo più veloce è di refactoring; quindi refactoring.

(Refactoring, Martin Fowler, 2000, pagina 61)

Ovviamente questo non funzionerà se hai intenzione di passare un mese senza fare altro che refactoring, ma penso che sia generalmente una cattiva idea ed è molto meglio fare semplicemente il refactoring nella misura necessaria per rendere più facile il tuo compito attuale o successivo o per ripulire il codice con cui hai appena lavorato.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.