O que impede os desenvolvedores de usar ferramentas automatizadas de refatoração? [fechadas]

Question

O que impede os desenvolvedores de usar ferramentas automatizadas de refatoração? [fechadas]

#1 resposta do (8 votos)
#2 resposta do (1 votos)
#3 resposta do (0 votos)
#4 resposta do (0 votos)
#5 resposta do (0 votos)
#6 resposta do (-2 votos)

5

Eu estava tendo uma discussão com meus colegas sobre o uso das ferramentas automatizadas de refatoração em IDEs (Eclipse, NetBeans, IntelliJ, Xcode, Visual Studio etc.) e fiquei surpreso com o fato de muitos deles se sentirem desconfortáveis tais ferramentas. Um deles é um desenvolvedor experiente (Smalltalk, C / C ++, Java, Javascript) há 20 anos e ele raramente usa um IDE e mesmo quando o faz, ele não usa as ferramentas de refatoração automatizadas. Ele faz muitas refatorações, mas as faz all manualmente.

Pessoalmente, confio muito em ferramentas de refatoração. Sempre que trabalho em um projeto, tento escolher um IDE que suporte refatorações automatizadas e use essas refatorações sempre que possível.

Estou interessado em descobrir se os desenvolvedores profissionais do Stack Exchange usam ferramentas automatizadas de refatoração. E se você não, por que não?

Para começar, aqui estão algumas razões pelas quais meus colegas não usam as ferramentas de refatoração automatizadas:

Trust - Às vezes eles não confiam no que a ferramenta está fazendo, especialmente se for uma refatoração complexa como o Pull-Up, que pode afetar vários arquivos; eles estão preocupados que a ferramenta possa introduzir bugs sutis.
Descoberta - Às vezes eles nem percebem que essa refatoração está disponível no IDE porque não é imediatamente óbvia
Flexibilidade - Às vezes, a ferramenta é muito rígida e eles sempre acham que precisam configurá-la demais para que ela funcione da maneira que desejam.

Atualizado - resumo

Com base nas respostas até agora, acho que posso resumir três coisas:

Os desenvolvedores não têm tempo para experimentar todas as diferentes refatorações disponíveis. E porque eles não podem experimentá-los, eles estão desconfiados do que farão com o código (todos os casos de canto). Essa suspeita é garantida pelo código de produção sob pressão de tempo (mesmo se você tiver testes para verificar). Talvez ferramentas de interface do usuário melhores possam aliviar isso.
Os desenvolvedores também ficaram frustrados com as limitações das ferramentas de refatoração, especialmente quando usam metaprogramação / reflexão ou possuem arquivos externos (xml, configuração, propriedades). As ferramentas automatizadas de refatoração continuam melhorando, mas sempre haverá limitações. Às vezes as limitações são aceitáveis e outras vezes não são. Eu falei com vários outros colegas e alguns deles são mais tolerantes com as limitações. Por exemplo, se renomear a refatoração não renomeia todos os arquivos, mas faz um bom trabalho ao renomear 90% deles, eles ainda estão felizes em usar a ferramenta e corrigir os 10% restantes à mão porque ainda salva < tempo e esforço.

[Na minha opinião, pelo que eu juntei], os desenvolvedores acham que as ferramentas de refatoração são recursos agradáveis , portanto, se não funcionar na primeira vez (ou algo inaceitável), eles parecem estar mais inclinados a abandoná-los e fazer mudanças à mão. Compare isso com outras ferramentas como compiladores / depuradores que também têm limitações e bugs . Os desenvolvedores provavelmente ficarão com eles, apesar de suas limitações, porque são recursos essenciais que você não pode abandonar em seu fluxo de trabalho.

Obrigado por todas as respostas. Se este tópico for de interesse para mais pessoas, sugiro transformá-lo em um Wiki da Comunidade.

Seria interessante descobrir se o tamanho do projeto, a disponibilidade de testes e a maturidade do IDE afetam a decisão das pessoas de usar ferramentas automatizadas de refatoração.

