Sind dynamische Sprachen für eine agile Entwicklung von Nachteil?

12

Nach dem, was ich gelesen habe, beinhaltet die agile Entwicklung oft das Umgestalten oder Reverse Engineering von Code in Diagrammen. Natürlich gibt es noch viel mehr, aber wenn wir die Praktiken berücksichtigen, die auf diesen beiden Methoden beruhen, sind dynamisch typisierte Sprachen im Nachteil?

Es scheint, dass statisch getippte Sprachen das Refactoring und Reverse Engineering erheblich vereinfachen würden.

Ist Refactoring oder (automatisiertes) Reverse Engineering in dynamisch typisierten Sprachen schwierig, wenn nicht unmöglich? Was sagen reale Projekte über die Verwendung dynamisch typisierter Sprachen für eine agile Methodik?

agile dynamic-typing static-typing Gerenuk
quelle
5
Reverse Engineering Code in Diagramme umwandeln? Warum sollten Sie das in Agile tun?
CaffGeek
7
Agile bedeutet nicht "Code zuerst, Dokument später".
Gort the Robot
@CaffGeek: In einigen häufig empfohlenen Büchern wird empfohlen, Diagramme auf einem Whiteboard zu zeichnen, dann Code zu erstellen und schließlich Code für die nächste Besprechung in Diagramme umzuwandeln.
Gerenuk
1
Ich denke, stark getippt sollte aus Tags und Text dieser Frage entfernt werden. Die Frage scheint statisch oder dynamisch zu sein, nicht stark oder schwach.
Winston Ewert
@ WinstonEwert - Guter Anruf, ich habe die Tags geändert dynamic-typingundstatic-typing
Carson63000

Antworten:

11

Dynamische Sprachen sind theoretisch von Nachteil, da alle anderen Sprachen gleich sind, da sie weniger Angaben zur Funktionsweise des Codes (zu den Einschränkungen) enthalten und daher weniger Umgestaltungen automatisch durchgeführt werden können und auftretende Probleme nicht automatisch erkannt werden können .

Aber alles andere ist nicht gleich. Die beliebtesten dynamischen Sprachen ermöglichen sehr kompakten und dennoch verständlichen Code, wodurch die Entwicklung in ihnen im Allgemeinen beschleunigt wird und die Logik (die sich beim Refactoring ändern kann) visuell leichter erkennbar wird. Obwohl Sie möglicherweise den relativen Vorteil verlieren, in einer dynamischen Sprache zu arbeiten, können Sie dennoch weiterkommen, insbesondere wenn Sie das Refactoring ohnehin von Hand planen.

Auf der anderen Seite gibt es statisch typisierte Sprachen mit im Wesentlichen den gleichen Vorteilen wie dynamische Sprachen (dh kompakt und verständlich - Typen werden meistens abgeleitet, aber sehr häufig): Haskell ist vielleicht das führende Beispiel, aber OCaML / F #, Scala, und andere sind auch in dieser Kategorie. Da sie weniger häufig verwendet werden als die gängigsten statisch typisierten Sprachen, verfügen sie leider nicht über so umfangreiche Toolsets (z. B. für das Refactoring).

Unter dem Strich denke ich, dass Sie mit agilen Methoden in den meisten Sprachen angemessen umgehen können. Ich würde nicht sagen, dass es im Moment einen klaren Sieger gibt, da die Praxis die Theorie noch nicht eingeholt hat.

Rex Kerr
quelle
Ich denke, diese Antwort spricht die wichtigsten Punkte der Frage am besten an :) Könnten Sie auch auf die Bedeutung von sicherem Refactoring und Reverse-Engineering für die agile Entwicklung eingehen? Ich nahm an, dass es eine sehr wichtige Rolle spielt? Vielleicht ist es weniger, als ich dachte, und Tools für die dynamische Sprache sind gerade gut genug.
Gerenuk
1
@Gerenuk - Ich habe nicht genügend Erfahrung mit agiler Entwicklung (insbesondere in dynamischen Sprachen), um eine verbindliche Antwort zu geben - wird der Refactoring-Aspekt unterstrichen, gleich gelassen usw.? Denken Sie daran, dass andere allgemeine Aspekte des Prozesses - beispielsweise die testgesteuerte Entwicklung - hilfreich sein können, um festzustellen, wo Ihr Refactoring schief gelaufen ist, und wenn Sie beispielsweise etwas mehr Aufwand in die Entwurfsphase investieren, ist dies möglicherweise nicht erforderlich so viel umgestalten. Ich glaube nicht, dass eine bestimmte Technik der Schlüssel ist - sie hält einen vollständigen Satz von Tools bereit, die häufig und gemeinsam eingesetzt werden.
Rex Kerr
13

Das automatisierte Refactoring wurde in Smalltalk, einer dynamisch typisierten Sprache, erfunden. Nein, es ist nicht unmöglich, automatisiertes Refactoring in einer dynamisch getippten Sprache durchzuführen. Wie schwer es ist, hängt wesentlich mehr von anderen Faktoren als der Schreibdisziplin ab. C ++ und Java sind beide statisch typisiert, aber Refactoring-Tools gibt es nur für Java. Smalltalk war mit seiner Selbstbeobachtung und einfachen Syntax ein wirklich guter Kandidat für Refactoring-Tools.

