Python Programmierung - Regeln / Ratschläge für die Entwicklung von Software auf Unternehmensebene in Python?

7

Ich bin ein etwas fortgeschrittener C ++ / Java-Entwickler, der sich vor kurzem für Python interessiert hat und ich genieße seine dynamische Typisierung und seinen effizienten Codierungsstil sehr. Ich benutze es derzeit für meine kleinen Programmieranforderungen, wie das Lösen von Programmierrätseln und Skripten, aber ich bin neugierig, ob irgendjemand da draußen erfolgreich Python in einem Projekt in Enterprise-Qualität verwendet hat? (Vorzugsweise mit modernen Programmierkonzepten wie OOP und einer Art Design Pattern)

Wenn ja, erklären Sie bitte warum Sie Python (spezifisch) gewählt haben und geben Sie uns einige der Lektionen , die Sie von diesem Projekt gelernt haben ? (Fühlen Sie sich frei, die Verwendung von Python im Projekt gegenüber Java oder etc zu vergleichen)

    
HipsterZipster 23.03.2009, 09:59
quelle

2 Antworten

16

Ich benutze Python für die Entwicklung einer komplexen Versicherung Underwriting-Anwendung.

Unsere Anwendungssoftware packt unser versicherungsmathematisches Modell im Wesentlichen so um, dass Unternehmen es abonnieren können. Dieses Geschäft basiert auf unseren Aktuaren und ihrem tiefen Denken. Wir verpacken keinen cleveren Algorithmus, der relativ stabil ist. Wir vermieten unsere Versicherungsmathematiker über einen Webservice an Kunden.

  1. Die Versicherungsmathematiker müssen frei sein, Änderungen vorzunehmen, wenn sie einen tieferen Einblick in die verschiedenen Faktoren erhalten, die zu Ansprüchen führen.

    • Statische Sprachen (Java, C ++, C #) führen zu einem frühen Lock-In zu einem Datenmodell.

    • Python ermöglicht uns ein sehr flexibles Datenmodell. Sie können Faktoren oder Informationsquellen ohne große Entwicklungskosten und Komplexität hinzufügen, ändern oder löschen. Das Tippen mit der Ente erlaubt uns, neue Stücke ohne viel Nacharbeit einzuführen.

  2. Unsere Software ist ein Service (kein Paket), also haben wir ein endloses Integrationsproblem.

    • Statische Sprachen benötigen komplexe Mapping-Komponenten. Oft eine Art konfigurierbares, XML-gesteuertes Mapping von Kundennachrichten zu unseren sich ständig ändernden internen Strukturen.

    • Python erlaubt uns, die Zuordnungen als einfache Python-Klassendefinition zu haben, die wir einfach optimieren, testen und in Produktion bringen. Dieses Modul unterliegt keinen Einschränkungen - es handelt sich um erstklassigen Python-Code.

  3. Wir müssen einen umfangreichen, lang andauernden Proof-of-Concept machen. Dazu gehören zahlreiche "Was-wäre-wenn" -Szenarien mit unterschiedlichen Datenfeeds und benutzerdefinierten Funktionen.

    • Statische Sprachen erfordern viel sorgfältiges Planen und Nachdenken, um eine weitere Demo zu erstellen, eine weitere Zuordnung von einer weiteren vom Kunden bereitgestellten Datei zur aktuellen Version unserer aktuariellen Modelle.

    • Python benötigt viel weniger Planung. Duck Typing (und Django) lassen uns eine Demo ohne große Schmerzen ausknocken. Die Datenzuordnungen sind einfache Python-Klassendefinitionen. Unsere versicherungsmathematischen Modelle befinden sich in einem ziemlich konstanten Wandel.

  4. Unser Geschäftsmodell unterliegt bestimmten Verhandlungen. Wir haben ziemlich komplexe Verträge mit Informationsanbietern; diese ändern sich nicht so oft wie das versicherungsmathematische Modell, aber Änderungen müssen hier angepasst werden.

    • Statische Sprachen binden sich an Annahmen über die Verträge und erfordern ziemlich komplexe Designs (oder Workarounds), um mit den Hirngespinsten der Geschäftsleute umzugehen, die die Deals aushandeln.

    • In Python verwenden wir eine umfangreiche Testsuite und machen eine Menge Refactoring, da die verschiedenen Vertragsbedingungen auf uns zutreffen.

    Jede Woche bekommen wir eine Frage wie "Können wir eine Bestimmung wie X handhaben?" Unsere Standardantwort lautet "Absolut". Gefolgt von einer Stunde Refactoring, um sicher zu sein, dass wir damit umgehen können, wenn der Deal in dieser Form getroffen wurde.

  5. Wir sind meistens ein RESTful Webservice. Django macht eine Menge davon out of the box. Wir mussten einige Erweiterungen schreiben, weil unser Sicherheitsmodell etwas strenger ist als das von Django.

    • Statische Sprachen müssen keine Quelle liefern. Mag das Sicherheitsmodell nicht? Bezahlen Sie den Kreditor $$$.

    • Dynamische Sprachen müssen als Quelle versandt werden. In unserem Fall verbringen wir viel Zeit damit, die Quelle von Django sorgfältig zu lesen, um sicherzustellen, dass unser Sicherheitsmodell sauber mit dem Rest von Django zusammenpasst. Wir brauchen keine HIPAA-Konformität, aber wir bauen sie trotzdem auf.

  6. Wir verwenden Webdienste von Informationsanbietern. urllib2 macht das für uns nett. Wir können eine Schnittstelle schnell entwickeln.

    • Mit einer statischen Sprache haben Sie APIs, Sie schreiben, Sie laufen, und Sie hoffen, es hat funktioniert. Der Entwicklungszyklus ist Bearbeiten, Kompilieren, Erstellen, Ausführen, Absturz, Protokolle anzeigen; und das ist nur, um die Schnittstelle zu spike und sicher sein, dass wir das Protokoll, die Anmeldeinformationen und die Konfigurationsrechte haben.

    • Wir üben die Schnittstelle in interaktivem Python. Da wir es interaktiv ausführen, können wir die Antworten sofort untersuchen. Der Entwicklungszyklus wird auf Ausführen, Bearbeiten reduziert. Wir können eine Web-Service-API an einem Nachmittag starten.

S.Lott 23.03.2009, 11:11
quelle
3

Ich habe Python als verteiltes Computing-Framework in einer der größten Banken der Welt verwendet. Es wurde gewählt, weil:

  • Es musste extrem schnell sein, um neue Funktionalitäten zu entwickeln und zu implementieren;
  • Es musste leicht mit C und C ++ integrierbar sein;
  • Einige Teile des Codes sollten von Leuten geschrieben werden, deren Fachgebiet die mathematische Modellierung und nicht die Softwareentwicklung war.
vartec 23.03.2009 10:06
quelle