refactoring agile eclipse

por vazexqi 20.04.2011 / 00:48
fonte

6 respostas

1

Eles são limitados no que podem fazer e, muitas vezes, os resultados são menos que satisfatórios. Além disso, muitas vezes eles cobrem casos de canto tão obscuros que não são muito úteis para a maioria dos usuários.

No IntelliJ, eu uso parte das ferramentas de refatoração regularmente (renomear, alterar lista de parâmetros, extrair método, etc.), enquanto outras nunca uso. Fazer estática ??? Eu tento evitar estática como a peste. Alterar construtor para fábrica ??? Nunca precisei disso.

No Eclipse, eu raramente uso qualquer um deles porque eles são IMO muito desajeitados (mas quanto mais eu uso o IntelliJ, mais eu odeio o Eclipse como um todo, então isso pode não ser muito surpreendente).

Para abordar diretamente seus pontos: 1) Confiança. De fato, isso pode ser um problema. Eu não usaria essas ferramentas em uma base de código sem saber o que elas fazem para que eu possa prever os resultados um pouco antes. À medida que a base de código fica maior, fica mais difícil de fazer (e a probabilidade de a ferramenta introduzir erros enquanto o trabalho sobe, eu tive que acontecer). 2) Descoberta. Muito mesmo. Muitas vezes, eles estão ocultos em várias camadas de menus de contexto e / ou possuem nomes muito obscuros. 3) Flexibilidade. Mais frequentemente do que ser inflexível demais, eles são muito flexíveis para serem fáceis de usar. Combinado com documentação freqüentemente pobre que pode deixar você adivinhando o que você está fazendo, não é uma coisa boa quando se trabalha sob pressão de tempo (e quem não está constantemente trabalhando sob pressão de tempo?).

Então, você gostaria de ter tempo para experimentar as ferramentas antes de empregá-las no código de produção, mas a maioria das pessoas (certamente as pessoas mais experientes em uma empresa) raramente tem tempo para essa experimentação, pois já estão trabalhando mais do que em tempo integral no código de produção.


por 20.04.2011 / 08:45
fonte

8

As ferramentas de refatoração, como em qualquer ferramenta, têm limitações.

Limitações nos ambientes que eles executam.

Fale sobre uma ferramenta de refatoração de linha de comando.

Limitações no tipo de código que pode refatorar.

O código de metaprogramação geralmente não pode ser executado por meio de ferramentas de refatoração.

Limitações na quantidade de suporte para idiomas diferentes

A qualidade da refatoração para Perl e Python há alguns anos não era boa. Eu não sei agora.

Também descobri as poucas coisas que posso fazer com ferramentas de refatoração automáticas, posso fazer melhor com macros em linha do emacs. Essa é apenas a minha experiência.


por 20.04.2011 / 01:19
fonte

0

Acho que essa é uma pergunta interessante porque o IDE continua adicionando novos recursos sem obter feedback suficiente de seus usuários. Essa pergunta é uma boa maneira de fornecer algum feedback dos programadores. A seguir, minha experiência pessoal com ferramentas de refatoração:

Eu uso a maioria das ferramentas de refatoração do Eclipse, mas não todas, porque não sei exatamente como elas funcionam e quais são os requisitos delas no código a ser refatorado.


por 20.04.2011 / 02:21
fonte

0

Eu posso responder isso porque eu sou o cara que você está falando. Aqui está a coisa. A refatoração é feita para produzir código de maior qualidade. Para fazer isso corretamente, é preciso pensar um pouco. No entanto, as ferramentas de refatoração tornam extremamente fácil fazer algo. Então o que acontece? As pessoas refatoram sem pensar, deixando o código que é pior do que o que estava lá para começar. Mas você nunca vai convencer o especialista em ferramentas de refatoração. Porque a refatoração é boa - todo mundo sabe disso - e o assistente do IDE de fato refatorou (o eclipse disse isso). Isso não quer dizer que as ferramentas de refatoração são ruins em si, mas recebem um nome ruim por causa do tipo de programador que tende a gostar delas.


