I linguaggi dinamici sono in svantaggio per lo sviluppo agile?

12

Da quello che ho letto lo sviluppo agile spesso comporta il refactoring o il reverse engineering del codice in diagrammi. Naturalmente c'è molto di più, ma se consideriamo le pratiche che si basano su questi due metodi, le lingue tipicamente dinamiche sono svantaggiate?

Sembra che linguaggi tipicamente statici renderebbero molto più semplice il refactoring e il reverse engineering.

Il refactoring o il reverse engineering (automatizzato) sono difficili se non impossibili in linguaggi tipizzati dinamicamente? Cosa dicono i progetti del mondo reale sull'uso di linguaggi tipizzati dinamicamente per la metodologia agile?

agile dynamic-typing static-typing

— Gerenuk
fonte

5

Codice di ingegneria inversa in diagrammi? Perché dovresti farlo in Agile?

— CaffGeek,

7

Agile non significa "codice prima, documento dopo".

— Gort il robot il

@CaffGeek: alcuni libri spesso consigliati suggeriscono di disegnare diagrammi su una lavagna, quindi codificare e infine decodificare il codice in diagrammi per la prossima riunione.

— Gerenuk,

1

Penso che i caratteri fortemente tipizzati debbano essere rimossi dai tag e dal testo di questa domanda. La domanda sembra essere statica vs dinamica, non forte contro debole.

— Winston Ewert,

@WinstonEwert - Buona chiamata, ho cambiato i tag in dynamic-typingestatic-typing

— Carson63000

11

I linguaggi dinamici sono teoricamente in svantaggio, essendo tutti uguali, poiché specificano meno su come funziona il codice (quali sono i vincoli), e quindi meno del refactoring può essere fatto automaticamente e anche i problemi che si presentano non possono essere rilevati automaticamente .

Ma tutto il resto non è uguale. I linguaggi dinamici più diffusi consentono un codice estremamente compatto ma comprensibile, che generalmente rende più veloce lo sviluppo in essi e rende più facile da 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, soprattutto se comunque stavi pianificando di fare il refactoring a mano.

D'altra parte, esistono linguaggi tipicamente statici con essenzialmente gli stessi vantaggi dei linguaggi dinamici (cioè compatti e comprensibili - con tipi per lo più dedotti, ma molto lì): Haskell è forse l'esempio principale, ma OCaML / F #, Scala, e altri sono anche in questa categoria. Sfortunatamente, dal momento che sono meno utilizzati rispetto alle più popolari lingue tipizzate staticamente, non hanno un set di strumenti altrettanto esteso (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.

— Rex Kerr
fonte

Penso che questa risposta affronti meglio i punti chiave della domanda :) Potresti anche approfondire l'importanza del refactoring sicuro e del reverse engineering per lo sviluppo agile? Pensavo avesse giocato un ruolo molto importante? Forse è meno di quanto pensassi e gli strumenti per il linguaggio della dinamica sono abbastanza buoni.

— Gerenuk,

1

@Gerenuk - Non ho esperienza sufficiente con lo sviluppo agile (specialmente nei linguaggi dinamici) per dare una risposta autorevole - l'aspetto del refactoring è de-enfatizzato, lasciato lo stesso, ecc.? Tieni presente che altri aspetti comuni del processo, ad esempio lo sviluppo guidato dai test, possono aiutare a individuare dove il tuo refactoring è andato storto e, se fai un po 'più di sforzo, diciamo, nella fase di progettazione, potresti non aver bisogno refactoring tanto. Non credo che una particolare tecnica sia la chiave: tenere a portata di mano un set completo di strumenti, distribuito frequentemente e in collaborazione.

— Rex Kerr,

14

Il refactoring automatizzato è stato inventato in Smalltalk, un linguaggio tipizzato in modo dinamico. Quindi no, non è impossibile avere il 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 davvero solo per Java. Smalltalk con la sua introspezione e sintassi semplice era un ottimo candidato per gli strumenti di refactoring.

