Ri-scrivere una grande applicazione web - alternative a LAMP

Congratulazioni, hai intrapreso il singolo tipo di progetto più rischioso possibile.

Completa riscrittura, secondo sistema, problemi irrisolti della gente, mancanza di direzione tecnica, massima disponibilità a renderlo grande - nessuna di queste è una bandiera rossa che farebbe sballare la gente dall'altra parte. L'unico vantaggio è che sarebbe difficile scegliere una lingua peggiore di quella che hai ora.

Per prima cosa dobbiamo impostare un'aspettativa di base con alcune cifre approssimative. In media, un "progetto di sviluppo del software aziendale" al momento della consegna richiede il 200% del tempo stimato, il 200% del budget stimato e fornisce il 50% delle funzionalità inizialmente promesse. Quelli non sono i fallimenti - quelli sono i successi. Il fallimento è estremamente comune e sembra lo stesso del successo fino a quando l'organizzazione non prende la spina perché non c'è un risultato finale funzionante. Questo è nella media. Dato l'elenco delle bandiere rosse che mi sono saltate addosso, l'aspettativa di base dovrebbe essere che sei a grave rischio di iniziare al di sotto della media.

Vorrei che stavo esagerando. Sfortunatamente non lo sono.

Avrai bisogno di iniziare a contrastare ciò con alcuni aspetti positivi.

Prima di tutto la piattaforma. Ci sono un sacco di piattaforme accettabili che andranno bene per te. Se vuoi allontanarti da PHP (io sono di parte, lo farei), ti consiglio vivamente di intraprendere programmi pilota in diversi ambienti per vedere cosa funziona per te. Poi vai con quello che ha avuto la migliore accoglienza tra le parti interessate importanti (compresi gli sviluppatori!). Ciò che sceglierai non sarà più importante del fatto che le parti interessate siano felici della scelta.

In secondo luogo il set di funzionalità. Stai costruendo un secondo sistema. La tua priorità principale deve essere quella di evitare la sindrome del secondo sistema. Tutti sanno cosa non gli piace nel sistema attuale. Tutti hanno le loro liste "I wish" e "what if". Individualmente quelli sembrano grandi, e sono informati dall'esperienza con il primo sistema. Ma quando li ammucchiano tutti nel secondo sistema, fallirà. Quindi qualcuno deve essere sul posto per dire no per presentare richieste e deve essere spietato. (Leggi Il mitico Man-Month per un libro classico ispirato da un architetto di un secondo sistema che cerca di capire cosa è andato storto.) Come regola generale, su un primo sistema l'inesperienza mostra e un terzo sistema generalmente va bene, ma un secondo sistema è il più probabile a fallire.

Terza stima del software. Corri, non camminare, per raccogliere Stima del software: Demistificare la Black Art di Steve McConnell e migliorare la capacità della tua organizzazione di produrre stime accurate. Pochissime organizzazioni sono brave a farlo, e migliorare su questo è una priorità assoluta prima di provare a intraprendere qualsiasi progetto di grandi dimensioni.

In quarto luogo, evita l'etichetta "impresa". In generale, software aziendale significa software che viene venduto a dirigenti che sono disconnessi dal lavoro effettivo. Pertanto possiede un eccellente marketing e solo occasionalmente merito tecnico. Oracle vorrebbe ottenere il tuo business. Ti farebbero sicuramente pagare il miglior dollaro. Ma a meno che tu non abbia qualcosa di specifico da ottenere da loro, in realtà non hanno molto da offrire tecnicamente che PostgreSQL non abbia. E, parlando personalmente, il database più grande che ho visto era un database MySQL su Google. Se Google può renderlo scalabile in base alle loro esigenze, può ridimensionare il tuo. (OK, così Google è stato in grado di eseguire il backup con quello che era effettivamente un disco RAM costruito su una serie ridondante di computer economici e Google non utilizza MySQL per la maggior parte delle loro esigenze di archiviazione dei dati.)

Buona fortuna. Spero di averti spaventato. Dovresti essere spaventato. Questo è sicuramente un progetto ad alto rischio. Ma non è impossibile - solo molto, molto rischioso. Un fallimento nell'accettare, comprendere e attenuare attivamente tali rischi è una garanzia di fallimento.

Chiediti perché vuoi passare da LAMP; è a causa di carenze nello stack o carenze nelle pratiche e nella progettazione dell'applicazione originale? Il codice errato può essere scritto in qualsiasi ambiente, dall'assemblatore alle architetture più astronautiche.

Attualmente, la mia azienda gestisce un set altamente scalabile di servizi Web su Linux, nginx, MySQL e Python; il più grande ostacolo è stato il problema del codice legacy scritto male, non la scalabilità di nessuno degli aspetti di questo stack. Potresti fare la stessa cosa in Java o in .NET; non importa, a patto che tu abbia l'esperienza in quello stack per renderlo efficace.

Sì, hai un problema, ma la soluzione non è riscrivere!

Ora, soluzioni per risolvere il problema in modo costruttivo. È necessario iniziare a tagliare i livelli del vecchio sistema e sostituirli, questo è chiaro, e ciò significa che è necessario mantenere la compatibilità con ciò che già si possiede. Quindi suona come servizi web (che puoi scrivere in qualsiasi lingua tu voglia, anche C ++).