In gewisser Weise erleichtert die dynamische Typisierung das Refactoring. Wenn Sie eine gute Testsuite haben, können Sie sicher sein, dass Ihre Refactorings nichts kaputt gemacht haben. Eine dynamisch typisierte Codebasis ist normalerweise kleiner. Darüber hinaus wirken sich Refactorings in der Regel weniger auf den Code aus. Insgesamt ist der Aufwand für die manuelle Umgestaltung einer dynamischen Codebasis geringer als der einer statischen Codebasis.

Winston Ewert
quelle
1
Was ist dann mit Reverse Engineering? Unterscheidet sich Smalltalk hinsichtlich der Eingabe von Python? Es scheint ein schwieriges Problem zu sein, alle Typen in Python abzuleiten und so zu bestimmen, welche Methoden wirklich identisch sind und nicht nur den gleichen Namen haben.
Gerenuk
1
Smalltalk ist nicht , dass viel anders aus Python in Bezug auf die Eingabe. In Bezug auf das Werkzeug ist es jedoch erheblich anders . Die Tools und IDEs, die für Smalltalk verfügbar sind , sind weitaus besser als diejenigen, die für Python oder sogar C #, C ++ und Java verfügbar sind . Der Grund, warum IDEs für Python fehlerhaft sind, liegt nicht darin, dass Python dynamisch typisiert wird, sondern darin, dass die IDEs für Python fehlerhaft sind. Vergessen wir nicht, dass die IDE, die wir heute als Eclipse kennen, einmal VisualAge für Smalltalk hieß. Die Smalltalk-Community verfügt über 40 Jahre Erfahrung im Aufbau von IDEs und wendet diese auf Java an.
Jörg W Mittag
@ Gerenuk, Smalltalks Eingabe unterscheidet sich nicht von Python. Auf andere Weise, wie zum Beispiel durch Introspektion, bietet Smalltalk einen Funktionsumfang, der das Refactoring erleichtert. Das Inferenzieren von Eingaben in Python würde Arbeit erfordern, wurde jedoch durchgeführt (siehe PyPy-Projekt).
Winston Ewert
1
@ WinstonEwert "aber Sie können manuell umgestalten, und dynamische Sprachen machen das eigentlich ziemlich einfach" - Nein, manuelles Umgestalten skaliert nicht. Werkzeugunterstützung für Refactoring ändert sich alles , selbst wenn Refactoring nicht zu 100% erfolgt automatisch (siehe Fallstudie Schnipsel unten - programmers.stackexchange.com/a/166594/4334 )
igouy
1
Fast jeder Punkt in Ihrer "dynamischen Programmierung macht das Refactoring tatsächlich einfacher" ist zweifelhaft oder keine Folge. Dynamische Programmierung bedeutet nicht, dass Sie eine umfassendere Testsuite haben, nur eine größere (da einige Dinge getestet werden müssen, die sonst statisch erfasst würden). Sie bieten keine Unterstützung für "Refactorings wirken sich in der Regel auf weniger Code aus" (als Ergänzung zu "das Projekt ist ohnehin kleiner", was angesichts der aktuellen Anzahl dynamischer Sprachen wahrscheinlich zutrifft). Und der "Aufwand beim manuellen Refactoring" scheint falsch zu sein, es sei denn, Sie wollen sich nicht einmal von Ihrem Compiler helfen lassen!
Rex Kerr
8

Refactoring wurde in dynamischen Sprachen erfunden. Automated Refactoring Tools wurden in dynamischen Sprachen erfunden. IDEs wurden in dynamischen Sprachen erfunden. Mehrere agile Methoden wurden in dynamischen Sprachen erfunden.

Ich sehe wirklich kein Problem.

Jörg W. Mittag
quelle
"Smalltalk unterscheidet sich nicht so sehr von Python in Bezug auf das Tippen. Es unterscheidet sich jedoch erheblich in Bezug auf das Werkzeug." - Vielleicht beginnt sich das zu ändern, siehe jetbrains.com/pycharm/features/index.html
igouy
3

Wenn wir nicht vergessen, wurde die "agile" Arbeitsweise, die als Extreme Programming (XP) bekannt wurde, in einem Smalltalk-Projekt erstellt (und Smalltalk zählt zweifellos als "dynamische" Sprache).

Hier ist eine Fallstudie zum industriellen Einsatz eines Refactoring-Tools mit einer dynamisch typisierten Sprache:

Bei Cargill wurde eine sehr große Smalltalk-Anwendung entwickelt, um den Betrieb von Getreideaufzügen und die damit verbundenen Warenhandelsaktivitäten zu unterstützen. Die Smalltalk-Clientanwendung verfügt über 385 Fenster und über 5.000 Klassen. Ungefähr 2000 Klassen in dieser Anwendung interagierten mit einem frühen Datenzugriffsframework (circa 1993). Das Framework führte dynamisch eine Zuordnung von Objektattributen zu Datentabellenspalten durch.

