Python Programmazione - Norme / Consigli per lo sviluppo di software di livello enterprise in Python?

Question

Sono una C un po 'avanzato ++ / Java Developer che di recente si è interessata in Python e mi piace la sua tipizzazione dinamica e lo stile di codifica efficienti molto. Attualmente uso sulle mie piccole esigenze di programmazione come risolvere enigmi di programmazione e di scripting, ma io sono curioso di sapere se qualcuno là fuori ha utilizzato con successo Python in un progetto di qualità aziendale? (Preferibilmente utilizzando tecniche di programmazione moderne come OOP e qualche tipo di disegno del modello)

Se è così, La prego di spiegare perché si è scelto Python (in particolare) e ci danno alcune delle lezioni si è appreso da questo progetto ? (Sentitevi liberi di confrontare l'utilizzo di Python nel progetto vs Java o etc)

Answer 1

Sto usando Python per lo sviluppo di una complessa applicazione di sottoscrizione di assicurazioni.

Il nostro software applicativo reimballa essenzialmente il nostro modello attuariale in una forma che le aziende possono abbonarsi. Questa attività si basa sui nostri attuari e la loro profondità di pensiero. Non stiamo confezionamento di un algoritmo intelligente che è relativamente fisso. Stiamo affittando il nostro cervello attuariali ai clienti tramite un servizio web.

1. Gli attuari devono essere liberi di fare i cambiamenti mentre guadagnano più profonda comprensione dei diversi fattori che portano a reclami.

   • linguaggi statici (Java, C ++, C #) portano ai primi di lock-in a un modello di dati.

   • Python ci permette di avere un modello di dati molto flessibile. Sono liberi di aggiungere, modificare o eliminare fattori o fonti di informazione senza un sacco di costi di sviluppo e la complessità. Duck typing ci permette di introdurre nuovi pezzi senza una rielaborazione molto.

2. Il nostro software è un servizio (non un pacchetto) quindi abbiamo un problema di integrazione senza fine.

   • linguaggi statici necessitano di componenti di mappatura complessi. Spesso un qualche tipo di configurabile, mappatura XML-driven dai messaggi dei clienti alla nostra continua evoluzione delle strutture interne.

   • Python ci permette di avere le mappature come una semplice definizione di classe Python che abbiamo semplicemente tweak, collaudo e messa in produzione. Non ci sono limitazioni di questo modulo - è il codice di prima classe Python

   .

3. Dobbiamo fare estesa, a lungo in esecuzione proof-of-concept. Queste coinvolgono numerosi "what-if" con dati diversi feed e funzioni personalizzate.

   • linguaggi statici richiedono un sacco di un'attenta pianificazione e di pensare di creare ancora un altro demo, ancora un altro mapping da un altro file di fornito dal cliente alla versione corrente dei nostri modelli attuariali.

   • Python richiede molto meno pianificazione. tipizzazione Duck (e Django) cerchiamo di mettere fuori un demo senza molto dolore. Le mappature di dati sono definizioni classe Python; nostri modelli attuariali sono in uno stato abbastanza costante di flusso.

4. Il nostro modello di business è soggetto ad una certa quantità di negoziazione. Abbiamo contratti piuttosto complessi con fornitori di informazioni; questi non cambiano tutte le volte che il modello attuariale, ma i cambiamenti qui richiedono la personalizzazione.

   • linguaggi statici legano in ipotesi circa i contratti, e richiedono i disegni piuttosto complesse (o soluzioni alternative) per gestire le cerebrali scoregge delle gente d'affari che negoziano le offerte.

   • In Python, usiamo una vasta suite di test e facciamo un sacco di refactoring, come i vari termini e le condizioni contrattuali trickle down a noi.

   Ogni settimana si ottiene una domanda del tipo "Possiamo gestire una disposizione come X?" La nostra risposta standard è "assolutamente". Seguita da un'ora di refactoring per essere sicuri che potrebbe gestirlo se l'affare è stato colpito in quella forma.

5. Siamo per lo più un servizio web RESTful. Django fa un sacco di questo, fuori dalla scatola. Abbiamo dovuto scrivere alcune estensioni perché il nostro modello di sicurezza è un po 'più rigorosa rispetto a quella fornita da Django.

   • linguaggi statici non devono spedire fonte. Non ti piace il modello di sicurezza? Pagare il fornitore $$$.

   • I linguaggi dinamici devono spedire come sorgente. Nel nostro caso, passiamo il tempo a leggere la fonte di Django con attenzione per assicurarsi che il nostro modello di sicurezza è inserito perfettamente con il resto della Django. Non necessità la conformità HIPAA, ma stiamo costruendo in ogni modo possibile.

6. Usiamo i servizi web da fornitori di informazioni. urllib2 fa questo per noi bene. Siamo in grado di creare rapidamente prototipi di interfaccia.

   • Con un linguaggio statico, si dispone di API, si scrive, si corre, e si spera ha funzionato. Il ciclo di sviluppo è modificare, compilare, Build, Run, Crash, Guarda Log; e questo è solo a picco l'interfaccia ed essere sicuri di avere il protocollo, le credenziali e la configurazione right.

   • Esercitiamo l'interfaccia in Python interattivo. Dal momento che stiamo eseguendo in modo interattivo, possiamo esaminare immediatamente le risposte. Il ciclo di sviluppo è ridotto a eseguire, modificare. Siamo in grado di spike un'API di servizi web in un pomeriggio.

Answer 2

Sono stato utilizzando Python come quadro di calcolo distribuito in uno dei mondi più grandi banche. E 'stato scelto perché:

• Doveva essere estremamente veloce per lo sviluppo e la distribuzione di nuove funzionalità;
• Doveva essere facilmente integrabile con C e C ++;
• Alcune parti del codice dovevano essere scritti da persone la cui area di competenza era di modellazione, non lo sviluppo di software matematico.