Quindi, identificare quali parti del sistema possono essere sostituite con un servizio web totalmente indipendente e iniziare a ridurre la complessità del sistema principale. Quindi, una volta ridotto a una dimensione più gestibile, è possibile iniziare a rifattorizzare (scusate l'uso di tale parola cliché) il codebase per sbarazzarsi di qualsiasi irrilevante cruft e sostituirlo con qualcosa di un po 'più ben progettato. Spero che tu possa vedere come più modifiche, magari sostituendo parti più grandi del sistema principale con un codice meglio scritto, ti aiuterebbero di più.

E una volta che hai fatto ciò, è probabile che avrai un sistema manutenibile ed estensibile che è una soluzione.

Il trucco è: 1. componenti indipendenti, ben progettati per una specifica e documentati su come usarli e cosa fanno. 2. rielaborare parte del codice esistente in modo che funzioni sempre allo stesso modo, ma meglio. Questo significa che dovrai documentare cosa dovrebbe fare. 3. Documentatelo ancora un po '- non lo dico a causa della gradita documentazione, ma perché sembra che ci sia stata una generale mancanza di rigore nel modo in cui il sistema è stato lavorato in passato. Inserisci un po 'di codice, modificalo ancora e finisci con un casino. Forza documentazione e specifiche e avrai maggiori possibilità di tenere le cose in ordine.

Non vedo alcun percorso da questo che non sia pieno di errori - uno dei più grandi progetti dello stack LAMP è che PHP ha un lotto di librerie e se il codice è già in PHP sei certo che PHP supporti tutto ciò che devi fare.

Puoi scrivere codice non valido e non gestibile in qualsiasi lingua, ma le tue scelte per il web "Enterprise" sono fondamentalmente Python, Ruby, C #, Java o PHP. L'unico vantaggio di abbandonare PHP potrebbe essere il passaggio a un linguaggio tipizzato staticamente - questo è un argomento su cui potrei essere d'accordo, ma per qualsiasi altra cosa non penso ci sia una ragione valida per abbandonare PHP come lingua.

Prima di tutto, qualsiasi utilizzo di C ++ per lo sviluppo web è così incredibilmente di nicchia da non meritare nemmeno una considerazione. Se stai chiedendo "quale lingua dovremmo usare?", Allora posso garantirti al 100% che la risposta è non "C ++". A parte ciò, come hanno detto altri, ci sono opzioni:

Direi che di gran lunga le due scelte più comuni per le applicazioni web enterprise-y sono Java (e uno dei suoi framework) e C # /. NET (probabilmente ASP.NET MVC per uno sviluppo greenfield, ASP.NET Web Moduli per tutto ciò che è stato in produzione un po '). Trovo che la decisione tra questi due sia spesso in gran parte determinata dal sistema operativo preferito del server. Java per Unix, .NET per Windows. Puoi fare Java su Windows ma spesso ti rende triste. Si può presumibilmente eseguire .NET su Unix utilizzando Mono, ma mi raccomando di non scommettere la tua attività su di esso.

Altri hanno menzionato Python e Ruby. La mia esperienza personale con questi due è poca e nessuna. La mia comprensione è che esistono quadri di qualità per entrambi. Inoltre, la mia comprensione è che non sono particolarmente visti alla fine dello spettro aziendale.

Coloro che hanno liquidato PHP fuori mano sono già stati accusati di parzialità. Anch'io sono di parte - tiro fuori di mano PHP e penso che dovresti farlo anche tu. Hai già creato un tipico Trainwreck PHP, non esci e costruisci un altro.

Detto questo , descrivi "un'applicazione web molto grande". Lei parla di "possibilmente centinaia" di programmatori che hanno immerso i loro remi in esso per oltre 10 anni. Presumo che tu abbia un bel numero di programmatori che lavorano lì. E assumerò anche (forse in modo impreciso) che questa grande applicazione PHP è la principale o unica cosa su cui stanno lavorando, e quindi molti o molti di questi programmatori non hanno alcuna esperienza significativa su larga scala con qualsiasi altra cosa di PHP.

Non costruiranno un buon "secondo sistema" in nessuna altra piattaforma.

Se hai intenzione di fare questa cosa, è necessario che sia avviata da sviluppatori esperti che vivono e respirano la piattaforma che scegli di utilizzare. Ho detto sopra che la mia esperienza personale con Python e Ruby è poca e nessuna. Potrei facilmente impararli e sono fiducioso di poter scrivere un buon codice con loro. Ma se provassi a utilizzare un sistema su larga scala come esperienza di apprendimento, sono certo che produrrei un treno che non ha impiegato 10 anni per sembrare cattivo come il sistema che speri di sostituire.

In definitiva, se la tua azienda può permettersi di spendere tempo, sforzi e denaro su un secondo sistema (e riscrivere un sistema di 10 anni sarà un lotto di tempo, impegno e denaro) , avrai bisogno di spendere un bel po 'di persone assoldate che hanno una vasta esperienza attuale nella piattaforma che selezioni.

Secondo Joel Spolsky - l'unico errore strategico peggiore che qualsiasi azienda di software possa fare: hanno deciso di riscrivere il codice da zero.

Dici:

poorly written due to a large number of patches and possible hundreds of programmers

Questa non è la ragione. Joel spiega tutto nel seguente articolo link

Leggilo e poi pensa a come puoi migliorare ciò che hai.