Cosa impedisce agli sviluppatori di utilizzare strumenti di refactoring automatici? [chiuso]

5

Stavo discutendo con i miei colleghi sull'uso degli strumenti di refactoring automatico negli IDE (Eclipse, NetBeans, IntelliJ, Xcode, Visual Studio, ecc.) ed ero sorpreso che molti di loro erano a disagio nell'usare tali strumenti. Uno di loro è uno sviluppatore esperto (Smalltalk, C / C ++, Java, Javascript) da 20 anni e quando usa raramente usa un IDE e anche , non usa gli strumenti di refactoring automatico. Fa molti refactoring, ma li fa all a mano.

Personalmente, mi affido molto agli strumenti di refactoring. Ogni volta che lavoro a un progetto, cerco di scegliere un IDE che supporti i refactoring automatici e utilizzi tali refactoring ogni volta che è possibile.

Sono interessato a scoprire se gli sviluppatori professionisti qui a Stack Exchange utilizzano strumenti di refactoring automatizzati. E, se non lo fai, perché no?

Per iniziare, ecco alcuni motivi per cui i miei colleghi non utilizzano gli strumenti di refactoring automatico:

  1. Fiducia - A volte non si fidano di ciò che lo strumento sta facendo, specialmente se si tratta di un refactoring complesso come Pull-Up che potrebbe influenzare più file; sono preoccupati che lo strumento possa introdurre bug sottili.

  2. Discoverability - A volte non si rendono nemmeno conto che tale refactoring è disponibile nell'IDE perché non è immediatamente ovvio

  3. Flessibilità - A volte lo strumento è troppo rigido e hanno sempre la sensazione di doverlo configurare troppo per farlo funzionare nel modo desiderato.

Aggiornato - riepilogo

Sulla base delle risposte finora, penso di poter riassumere tre cose:

  1. Gli sviluppatori non hanno il tempo di provare tutti i diversi refactoring disponibili. E poiché non possono provarli, sono sospettosi di ciò che faranno al codice (tutti i casi d'angolo). Questo sospetto è giustificato per il codice di produzione sotto pressione temporale (anche se si hanno test da verificare). Forse gli strumenti di interfaccia utente migliori possono alleggerirlo.

  2. Gli sviluppatori sono anche stati frustrati dalle limitazioni degli strumenti di refactoring, specialmente quando usano metaprogramming / reflection o hanno file esterni (xml, configuration, properties). Gli strumenti di refactoring automatico continuano a migliorare ma ci saranno sempre dei limiti. A volte le limitazioni sono accettabili e altre volte non lo sono. Ho parlato con molti altri colleghi e alcuni di loro sono più tolleranti nei confronti dei limiti. Ad esempio, se il refactoring del rename non rinomina tutti i file, ma fa un buon lavoro di ridenominazione del 90%, sono comunque felici di utilizzare lo strumento e di aggiustare il restante 10% a mano perché ancora salva tempo e impegno.

  3. [Secondo me da quello che ho raccolto], gli sviluppatori ritengono che gli strumenti di refactoring siano caratteristiche piacevoli , quindi se non funziona la prima volta (o fa qualcosa inaccettabile), sembrano essere più inclini ad abbandonarli e apportare modifiche a mano. Confronta questo con altri strumenti come compilatori / debugger che hanno anche limitazioni e bug . È probabile che gli sviluppatori continuino a seguirli nonostante i loro limiti perché sono caratteristiche essenziali di essenziale che non puoi semplicemente abbandonare nel tuo flusso di lavoro.

Grazie per tutte le risposte. Se questo argomento interessa più persone, ti suggerisco di trasformarlo in un wiki della community.

Sarebbe interessante scoprire se le dimensioni del progetto, la disponibilità dei test, la maturità dell'IDE influiscono sulla decisione delle persone di utilizzare strumenti di refactoring automatizzati.

    
posta vazexqi 20.04.2011 - 00:48
fonte

6 risposte

1

Sono limitati in ciò che possono fare, e spesso i risultati non sono soddisfacenti. Inoltre, spesso coprono casi oscuri che non sono molto utili alla maggior parte degli utenti.

In IntelliJ, uso regolarmente parte degli strumenti di refactoring (rinomina, cambia elenco parametri, estrai metodo, ecc.), mentre altri non li uso mai. Fai statico ??? Cerco di evitare statici come la peste. Cambia costruttore in fabbrica ??? Non ne ho mai avuto bisogno.

In Eclipse, uso raramente qualcuno di loro perché sono IMO troppo goffo (ma più uso IntelliJ più mi odio di Eclipse nel suo insieme, quindi potrebbe non essere troppo sorprendente).

Per indirizzare direttamente i tuoi punti: 1) Fiducia. In effetti questo può essere un problema. Non userei questi strumenti su una base di codice senza sapere cosa fanno in modo da poter prevedere in anticipo i risultati. Man mano che il codebase diventa più grande, diventa più difficile (e la probabilità che lo strumento introduca bug mentre si lavora aumenta, è successo). 2) Discoverability. Così tanto. Spesso sono nascosti in più livelli di menu contestuali e / o hanno nomi molto oscuri. 3) Flessibilità. Più spesso che essere troppo rigidi, sono troppo flessibili per essere facili da usare. Combinato con una documentazione spesso scarsa che può lasciarti indovinare su cosa stai facendo, non è una buona cosa quando si lavora sotto la pressione del tempo (e chi non lavora costantemente sotto la pressione del tempo?).

