Wie wirkt sich die fehlende statische Typisierung von Python auf Wartbarkeit und Erweiterbarkeit in größeren Projekten aus?

Question

Nach dem Lesen this very informative (albeit somewhat argumentative) question würde ich gerne Ihre Erfahrung mit der Programmierung großer Projekte mit Python wissen. Werden die Dinge unkontrollierbar, wenn das Projekt größer wird? Diese Sorge ist eine Sache, die mich an Java bindet. Ich wäre daher besonders interessiert an informiert Vergleiche der Wartbarkeit und Erweiterbarkeit von Java und Python für große Projekte.

Answer 1

Ich arbeite an einem großen kommerziellen Produkt in Python. Ich gebe eine sehr grobe Schätzung von 5000 Dateien x 500 Zeilen. Das sind etwa 2,5 Millionen Zeilen Python. Beachten Sie, dass die Komplexität dieses Projekts wahrscheinlich 10 Millionen Zeilen Code in anderen Sprachen entspricht. Ich habe nicht von einem einzigen Ingenieur/Architektur/Manager gehört, der sich darüber beschwert, dass Python-Code nicht erreichbar ist. Von dem, was ich von unserem Bug-Tracker gesehen habe, sehe ich kein systemisches Problem, das durch statische Typprüfung vermieden werden könnte. In der Tat gibt es sehr wenige Fehler, die durch falsche Verwendung des Objekttyps erzeugt werden.

Ich denke, das ist ein sehr gutes akademisches Thema empirisch zu studieren, warum statische Klasse basierte Sprache scheint nicht so kritisch zu sein, wie man denken könnte.

Und über Erweiterbarkeit. Wir haben gerade eine Datenbank 2 über der Datenbank 1 in unserem Produkt hinzugefügt, die beide nicht SQL sind. Es gibt kein Problem im Zusammenhang mit der Typprüfung. Zunächst haben wir eine API entwickelt, die flexibel genug ist, um unterschiedliche zugrunde liegende Implementierungen vorauszusehen. Ich denke, dynamische Sprache ist in dieser Hinsicht eher hilfreich als hinderlich. Als wir mit der Test- und Fehlerbehebungs-Phrase fortfuhren, arbeiteten wir an der Art von Fehlern, mit denen sich Leute beschäftigten, die an irgendeiner Sprache arbeiteten. Zum Beispiel Probleme bei der Speichernutzung, Konsistenz und referenzielle Integrität, Probleme bei der Fehlerbehandlung. Ich sehe keine statische Typprüfung, die bei diesen Herausforderungen viel hilft. Auf der anderen Seite haben wir stark von der dynamischen Sprache profitiert, indem wir den Code mitten im Flug oder nach einem einfachen Patching injizieren konnten. Und wir können unsere Hypothese testen und unsere Fixes schnell demonstrieren.

Es ist sicher zu sagen, die meisten unserer über 100 Ingenieure sind glücklich und produktiv mit Python. Es ist wahrscheinlich undenkbar, dass wir dasselbe Produkt mit einer statischen Sprache in der gleichen Zeit und mit der gleichen Qualität erstellen.

Answer 2

Aus meiner Erfahrung können statisch getippte Sprachen schwierig zu verwalten sein. Nehmen wir zum Beispiel an, Sie haben eine Dienstprogrammfunktion, die eine benutzerdefinierte Klasse als Parameter akzeptiert. Wenn Sie auf der Straße sind, müssen Sie eine neue Namenskonvention einführen, denn der Name dieser Klasse muss sich ändern, und dann müssen sich auch alle Ihre Dienstprogrammfunktionen ändern. In einer Sprache wie Python spielt es keine Rolle, solange die Klasse die gleichen Methoden implementiert.

Persönlich verachte ich eine Sprache, die mir in den Weg kommt. Die Geschwindigkeit, mit der Sie Ihre Ideen ausdrücken, ist ein Wert, und das ist der Vorteil, den Python gegenüber Java hat.

Answer 3

Ich habe Python für viele Projekte verwendet, von einigen hundert Zeilen bis zu mehreren tausend Zeilen. Dynamische Typisierung ist eine große Zeitersparnis und es macht OO-Konzepte wie Polymorphismus einfacher zu verwenden. Das Typsystem macht Projekte nicht unwartbar. Wenn Sie sich das nicht vorstellen können, versuchen Sie ein paar Dinge in Python zu schreiben und sehen Sie, wie sie laufen.

Answer 4

Eine große Codebasis in Python ohne gute Testabdeckung könnte ein Problem sein. Aber das ist nur ein Teil des Bildes. Es geht um Menschen und geeignete Ansätze, um den Job zu machen.

