Le lingue dinamiche sono svantaggiate per lo sviluppo agile?

I linguaggi dinamici sono teoricamente in svantaggio, a parità di tutti gli altri, perché specificano meno come funziona il codice (quali sono i vincoli), e quindi meno del refactoring può essere fatto automaticamente, e i problemi che si presentano non possono essere rilevati automaticamente pure.

Ma tutto il resto non è uguale. I linguaggi dinamici più diffusi consentono di realizzare codice altamente compatto ma comprensibile, che in genere rende più veloce lo sviluppo in essi, e rende più semplice individuare visivamente la logica (che può cambiare nel refactoring). Quindi, anche se potresti perdere parte del vantaggio relativo di lavorare in un linguaggio dinamico, potresti comunque venire avanti, specialmente se avessi intenzione di eseguire comunque il refactoring a mano.

D'altra parte, esistono linguaggi tipizzati staticamente con essenzialmente gli stessi vantaggi dei linguaggi dinamici (cioè compatti e comprensibili - con tipi per lo più dedotti, ma molto presenti): Haskell è forse l'esempio principale, ma OCaML / F # , Scala e altri sono in questa categoria anche. Sfortunatamente, dal momento che sono meno pesantemente utilizzati rispetto ai più popolari linguaggi tipizzati staticamente, non dispongono di una vasta gamma di strumenti per essi (ad esempio per il refactoring).

Quindi, come linea di fondo, penso che farai adeguatamente con metodologie agili nella maggior parte delle lingue; Non direi che c'è un chiaro vincitore in questo momento in quanto la pratica non ha ancora raggiunto la teoria.

Il refactoring automatico è stato inventato in Smalltalk, un linguaggio tipizzato dinamicamente. Quindi no, non è impossibile avere un refactoring automatizzato in un linguaggio tipizzato dinamicamente. Quanto sia difficile dipende molto di più da altri fattori oltre alla disciplina di battitura. C ++ e Java sono entrambi tipizzati staticamente, ma gli strumenti di refactoring esistono solo per Java. Smalltalk con la sua introspezione e la semplice sintassi è stato un ottimo candidato per gli strumenti di refactoring.

In un certo senso, la digitazione dinamica rende in effetti più facile il refactoring. Se hai una buona suite di test, puoi essere sicuro che i tuoi refactoring non hanno infranto nulla. Una base di codice digitato in modo dinamico è in genere più piccola. Inoltre, i refactoring tendono a influenzare meno codice. Complessivamente, lo sforzo richiesto per il refactoring manuale di una base di codice dinamica è inferiore a quello di una base di codice statico.

Il refactoring è stato inventato in linguaggi dinamici. Gli strumenti di refactoring automatico sono stati inventati in linguaggi dinamici. Gli IDE sono stati inventati in linguaggi dinamici. Diverse metodologie Agile sono state inventate in linguaggi dinamici.

Non vedo alcun problema.

Per non dimenticare, il metodo di lavoro "Agile" noto come Extreme Programming (XP) è stato creato su un progetto Smalltalk (e Smalltalk conta sicuramente come lingua "dinamica").

Ecco un case study sull'uso industriale di uno strumento di refactoring fornito con un linguaggio tipizzato dinamicamente:

A very large Smalltalk application was developed at Cargill to support the operation of grain elevators and the associated commodity trading activities. The Smalltalk client application has 385 windows and over 5,000 classes. About 2,000 classes in this application interacted with an early (circa 1993) data access framework. The framework dynamically performed a mapping of object attributes to data table columns.

Analysis showed that although dynamic look up consumed 40% of the client execution time, it was unnecessary.

A new data layer interface was developed that required the business class to provide the object attribute to column mapping in an explicitly coded method. Testing showed that this interface was orders of magnitude faster. The issue was how to change the 2,100 business class users of the data layer.

A large application under development cannot freeze code while a transformation of an interface is constructed and tested. We had to construct and test the transformations in a parallel branch of the code repository from the main development stream. When the transformation was fully tested, then it was applied to the main code stream in a single operation.

Less than 35 bugs were found in the 17,100 changes. All of the bugs were quickly resolved in a three-week period.

If the changes were done manually we estimate that it would have taken 8,500 hours, compared with 235 hours to develop the transformation rules.

The task was completed in 3% of the expected time by using Rewrite Rules. This is an improvement by a factor of 36.

da "Trasformazione di un livello di dati dell'applicazione" Loew-Blosser OOPSLA 2002

Inoltre - " Strumenti per apportare modifiche impossibili - esperienze con uno strumento per trasformare grandi programmi Smalltalk "

I tuoi principi mi sembravano suoni corretti .

I linguaggi strongmente tipizzati come C # sono buoni candidati per una base di codice che richiede costantemente il re-factoring. Fondamentalmente la maggior parte degli strumenti di ri-factoring (come Resharper, JustCode, ecc.) Nel mercato sono molto efficaci nei linguaggi di programmazione tipizzati staticamente.

What does real world projects tell about usage of dynamically typed languages for agile methodology?

Per il team di sviluppo che pratica la metodologia Agile / Scrum è molto utile (anche critico) avere un buon set di strumenti di ri-factoring sotto armatura. Altrimenti, tutti i cambiamenti improvvisi nello sprint in arrivo potrebbero essere un incubo da modificare o riprogettare.

Pertanto, la metodologia agile non offre vantaggi alle lingue tipizzate in modo statico o dinamiche una volta. Ciò che fornisce è un approccio iterativo per creare un'applicazione solida.