por 20.04.2011 / 05:11
fonte

0

Problemas potenciais de refatoração com o MS VisualStudio (2005, 2008, 2010)

Nota: Para tornar-se mais construtivo, reinterpretei sua pergunta como " Onde devo estar ciente de possíveis problemas ao usar o Refractoringtools "

Se você estiver usando algum tipo de reflexão, a Renomeação de Propriedades / Métodos pode se tornar um pesadelo, pois a Renomeação pode não se refletir em configuration / xml / gui-Files.

Infelizmente, este Issuse ocorre apenas em tempo de execução, não em tempo de compilação.

Este problema acontece com

wpf / mvvm em que os arquivos xml / xaml / gui possuem referências a propertynames

fluxos de trabalho nos quais os arquivos xml / xaml têm referências a nomes de propriedade que controlam o fluxo de trabalho.

Desde que não haja programação baseada em reflexos (por exemplo, WinForms) Renomear com VS (ou até mesmo VsExpress) funciona como um charme porque obedece ao Escopo Identificador em vários subprojetos, o que não é o caso de localizar e substituir simples. / p>

por 20.04.2011 / 10:10
fonte

-2

Eu uso um IDE para refatorar o código. Ele faz um trabalho decente, mas erra às vezes. Eu também faço toda a pesquisa e substituição de regex de base de código, e muitas vezes eu também entendo errado. Eu uso meu software de controle de revisão (ou diff) para mostrar o que mudou na base de código. Acontece com freqüência eu verifico diffs agora sempre que eu deixo minha IDE fazer a refatoração.


por 08.01.2016 / 23:56
fonte

Tags refactoring agile eclipse

Como e quando usar o teste UNIT corretamente O que podemos aprender das linguagens esotéricas? [fechadas]

score 1 · Accepted Answer

Eles são limitados no que podem fazer e, muitas vezes, os resultados são menos que satisfatórios. Além disso, muitas vezes eles cobrem casos de canto tão obscuros que não são muito úteis para a maioria dos usuários.

No IntelliJ, eu uso parte das ferramentas de refatoração regularmente (renomear, alterar lista de parâmetros, extrair método, etc.), enquanto outras nunca uso. Fazer estática ??? Eu tento evitar estática como a peste. Alterar construtor para fábrica ??? Nunca precisei disso.

No Eclipse, eu raramente uso qualquer um deles porque eles são IMO muito desajeitados (mas quanto mais eu uso o IntelliJ, mais eu odeio o Eclipse como um todo, então isso pode não ser muito surpreendente).

Para abordar diretamente seus pontos: 1) Confiança. De fato, isso pode ser um problema. Eu não usaria essas ferramentas em uma base de código sem saber o que elas fazem para que eu possa prever os resultados um pouco antes. À medida que a base de código fica maior, fica mais difícil de fazer (e a probabilidade de a ferramenta introduzir erros enquanto o trabalho sobe, eu tive que acontecer). 2) Descoberta. Muito mesmo. Muitas vezes, eles estão ocultos em várias camadas de menus de contexto e / ou possuem nomes muito obscuros. 3) Flexibilidade. Mais frequentemente do que ser inflexível demais, eles são muito flexíveis para serem fáceis de usar. Combinado com documentação freqüentemente pobre que pode deixar você adivinhando o que você está fazendo, não é uma coisa boa quando se trabalha sob pressão de tempo (e quem não está constantemente trabalhando sob pressão de tempo?).

Então, você gostaria de ter tempo para experimentar as ferramentas antes de empregá-las no código de produção, mas a maioria das pessoas (certamente as pessoas mais experientes em uma empresa) raramente tem tempo para essa experimentação, pois já estão trabalhando mais do que em tempo integral no código de produção.