In un certo senso, la digitazione dinamica in realtà rende più semplice il refactoring. Se disponi di una buona suite di test, puoi essere certo che i tuoi refactoring non hanno rotto nulla. Una base di codice tipizzata in modo dinamico è generalmente più piccola. Inoltre, i refactoring tendono a influenzare meno codice. Nel complesso, lo sforzo richiesto per il refactoring manuale di una base di codice dinamica è inferiore a quello di una base di codice statica.

— Winston Ewert
fonte

1

Che dire del reverse engineering allora? Smalltalk è diverso da Python per quanto riguarda la digitazione? Sembra un problema arduo dedurre tutti i tipi in Python e quindi determinare quale metodo sia realmente identico e non solo con lo stesso nome.

— Gerenuk,

2

Smalltalk non è che molto diverso da Python per quanto riguarda la tipizzazione. Si tratta , tuttavia, significativamente diverso per quanto riguarda utensili . Gli strumenti e gli IDE disponibili per Smalltalk sono molto meglio di quelli disponibili per Python o anche C #, C ++ e Java. Il motivo per cui gli IDE per Python sono cattivi non è perché Python è tipizzato in modo dinamico, ma perché, bene, gli IDE per Python sono cattivi. Non dimentichiamo che l'IDE che ora conosciamo come Eclipse era chiamato una volta VisualAge per Smalltalk. La community Smalltalk ha 40 anni di esperienza nella creazione di IDE e li applica a Java.

— Jörg W Mittag,

@Gerenuk, la digitazione di Smalltalk non è diversa da quella di Python. In altri modi, come l'introspezione, Smalltalk offre un set di funzionalità più intuitivo per il refactoring. L'inferenza del tipo in Python richiederebbe lavoro, ma è stata fatta, vedi il progetto PyPy.

— Winston Ewert,

1

@WinstonEwert "ma puoi eseguire il refactoring manualmente e i linguaggi dinamici in realtà lo rendono abbastanza semplice" - No, il refactoring manuale non si ridimensiona. Il supporto degli strumenti per il refactoring cambia tutto anche quando il refactoring non è automatico al 100% (vedere i frammenti del case study di seguito - programmers.stackexchange.com/a/166594/4334 )

— igouy,

1