Die Analyse ergab, dass die dynamische Suche zwar 40% der Ausführungszeit des Clients in Anspruch nahm, jedoch nicht erforderlich war.

Es wurde eine neue Datenschichtschnittstelle entwickelt, bei der die Geschäftsklasse das Objektattribut für die Spaltenzuordnung in einer explizit codierten Methode bereitstellen musste. Tests ergaben, dass diese Schnittstelle um Größenordnungen schneller war. Die Frage war, wie die 2.100 Business-Class-Benutzer der Datenschicht geändert werden sollten.

Eine große in der Entwicklung befindliche Anwendung kann keinen Code einfrieren, während eine Transformation einer Schnittstelle erstellt und getestet wird. Wir mussten die Transformationen in einem parallelen Zweig des Code-Repositorys aus dem Hauptentwicklungsstrom erstellen und testen. Wenn die Umwandlung vollständig getestet wurde, wurde sie in einem einzigen Vorgang auf den Hauptcode-Stream angewendet.

In den 17.100 Änderungen wurden weniger als 35 Bugs gefunden.Alle Fehler wurden innerhalb von drei Wochen schnell behoben.

Wenn die Änderungen manuell vorgenommen würden, wären schätzungsweise 8.500 Stunden vergangen, verglichen mit 235 Stunden für die Entwicklung der Transformationsregeln.

Die Aufgabe wurde in 3% der erwarteten Zeit mithilfe von Umschreiberegeln abgeschlossen. Dies ist eine Verbesserung um den Faktor 36.

aus "Transformation einer Anwendungsdatenschicht" Will Loew-Blosser OOPSLA 2002

Außerdem - "Tools zum Vornehmen unmöglicher Änderungen - Erfahrungen mit einem Tool zum Transformieren großer Smalltalk-Programme"

igouy
quelle
1

Dein Grundsatzgedanke klingt für mich richtig .

Die stark typisierten Sprachen wie C # sind gute Kandidaten für eine Codebasis, die ständig überarbeitet werden muss. Grundsätzlich sind die meisten Re-Factoring-Tools (wie Resharper, JustCode usw.) auf dem Markt in statisch typisierten Programmiersprachen sehr effektiv.

Was sagen reale Projekte über die Verwendung dynamisch typisierter Sprachen für eine agile Methodik?

Für Entwicklerteams, die mit der Agile / Scrum-Methodik arbeiten, ist es sehr hilfreich (auch kritisch), einen guten Satz von Re-Factoring-Tools unter Rüstung zu haben. Andernfalls können alle plötzlichen Änderungen im bevorstehenden Sprint ein Albtraum sein, der geändert oder neu gestaltet werden muss.

Somit bietet die agile Methodik keine Vorteile für statisch typisierte oder einmal dynamische Sprachen. Was es bietet, ist ein iterativer Ansatz zum Erstellen einer soliden Anwendung.

Yusubov
quelle
4
Dynamische Sprachen hatten Refactoring-Tools lange bevor C # überhaupt existierte und als Notepad noch die leistungsstärkste Java-IDE war.
Jörg W Mittag
4
Diese Antwort wird meiner Erfahrung nach nicht vollständig unterstützt. Dynamische Sprachen sind in der Regel schneller , Dinge zu tun in als die konventionelleren statisch typisierten diejenigen (ich habe bekam Haskell oder ML oder so ähnlich irgendwann zu lernen). Sie können auch viel schneller geändert werden, wenn sie plötzlich benötigt werden, was zu meiner Schlussfolgerung führte, dass Common Lisp die beste Sprache war, wenn Sie nicht wirklich wussten, was Sie taten. Wo haben Sie mit dem Refactoring begonnen?
David Thornley
1
Warum denken Sie so, zum Beispiel ist Javascript eine dynamische Sprache, aber Re-sharper erledigt nicht den gleichen Slick-Job wie mit C #. Zweitens habe ich NICHT gesagt, dass "dynamische Sprachen langsamer sind, um die Dinge zu tun".
Yusubov
Von den Leuten, die Ihnen IntelliJ IDEA - PyCharm - "Rename Refactoring" gebracht haben, können Sie globale Codeänderungen sicher und sofort durchführen. Lokale Änderungen in einer Datei werden direkt durchgeführt. Refactorings funktionieren in einfachen Python- und Django-Projekten. Verwenden Sie Introduce Variable / Field / Constant und Inline Local zur Verbesserung der Codestruktur innerhalb einer Methode, Extract Method zum Aufbrechen längerer Methoden, Extract Superclass, Push Up, Pull Down und Move zum Verschieben der Methoden und Klassen. " jetbrains.com/pycharm/features/index.html
igouy
@igouy, ich beziehe mich in meiner Antwort auf Resharper und JustCode. Es gilt also für den Kontext, auf den es sich bezieht.
Yusubov