Quindi vorresti del tempo per sperimentare con gli strumenti prima di impiegarli sul codice di produzione, ma la maggior parte delle persone (sicuramente le persone più anziane di una società) raramente hanno il tempo per una simile sperimentazione che stanno già lavorando più del tempo pieno sul codice di produzione.

    
risposta data 20.04.2011 - 08:45
fonte
8

Gli strumenti di refactoring, come con qualsiasi strumento, hanno delle limitazioni.

Limitazioni negli ambienti che gestiscono.

  • Parlami di uno strumento di refactoring della riga di comando.

Limitazioni nel tipo di codice che può refactoring.

  • Il codice di metaprogrammazione spesso non può essere eseguito attraverso strumenti di refactoring.

Limitazioni nella quantità di supporto per lingue diverse

  • La qualità del refactoring per Perl e Python alcuni anni fa non era buona. Non so adesso.

Ho anche trovato le poche cose che posso fare con gli strumenti di refactoring automatico, posso fare meglio con le macro in linea di emacs. Questa è solo la mia esperienza.

    
risposta data 20.04.2011 - 01:19
fonte
0

Penso che questa sia una domanda interessante perché l'IDE continua ad aggiungere nuove funzionalità senza ottenere abbastanza feedback dai propri utenti. Tale domanda è un buon modo per fornire un po 'di fadback dai programmatori. Quanto segue è la mia esperienza personale con gli strumenti di refactoring:

Uso la maggior parte degli strumenti di refactoring di Eclipse ma non tutti, perché non so come funzionano esattamente e quali sono i requisiti per il codice da refactoring.

    
risposta data 20.04.2011 - 02:21
fonte
0

Posso rispondere perché sono il ragazzo di cui stai parlando. Ecco la cosa. Il refactoring è fatto per produrre un codice di qualità superiore. Per farlo bene richiede un bel po 'di pensiero. Tuttavia, gli strumenti di refactoring rendono estremamente facile ... fare qualcosa. Quindi cosa succede? Il refactoring delle persone senza pensieri lascia il codice che è peggio di quello che era lì per cominciare. Ma non convincerai mai il mago del refactoring. Perché il refactoring è buono - lo sanno tutti - e il wizard IDE ha fatto il refactoring (eclipse ha detto così). Questo non vuol dire che gli strumenti di refactoring sono di per sé cattivi, ma ottengono un brutto nome a causa del tipo di programmatore che tende a piacergli.

    
risposta data 20.04.2011 - 05:11
fonte
0

Potenziali problemi di refactoring con MS VisualStudio (2005, 2008, 2010)

Nota: per diventare più costruttivo reinterpreta la tua domanda come " dove devo essere a conoscenza dei potenziali propblems quando uso Refractoringtools "

Se stai usando qualche tipo di riflessione, la ridenominazione di proprietà / metodi può diventare un incubo perché la rinomina potrebbe non riflettersi in configuration / xml / gui-Files.

Purtroppo questi Issuse si verificano solo in fase di esecuzione, non in compiletime.

Questo problema si verifica con

  • wpf / mvvm dove i file xml / xaml / gui hanno riferimenti a propertyname
  • flussi di lavoro in cui i file xml / xaml hanno riferimenti a proprietàname che controllano il flusso di lavoro.

Finché non esiste una programmazione basata su riflessioni (cioè Winforms), la ridenominazione con VS (o anche VsExpress) funziona come un fascino perché obbedisce all'Identificatore dell'identificatore su diversi progetti secondari, che non è il caso con la ricerca e sostituzione semplice.

    
risposta data 20.04.2011 - 10:10
fonte
-2

Uso un IDE per il codice refactoring. Fa un lavoro decente, ma a volte si sbaglia. Faccio anche l'intero codice base regex per cercare e sostituire, e spesso mi danno anche loro torto. Uso il mio software di controllo di revisione (o diff) per mostrarmi cosa è cambiato nel codebase. Succede abbastanza spesso che controllo i diff ora ogni volta che lascio che il mio IDE faccia il refactoring.

    
risposta data 08.01.2016 - 23:56
fonte

Leggi altre domande sui tag