As linguagens dinâmicas estão em desvantagem para o desenvolvimento ágil?

12

Pelo que li, o desenvolvimento ágil geralmente envolve refatoração ou código de engenharia reversa em diagramas. É claro que há muito mais do que isso, mas se considerarmos as práticas que dependem desses dois métodos, as linguagens de tipo dinâmico estão em desvantagem?

Parece que linguagens com estática tornariam a refatoração e a engenharia reversa muito mais fáceis.

A refatoração ou a engenharia reversa (automatizada) é difícil, se não impossível, em idiomas de tipo dinâmico? O que os projetos do mundo real dizem sobre o uso de linguagens dinamicamente tipadas para a metodologia ágil?

agile dynamic-typing static-typing

— Gerenuk
fonte

5

Código de engenharia reversa em diagramas? Por que você faria isso no Agile?

— CaffGeek

7

Agile não significa "codifique primeiro, documente depois".

— Gort the Robot

@CaffGeek: Alguns livros recomendados sugerem desenhar diagramas em um quadro branco, codificar e finalmente fazer engenharia reversa em códigos para a próxima reunião.

— Gerenuk

1

Eu acho que o tipo forte deve ser removido das tags e do texto desta pergunta. A questão parece ser sobre estática vs dinâmica, não forte vs fraca.

— Winston Ewert

@WinstonEwert - Boa chamada, eu mudei as tags para dynamic-typingestatic-typing

— Carson63000 25/12/12

11

As linguagens dinâmicas estão teoricamente em desvantagem, todas as demais são iguais, porque especificam menos sobre como o código funciona (quais são as restrições) e, portanto, menos refatoração pode ser feita automaticamente, e os problemas que surgem também não podem ser detectados automaticamente. .

Mas tudo o resto não é igual. As linguagens dinâmicas mais populares permitem código altamente compacto, mas compreensível, o que geralmente torna o desenvolvimento mais rápido e facilita a localização visual da lógica (que pode mudar na refatoração). Portanto, embora você possa perder parte da vantagem relativa de trabalhar em uma linguagem dinâmica, ainda assim poderá avançar, especialmente se estiver planejando fazer a refatoração manualmente de qualquer maneira.

Por outro lado, existem linguagens estaticamente tipadas com essencialmente as mesmas vantagens que linguagens dinâmicas (ou seja, compactas e compreensíveis - com tipos principalmente inferidos, mas muito existentes): Haskell é talvez o exemplo principal, mas OCaML / F #, Scala, e outros também estão nessa categoria. Infelizmente, uma vez que são menos usados do que as linguagens de tipo estaticamente mais populares, elas não possuem um conjunto de ferramentas extensivo (por exemplo, para refatoração).

Então, como resultado, acho que você fará adequadamente com metodologias ágeis na maioria dos idiomas; Eu não diria que há um vencedor claro agora, já que a prática ainda não alcançou a teoria.

— Rex Kerr
fonte

Eu acho que essa resposta aborda os principais pontos da pergunta melhor :) Você poderia também elaborar a importância da refatoração e engenharia reversa seguras para o desenvolvimento ágil? Eu estava assumindo que desempenhou um papel muito importante? Talvez seja menos do que eu pensava e as ferramentas para a linguagem dinâmica sejam boas o suficiente.

— Gerenuk 27/09/12

1

@ Gerenuk - Eu não tenho experiência suficiente com desenvolvimento ágil (especialmente em linguagens dinâmicas) para dar uma resposta autorizada - o aspecto da refatoração é enfatizado, deixou o mesmo, etc.? Lembre-se de que outros aspectos comuns do processo - desenvolvimento orientado a testes, por exemplo - podem ajudar a identificar onde sua refatoração deu errado e, se você se esforçar um pouco mais, por exemplo, na fase de design, talvez não seja necessário refatorar tanto. Eu não acho que uma técnica específica seja a chave - é manter um conjunto completo de ferramentas à mão, implantado com frequência e de forma colaborativa.

— Rex Kerr

14

A refatoração automatizada foi inventada no Smalltalk, uma linguagem de tipo dinâmico. Portanto, não, não é impossível ter refatoração automatizada em uma linguagem de tipo dinâmico. O quão difícil é depende muito mais de outros fatores além da disciplina de digitação. C ++ e Java são de tipo estaticamente, mas as ferramentas de refatoração realmente existem apenas para Java. O Smalltalk, com sua introspecção e sintaxe simples, era realmente um bom candidato para ferramentas de refatoração.