Ohne

• Source Control
• Bug Tracking
• Einheit
• engagiertes Team

Tests können Sie mit jeder Art von Sprache scheitern.

Answer 5

Ich erinnere mich an die Tage vor und nach der Innovation von IntelliJ IDEA. Es gibt große Unterschiede. Bevor die statische Typisierung nur zum Kompilieren verwendet wurde, behandelt die Entwicklung den Quellcode im Grunde als Textdateien. Nach dem Quelltext handelt es sich um strukturierte Informationen, viele Entwicklungsaufgaben müssen einfacher sein, dank statischer Typisierung.

Allerdings ist es nicht wie in den alten Tagen die Hölle leben. Wir nahmen es so wie es ist, tun was immer nötig ist, benutzen die verfügbaren Tools, um das System aufzubauen, Zufriedenheit. Es gab nicht viele unglückliche Erinnerungen. Das ist wahrscheinlich, was dynamische Programmierer jetzt fühlen. Ist doch nicht so schlimm.

Natürlich werde ich nie in die alten Zeiten zurückkehren. Wenn ich eine solche IDE nicht benutzen darf, schätze ich, dass wir alle zusammen programmieren.

Answer 6

Nach meiner Erfahrung hängt die Wartbarkeit von geringer Kopplung, guter Dokumentation, gutem Entwicklungsprozess und exzellentem Test ab. Statisches Tippen hat damit wenig zu tun.

Die Fehler, die Java zur Kompilierzeit abfangen kann, sind nur eine kleine Teilmenge der Fehler, die auftreten können. Sie sind auch fast immer trivial, wenn man sie testet. Sie können auf keinen Fall eine Methode für ein Objekt der falschen Klasse aufrufen, wenn Sie testen, dass Ihr Code die richtige Antwort liefert! In dieser Hinsicht könnte man argumentieren, dass Python tatsächlich besser für die Gewährleistung der Qualität ist; von zwang Sie zumindest ein wenig zu testen, um sicherzustellen, dass Ihr Code frei von einfachen Tippfehlern ist, stellt es sicher, dass Sie tatsächlich tun mindestens ein bisschen testen.

In der Tat ist Java nicht einmal ein sehr gutes Beispiel für eine Sprache mit starken statischen Prüfungen, um viele Fehler zu finden. Versuchen Sie, in Haskell oder Mercury zu programmieren, um zu sehen, was ich meine, oder besser noch, programmieren Sie in Scala und verbinden Sie sich mit Java-Bibliotheken; Der Unterschied in der "Korrektheit", die der Compiler für Sie garantieren kann, fällt auf, wenn Sie den normalen idiomatischen Scala-Code mit Scala-Bibliotheken mit dem Code vergleichen, der mit Java-Bibliotheken umgehen muss (ich habe das tatsächlich gemacht, da ich ein Programm programmiere) Bit in Scala auf Android).

Ihre Fähigkeit, guten wartbaren Code in großen Code-Basen von vielen Entwicklern über längere Zeit, trotz der Mängel der Java Erkennung statischer Fehler im Vergleich zu Sprachen wie Scala, auf genau hängt die gleichen Techniken Python gearbeitet zu schreiben Programmierer tun dasselbe in ihren großen Codebasen, trotz der Unzulänglichkeiten von Pythons statischer Fehlererkennung im Vergleich zu Java.

Answer 7

Versuchen Sie, die Quelle eines scheinbar fehlerhaften Objekts in einem großen, dynamisch typisierten Framework mit vielen IoC- oder anderen Entwurfsmustern zurückzuverfolgen, bei denen das Objekt nicht direkt im Stapel nachverfolgt werden kann.

Versuchen Sie dies nun in einer statisch typisierten Sprache.

Wenn der Typ des Objekts nicht in der Nähe der Verwendungsstelle dokumentiert ist (z. B. über Typanmerkungen, a-la Pythons typsichere Bibliothek) oder irgendwo auf dem Stapel, kann die Herkunft der Objekte praktisch ausgeschlossen werden. Ich spreche aus Erfahrung, nachdem ich versucht habe, Teile des BuildBot-Frameworks zu debuggen. Es umfasste eine immense Menge an Rohtext, der das Framework durchforstete, selbst mit ausgefallenen IDEs wie PyDev, Komodo und Wingware.

Ich bezweifle nicht, dass es möglich ist, einige type constraints auf dynamische Sprachen zu erzwingen, aber das Fehlen jeglicher Standardisierung scheint ein Hindernis für jeden zu sein, der versucht, einen Teil eines großen existierenden Frameworks zu debuggen.