Quali considerazioni dovrebbero essere fatte a favore e contro i "super" siti?

Cattiva idea

Questa reazione si basa sulle seguenti ipotesi:

1. Ci sono molte applicazioni abbastanza disparate che vengono omogeneizzate
2. Ci sono molti team che lavorano sulle diverse applicazioni
3. Non esiste un architetto software rispettato e autorevole che gestisca attivamente le applicazioni

Che cosa succederà se prosegui

Molto probabilmente ci sarà uno sforzo consolidato iniziale per riunire tutto sotto un unico approccio progettuale. Questo mostrerà l'enorme sforzo richiesto per far sì che tutto funzioni allo stesso modo e potrebbe diventare inutilizzabile.

Se preme, allora sarà necessario un qualche tipo di archivio centralizzato contenente i dati di configurazione (ad esempio accesso di sicurezza, livelli di registrazione, ecc.) a quel punto qualcuno indicherà l'ovvio e dirà

"Hey, why don't we just retrofit this externalised configuration approach to the old applications, it'll be much quicker?"

e un attimo dopo qualcun altro si stuzzicherà con

"And, since we're refactoring anyway, why don't we just apply a design standard for each of the application domains - web processing looks like this, business rule processing like this and database access like, er this."

fino alla fine

"Oh, and there's a lot of common code here why not put together some easily shared libraries. We'll probably need some kind of integration build run at regular intervals, say, every night."

A quel punto tutti tirano un sospiro di sollievo che non è stato costruito un enorme monolite.

Abbiamo lavorato su questo nella mia azienda. Penso che sia possibile e ci sono evidenti benefici (li hai citati), tuttavia, questo sarà probabilmente un progetto da 5 a 7 anni al minimo, e richiede fondamentalmente tutto da riscrivere. Se riesci a ottenere l'approvazione per qualcosa del genere, allora direi di andare a farlo. In caso contrario, preparati per una marcia della morte da incubo.

Google lo fa, quindi è possibile . p>

Questo link a BTW è una presentazione interessante di un googler su come gestiscono il loro codice base, l'integrazione continua, i test ecc.

Senza un altrettanto strong impegno per gli strumenti, tuttavia, come ha fatto Google, è probabile che tu abbia un mondo di ferite.

La domanda chiave qui è perché ? Perché il senior management vuole farlo? Quali risparmi, leva o altri vantaggi sperano di ottenere?

Se riesci a indirizzare abbastanza di tali problemi in modo da raggiungere i loro obiettivi, puoi evitare il singolo codice base che ti riguarda, pur continuando a dare loro lo stesso risultato efficace.

Stiamo attraversando un processo simile. Abbiamo avuto un prodotto che è stato in giro un po '. L'anno scorso abbiamo introdotto un altro prodotto che è il 95% uguale al primo, con il 5% di differenze talvolta sottili ma significative, con le differenze da sviluppare e mantenere da un team separato.

Quando abbiamo iniziato a lavorare sul nuovo prodotto, il vecchio team continuava a fare cambiamenti che ci hanno condizionato negativamente in quel 5%, perché non capivano il nuovo prodotto. Abbiamo quindi completamente biforcato quel 5% di codice, che ci ha permesso di terminare la prima versione in tempo.

Poi sono iniziati altri interventi di manutenzione, e abbiamo scoperto che spesso stavamo eseguendo modifiche quasi identiche in un codice quasi identico. Il vecchio team ha anche una migliore comprensione del nuovo prodotto ora, quindi stiamo gradualmente reintegrando ciò che abbiamo forgiato e trovando modi architettonici più efficienti per esprimere le differenze.

Quindi quando dici che le strutture di dati sono diverse e le basi di codice complessive sono disparate, la domanda che vorrei porre è se devono essere in quel modo o è proprio come si sono evoluti a causa dell'opportunità del momento. Ovviamente è necessario tenere conto delle diverse regole e requisiti aziendali, ma la chiave è isolare tali differenze in un modulo il più piccolo possibile. Se ti capiti spesso di implementare la stessa identica funzionalità per più clienti in modi leggermente diversi per basi di codice diverse, il consolidamento può davvero aiutare, e sospetto che sia il caso o la gestione probabilmente non lo proporrà.

Probabilmente non sarai in grado di consolidare numerose applicazioni nello stesso codice base perché ci vorrà un po 'di sforzo e per i vecchi programmi trascurati questo potrebbe essere molto più lavoro di quanto inizialmente previsto.

Detto questo, non c'è niente di male nell'avere tutte le tue applicazioni nello stesso repository , dove ogni applicazione ha un'area separata. Questo ti consente di es. avere una documentazione online generata per l'intera base di codice in una singola visione coerente, che generalmente è una buona cosa che si desidera più visibilità possibile.

Coloro che decidono di farlo, dovrebbero considerare seriamente perché vogliono farlo e considerare quanto lavoro vogliono spendere per arrivarci.

Se c'è una sola cosa che rende lo sviluppo delle imprese così inefficiente e costoso è l'illusione che sia possibile creare un singolo sistema che faccia tutto. Se avessi un singolo product owner che comprende tutti i dettagli del sistema e può prendere tutte le decisioni senza aver bisogno di una settimana di incontri, potrebbe funzionare, ma non l'ho mai visto accadere.

In generale starai meglio se lo tratti più come lo sviluppo per Internet: crea semplicemente la tua app, ammettendo che in pratica non hai il controllo di nulla al di fuori del tuo codice. Puoi ottenere praticamente tutta la coerenza che vorresti con OAuth e una semplice API per le impostazioni utente e un po 'di CSS condiviso.

Questo è abbastanza simile all'intenzione originale di SOA, ma se lo chiami ti ritroverai con un diverso tipo di sistema grande, che funziona a malapena e cerca di fare tutto.

Il mio primo pensiero è che questa sarebbe una PITA totale per le versioni.

La suddivisione in parti gestibili di funzionalità è molto più ragionevole, se non altro per evitare tutti i livelli di gestione e approvazione.

Scomporre materiale comune in componenti / servizi e standardizzare in questo modo sarebbe molto più facile da IMHO.

Puoi affrontarlo in modo diverso, utilizzando una tecnologia di integrazione come Deliverance per simulare tutte le tue applicazioni web allo stesso modo. Fondamentalmente, ogni applicazione è ancora separata; Deliverance utilizza le regole XSLT per calzare il proprio output in un modello HTML statico che si progetta. Ciò consente di applicare un tema HTML / CSS statico relativamente semplice a un'intera suite di applicazioni con un minimo di difficoltà.