De certa forma, a digitação dinâmica realmente facilita a refatoração. Se você possui um bom conjunto de testes, pode ter certeza de que suas refatorações não quebraram nada. Uma base de código digitada dinamicamente é geralmente menor. Além disso, as refatorações tendem a afetar menos código. No total, o esforço envolvido na refatoração manual de uma base de código dinâmica é menor que o de uma base de código estática.

— Winston Ewert
fonte

1

E a engenharia reversa, então? O Smalltalk é diferente do Python no que diz respeito à digitação? Parece um problema difícil deduzir todos os tipos em Python e, assim, determinar qual método é realmente idêntico e não apenas o mesmo nome.

— Gerenuk

2

Smalltalk não é que muito diferente do Python com relação a digitação. Ele é , no entanto, significativamente diferente com relação a ferramentas . As ferramentas e IDEs disponíveis para Smalltalk são muito melhores do que aqueles disponíveis para Python ou mesmo C #, C ++ e Java. A razão pela qual os IDEs para Python são ruins não é porque o Python é digitado dinamicamente, é porque, bem, os IDEs para Python são ruins. Não vamos esquecer que o IDE que agora conhecemos como Eclipse costumava ser chamado VisualAge for Smalltalk uma vez. A comunidade Smalltalk tem 40 anos de experiência na construção de IDEs, e eles aplicam isso ao Java.

— Jörg W Mittag

@ Gerenuk, a digitação do Smalltalk não é diferente do python. De outras maneiras, como introspecção, o Smalltalk fornece um conjunto de recursos mais amigável à refatoração. A dedução de tipos em python exigiria trabalho, mas já foi feita, consulte Projeto PyPy.

— Winston Ewert

1

@WinstonEwert ", mas você pode refatorar manualmente, e os idiomas dinâmicos tornam isso bastante fácil" - Não, a refatoração manual não é dimensionada. Ferramenta de suporte para refatoração muda tudo , mesmo quando refatoração não é 100% automático (ver os trechos de estudo de caso abaixo - programmers.stackexchange.com/a/166594/4334 )

— igouy

1

Quase todos os pontos da sua "programação dinâmica realmente facilitam a refatoração" são duvidosos ou não são seqüenciais. A programação dinâmica não significa que você tenha um conjunto de testes mais abrangente, apenas um maior (porque algumas coisas precisam de testes que seriam estatisticamente capturados). Você não oferece suporte para "refatorações tendem a afetar menos código" (como uma adição a "o projeto é menor de qualquer maneira", o que provavelmente é verdadeiro, dada a atual safra de linguagens dinâmicas). E o "esforço envolvido na refatoração manual" parece errado, a menos que você queira dizer que nem permitirá que seu compilador o ajude!

— Rex Kerr

8

A refatoração foi inventada em linguagens dinâmicas. As ferramentas automatizadas de refatoração foram inventadas em linguagens dinâmicas. Os IDEs foram inventados em linguagens dinâmicas. Várias metodologias ágeis foram inventadas em linguagens dinâmicas.

Eu realmente não vejo nenhum problema.

— Jörg W Mittag
fonte

"O Smalltalk não é muito diferente do Python no que diz respeito à digitação. No entanto, é significativamente diferente no que diz respeito às ferramentas." - Talvez isso está começando a mudar, ver jetbrains.com/pycharm/features/index.html

— igouy

3

Para não esquecermos, a maneira de trabalhar "Agile", que ficou conhecida como Extreme Programming (XP), foi criada em um projeto Smalltalk (e o Smalltalk certamente conta como uma linguagem "dinâmica").

Aqui está um estudo de caso do uso industrial de uma ferramenta de refatoração fornecida com uma linguagem de tipo dinâmico:

Uma aplicação Smalltalk muito grande foi desenvolvida na Cargill para apoiar a operação de elevadores de grãos e as atividades de comércio de mercadorias associadas. O aplicativo cliente Smalltalk possui 385 janelas e mais de 5.000 classes. Cerca de 2.000 classes neste aplicativo interagiram com uma estrutura de acesso a dados antiga (por volta de 1993). A estrutura executou dinamicamente um mapeamento dos atributos do objeto para as colunas da tabela de dados.