Quasi ogni punto della tua "programmazione dinamica in realtà semplifica il refactoring" è dubbio o non sequitur. La programmazione dinamica non significa che hai una suite di test più completa, solo una più ampia (perché alcune cose hanno bisogno di test che altrimenti verrebbero catturati staticamente). Non offrite alcun supporto per "i refactoring tendono a influire meno sul codice" (in aggiunta al "progetto è comunque più piccolo", il che è probabilmente vero dato l'attuale raccolto di linguaggi dinamici). E lo "sforzo implicato nel refactoring manuale" sembra sbagliato a meno che tu non intenda che non lascerai che il tuo compilatore ti aiuti!

— Rex Kerr,

8

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

Non vedo davvero alcun problema.

— Jörg W Mittag
fonte

"Smalltalk non è molto diverso da Python per quanto riguarda la digitazione. Tuttavia, è significativamente diverso per quanto riguarda gli strumenti." - Forse sta iniziando a cambiare, vedi jetbrains.com/pycharm/features/index.html

— igouy,

3

Per non dimenticare, il modo di lavorare "Agile" che divenne noto come Extreme Programming (XP) è stato creato su un progetto Smalltalk (e Smalltalk conta certamente come un linguaggio "dinamico").

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

Una grande applicazione Smalltalk è stata sviluppata in Cargill per supportare il funzionamento degli elevatori di grano e le attività di commercio di merci associate. L'applicazione client Smalltalk ha 385 finestre e oltre 5.000 classi. Circa 2.000 classi in questa applicazione hanno interagito con un primo (circa 1993) framework di accesso ai dati. Il framework ha eseguito dinamicamente una mappatura degli attributi degli oggetti alle colonne della tabella di dati.

L'analisi ha dimostrato che, sebbene la ricerca dinamica richiedesse il 40% dei tempi di esecuzione del client, non era necessaria.

È stata sviluppata una nuova interfaccia di livello dati che ha richiesto alla business class di fornire l'attributo object alla mappatura delle colonne in un metodo esplicitamente codificato. I test hanno dimostrato che questa interfaccia era più veloce per ordini di grandezza. Il problema era come modificare i 2.100 utenti di business class del livello dati.

Una grande applicazione in fase di sviluppo non può bloccare il codice mentre una trasformazione di un'interfaccia viene costruita e testata. Abbiamo dovuto costruire e testare le trasformazioni in un ramo parallelo del repository di codice dal flusso di sviluppo principale. Quando la trasformazione è stata completamente testata, è stata applicata al flusso di codice principale in un'unica operazione.

Sono stati trovati meno di 35 bug nelle 17.100 modifiche. Tutti i bug sono stati risolti rapidamente in un periodo di tre settimane.

Se le modifiche fossero state apportate manualmente, stimiamo che sarebbero state necessarie 8.500 ore, rispetto alle 235 ore per lo sviluppo delle regole di trasformazione.

L'attività è stata completata nel 3% del tempo previsto utilizzando le regole di riscrittura. Questo è un miglioramento di un fattore di 36.

da "Trasformazione di un livello di dati applicativi" Will Loew-Blosser OOPSLA 2002

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

— igouy
fonte

1

I tuoi principi, secondo me, mi sembrano corretti .

I linguaggi fortemente tipizzati come C # sono buoni candidati per una base di codice che necessita costantemente di un nuovo factoring. Fondamentalmente la maggior parte degli strumenti di re-factoring (come Resharper, JustCode, ecc.) Sul mercato sono molto efficaci nei linguaggi di programmazione tipizzati staticamente.

Cosa dicono i progetti del mondo reale sull'uso di linguaggi tipizzati dinamicamente per la metodologia agile?

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

Pertanto, la metodologia agile non offre vantaggi ai linguaggi tipicamente statici o dinamici una volta. Ciò che fornisce è un approccio iterativo per creare un'applicazione solida.

— Yusubov
fonte

4

I linguaggi dinamici avevano strumenti di refactoring automatizzato molto prima che esistesse C # e quando Notepad era ancora l'IDE Java più potente.

— Jörg W Mittag,

4

Questa risposta non è completamente supportata dalla mia esperienza. Linguaggi dinamici sono in genere più veloce per fare le cose in rispetto a quelli più convenzionali staticamente tipizzati (ho avuto imparare Haskell o ML o qualcosa di simile qualche tempo). Sono anche molto più veloci da modificare se improvvisamente necessari, il che ha portato alla mia conclusione che Common Lisp era la lingua migliore quando non sapevi davvero cosa stavi facendo. Inoltre, dove pensi sia iniziato il refactoring?

— David Thornley,

1

perché stai pensando così, ad esempio javascript è un linguaggio dinamico, ma Re-sharper non fa lo stesso lavoro slick di C #. In secondo luogo, NON ho detto che "i linguaggi dinamici sono più lenti a fare le cose".

— Yusubov,

Dalle persone che ti hanno portato IntelliJ IDEA - PyCharm - "Rinomina refactoring consente di eseguire modifiche di codice globali in modo sicuro e istantaneo. Le modifiche locali all'interno di un file vengono eseguite sul posto. I refactoring funzionano in semplici progetti Python e Django. Usa Introduce Variable / Campo / Costante e Inline Local per migliorare la struttura del codice all'interno di un metodo, Estrai metodo per scomporre metodi più lunghi, Estrai superclasse, Push Up, Pull Down e Move per spostare i metodi e le classi. " jetbrains.com/pycharm/features/index.html

— igouy,

@igouy, mi riferisco a Resharper e JustCode nella mia risposta. Pertanto, è vero per il contesto a cui è riferito.

— Yusubov,