Un approccio aggiornabile per progettare un sistema di applicazioni Web

Question

Molte persone hanno startup online nella propria testa che potrebbero potenzialmente attirare milioni di persone, ma il più delle volte si avrà solo un budget minimo (tempo e risorse) da cui partire per cui si desidera avere ha consegnato entro un anno. Poco dopo il lancio, si è tenuti a eseguire una o una serie di aggiornamenti che possono includere: rifattore del codice a basi più recenti, aggiunta di gerarchie (i) in architettura software o ristrutturazione (s). Questo ciclo di aggiornamento/refactor continua come:

• Nuove funzionalità disponibili nella versione più recente della/e lingua/e struttura/i che si utilizzano.
• Disponibilità di nuovi componenti/framework/plug-in che possono potenzialmente migliorare il prodotto.
• Il requisito ha cambiato la sua direzione, il prodotto esistente non è stato progettato per far fronte alle nuove esigenze.

Con sopra come prerequisito, voglio prendere questa discussione seria e individuare l'essenza di una soluzione aggiornabile per un'applicazione web. Nella discussione si può parlare di eventuali fasi di sviluppo (iniziale, aggiornamento presto, upgardes incrementali) e coprire uno dei più dei seguenti elementi:

• Scelta della lingua (s) per un'applicazione web.
• Decisione per l'utilizzo di un framework o no? (Considerare l'overhead)
• Scelta del DBMS e del suo design
• Scelta dell'hardware (s) e configurazioni?
• strategia ai continui cambiamenti nei requisiti (che può essere una naturale applicazione web)
• Strategia/decisione verso riprogettazione totale

Answer 1

soluzione web della nostra azienda è il suo quarto importante generazione, si è notevolmente evoluto nel corso degli ultimi 8 anni. La generazione più recente ha introdotto una vasta gamma di costrutti per aiutare esattamente con questo compito poiché stava diventando poco pratico aggiornare la generazione precedente in base alle nuove richieste dei clienti. Così, nel 2009 ho passato un po 'di tempo a pensare esattamente a questo problema.

L'unica cosa più preziosa che è possibile fare è impiegare un approccio Agile per creare software. In particolare, è necessario mantenere un ambiente in cui una nuova build può essere (ed è) creata quotidianamente. Mentre le build giornaliere sono solo un aspetto di Agile, questa è la pratica più importante nell'affrontare la tua domanda. Sebbene ciò non sia la stessa cosa della aggiornabilità, di per sé, introduce comunque una disciplina nel processo che aiuta a ridurre la possibilità che la base di codice diventi ingombrante (o che diventi un Architect Astronaut).

Per quanto riguarda framework e linguaggi vanno, ci sono due esigenze principali: che il quadro sia longevo e stabile e che l'ambiente supporta un Separation of Concerns. ASP.NET ha funzionato bene per me in questo senso: si è evoluto in modo razionale e senza discontinuità che invalida il vecchio codice. Io uso un Business Logic Layer separato per gestire SoC ma ASP.NET ora supporta anche lo sviluppo MVC.Al contrario, dopo pochi mesi mi è dispiaciuto disobbedire a PHP perché sembrava solo incoraggiare pratiche disordinate che avrebbero messo in pericolo futuri aggiornamenti.

Rispetto allo Selezione DBMS, qualsiasi RDMS moderno (SQL Server, MySQL, Oracle) può essere utile. Ecco però la chiave: è necessario mantenere gli script DDL per la gestione degli aggiornamenti. È solo un fatto della vita. Quindi, come si fa a rendere questo un processo trattabile? Il singolo strumento più prezioso di qualsiasi sviluppatore di terze parti è la mia copia di SQL Compare da Red Gate. Questo processo era un completo incubo e un significativo ostacolo alla mia capacità di evolvere il mio codice fino a quando ho trovato questo strumento. Pertanto, la raccomandazione generica consiste nell'utilizzare un database per il quale esiste uno strumento per confrontare le strutture del database. SQL Server è solo molto fortunato a questo proposito.

L'hardware è quasi un non importa. È sempre possibile passare al nuovo hardware purché il processo di sviluppo includa un ragionevole processo di generazione del rilascio.

Strategia per modifiche costanti dei requisiti. Ancora, vedi Agile. Ti incoraggerei a non pensarci nemmeno più come "requisiti" - nel senso tradizionale di un grande documento pieno di specifiche. Agile cambia questo in modi importanti. Non tengo un documento dei requisiti, tranne quando si lavora su un contratto per un cliente esterno, pagante, in modo tale da poter essere sicuro della fatturazione appropriata e prevenire il creep della funzionalità. A questo punto, il nostro processo interno è così rapido e fluido che i report del nostro software di gestione delle richieste/bug (FogBugz se vuoi sapere) serve come documentazione per documentare una nuova release per il marketing.

La strategia/decisione per riprogettazione totale è: no. Se si inserisce un ragionevole grado di giudizio nel processo , si utilizzerà, si scelgono strumenti mainstream e si impone una separazione delle preoccupazioni, quindi niente a parte un abbandono completo di HTTP e RDBMS dovrebbe causare una riprogettazione totale.

Se siete abbastanza agile che nulla può cambiamento, si è improbabile che siano sempre in una posizione in cui tutto must cambiamento.

Answer 2

per ottenere la palla a rotazione, avrei pensato un linguaggio/framework che supporta il concetto di dipendenza da iniezione (o Inversion of Control come sembra essere chiamato in questi giorni) sarebbe in cima alla lista.

Answer 3

Scoprirete che la tecnologia RDBMS non è facilmente scalabile. Tutti i fornitori ti diranno altrimenti quando proverai più server e il bilanciamento del carico mostrerà le limitazioni inerenti. Tutto il resto può essere rinforzato con "ferro più grande" e potrebbe essere un codice più efficiente, ma i database non possono essere suddivisi e distribuiti facilmente.

Speriamo che le applicazioni Web guidino l'innovazione nelle tecnologie di database e ci aiutino ad uscire dall'arcaica mentalità del modello relazionale. È in ritardo da tempo.

Mi raccomando di prestare molta attenzione a questo collegamento debole fin dall'inizio.