A análise mostrou que, embora a pesquisa dinâmica consumisse 40% do tempo de execução do cliente, era desnecessária.

Foi desenvolvida uma nova interface da camada de dados que exigia que a classe de negócios fornecesse o atributo de objeto ao mapeamento de colunas em um método explicitamente codificado. Os testes mostraram que essa interface tinha ordens de magnitude mais rápidas. A questão era como alterar os 2.100 usuários da classe executiva da camada de dados.

Um grande aplicativo em desenvolvimento não pode congelar o código enquanto uma transformação de uma interface é construída e testada. Tivemos que construir e testar as transformações em uma ramificação paralela do repositório de código do fluxo de desenvolvimento principal. Quando a transformação foi totalmente testada, foi aplicada ao fluxo de código principal em uma única operação.

Menos de 35 erros foram encontrados nas 17.100 alterações. Todos os erros foram resolvidos rapidamente em um período de três semanas.

Se as alterações fossem feitas manualmente, estimamos que seriam necessárias 8.500 horas, em comparação com 235 horas para desenvolver as regras de transformação.

A tarefa foi concluída em 3% do tempo esperado usando Regras de Reescrita. Isso é uma melhoria de um fator de 36.

de “Transformação de uma camada de dados de aplicativos” Loew-Blosser OOPSLA 2002

Também - "Ferramentas para fazer alterações impossíveis - experiências com uma ferramenta para transformar grandes programas Smalltalk"

— igouy
fonte

1

Seus princípios pensados me parecem corretos .

As linguagens fortemente tipadas, como o C #, são boas candidatas a uma base de código que precisa constantemente de re-fatoração. Basicamente, a maioria das ferramentas de re-fatoração (como Resharper, JustCode, etc.) no mercado são muito eficazes em linguagens de programação com tipos estatísticos.

O que os projetos do mundo real dizem sobre o uso de linguagens dinamicamente tipadas para a metodologia ágil?

Para a equipe de desenvolvimento que pratica a metodologia Agile / Scrum, é muito útil (mesmo crítico) ter um bom conjunto de ferramentas de refatoração sob a armadura. Caso contrário, todas as mudanças repentinas no próximo sprint podem ser um pesadelo para serem modificadas ou redesenhadas.

Assim, a metodologia ágil não oferece vantagens para linguagens estaticamente tipadas ou dinâmicas uma vez. O que ele fornece é uma abordagem iterativa para criar um aplicativo sólido.

— Yusubov
fonte

4

As linguagens dinâmicas tinham ferramentas de refatoração automatizadas muito antes do C # existir e quando o Notepad ainda era o Java IDE mais poderoso.

— Jörg W Mittag

4

Esta resposta não é totalmente suportada pela minha experiência. As linguagens dinâmicas são tipicamente mais rápidas de fazer as coisas do que as mais convencionais, de tipo estatístico (eu tenho que aprender Haskell, ML ou algo assim em algum momento). Eles também são muito mais rápidos de modificar, se forem necessários repentinamente, o que levou à minha conclusão de que o Common Lisp era a melhor linguagem quando você realmente não sabia o que estava fazendo. Além disso, onde você acha que a refatoração começou?

— David Thornley

1

por que você pensa assim, por exemplo, o javascript é uma linguagem dinâmica, mas o Re-sharper não faz o mesmo trabalho liso do C #. Em segundo lugar, eu NÃO disse que "linguagens dinâmicas são mais lentas para fazer as coisas".

— Yusubov 24/09/12

Das pessoas que trouxeram você IntelliJ IDEA - PyCharm - "A renomeação de refatoração permite realizar alterações globais de código com segurança e instantaneamente. Alterações locais em um arquivo são executadas no local. As refatorações funcionam em projetos simples de Python e Django. Use Introduce Variable / Campo / Constante e Local embutido para melhorar a estrutura do código em um método, Extrair método para dividir métodos mais longos, Extrair superclasse, Empurrar para cima, Puxar para baixo e Mover para mover os métodos e classes. " jetbrains.com/pycharm/features/index.html

— igouy

@igouy, estou me referindo ao Resharper e JustCode na minha resposta. Assim, é verdade para o contexto a que se refere.

— Yusubov 28/09/12