Pericoli del progetto J2EE!

Nei miei vari incarichi come sviluppatore, sviluppatore senior e architetto, ho visto il buono, il brutto e il cattivo quando si tratta di progetti Java aziendali! Quando mi chiedo cosa fa sì che un progetto abbia successo e un altro fallisca, è difficile trovare la risposta perfetta, poiché il successo si rivela difficile da definire per tutti i progetti software. I progetti J2EE non fanno eccezione. Invece, i progetti riescono o falliscono a vari livelli. In questo articolo mi propongo di prendere i 10 principali pericoli che influenzano il successo di un progetto Java aziendale e mostrarli per te, il lettore.

Alcuni di questi pericoli rallentano semplicemente il progetto, alcuni sono false piste e altri ancora possono rovinare qualsiasi possibilità di successo. Tuttavia, tutti sono evitabili con una buona preparazione, conoscenza del viaggio da percorrere e guide locali che conoscono il terreno.

Questo articolo ha una struttura semplice; Tratterò ogni pericolo come segue:

  • Nome del pericolo: una riga che delinea il pericolo
  • Fase del progetto: la fase del progetto in cui si verifica il pericolo
  • Fasi del progetto interessate: in molti casi, i pericoli possono avere un effetto a catena sulle fasi successive del progetto
  • Sintomi: sintomi associati a questo pericolo
  • Soluzione: modi per evitare del tutto il pericolo e come minimizzarne gli effetti sul progetto
  • Note: punti che desidero impartire che si riferiscono al pericolo, ma non rientrano nelle categorie precedenti

Come notato sopra, esamineremo ogni pericolo nel contesto di un progetto Java aziendale, insieme alle sue fasi importanti. Le fasi del progetto riguardano:

  • Selezione del fornitore: il processo di scelta della migliore combinazione possibile di strumenti prima di iniziare il progetto J2EE, dal server delle applicazioni fino alla marca di caffè.
  • Design: tra una rigorosa metodologia a cascata e un approccio di "codificalo e guarda", si trova la mia opinione sul design: faccio abbastanza design in modo da poter muovermi comodamente nello sviluppo. Considero completa la mia fase di progettazione quando so esattamente cosa sto costruendo e come lo costruirò. Inoltre, utilizzo i modelli di progettazione per assicurarmi di aver posto tutte le giuste domande a me stesso e alla mia soluzione proposta prima di passare allo sviluppo. Tuttavia, non ho paura di programmare in questa fase; a volte è l'unico modo per rispondere a una domanda su, ad esempio, prestazioni o modularità.
  • Sviluppo: la fase del progetto in cui verrà mostrata la quantità di lavoro svolto nelle fasi precedenti. Una buona scelta di strumenti unita a un buon design non sempre significa uno sviluppo super fluido, ma sicuramente aiuta!
  • Stabilizzazione / test di carico: in questa fase, l'architetto del sistema e il project manager imporranno un blocco delle funzionalità e si concentreranno sulla qualità della costruzione, oltre a garantire che le statistiche vitali del sistema - numero di utenti simultanei, scenari di failover e così via - possono essere soddisfatte. Tuttavia, la qualità e le prestazioni non dovrebbero essere ignorate fino a questa fase. In effetti, non puoi scrivere codice lento o di scarsa qualità e lasciarlo fino alla stabilizzazione per risolverlo.
  • Live: questa non è proprio una fase del progetto, è una data scolpita nella pietra. Questa fase è tutta una questione di preparazione. È qui che i fantasmi degli errori del passato torneranno a perseguitare il tuo progetto, dal cattivo design e sviluppo a una cattiva scelta di fornitori.

La figura 1 illustra le fasi del progetto maggiormente influenzate dalle diverse cause (ed in particolare dagli effetti a catena).

Bene, allora, senza ulteriori indugi, tuffiamoci direttamente nella top 10!

Pericolo 1: non capire Java, non capire EJB, non capire J2EE

Bene, suddividerò questo in tre sottoelementi per un'analisi più semplice.

Descrizione: Non capisco Java

Fase del progetto:

Sviluppo

Fase (i) del progetto interessata:

Design, stabilizzazione, live

Caratteristiche del sistema interessate:

Manutenibilità, scalabilità, prestazioni

Sintomi:

  • Reimplementazione di funzionalità e classi già contenute nelle API principali di JDK
  • Non sapendo cosa sono alcuni o tutti i seguenti e cosa fanno (questo elenco rappresenta solo un campione di argomenti):
    • Garbage collector (treno, generazionale, incrementale, sincrono, asincrono)
    • Quando gli oggetti possono essere raccolti nella spazzatura - riferimenti penzolanti
    • Meccanismi di ereditarietà utilizzati (e relativi compromessi) in Java
    • Metodo over-riding e over-loading
    • Perché java.lang.String(sostituisci la tua classe preferita qui!) Si rivela negativo per le prestazioni
    • Semantica di riferimento pass-by di Java (rispetto alla semantica del valore pass-by in EJB)
    • Usare ==contro implementare il equals()metodo per i non primitivi
    • In che modo Java pianifica i thread su piattaforme diverse (ad esempio, preventivo o meno)
    • Thread verdi contro thread nativi
    • Hotspot (e perché le vecchie tecniche di ottimizzazione delle prestazioni negano le ottimizzazioni dell'hotspot)
    • Il JIT e quando i JIT buoni vanno male (non impostato JAVA_COMPILERe il tuo codice funziona bene, ecc.)
    • L'API delle collezioni
    • RMI

Soluzione:

Devi migliorare la tua conoscenza di Java, in particolare i suoi punti di forza e di debolezza. Java esiste ben oltre il semplice linguaggio. È altrettanto importante comprendere la piattaforma (JDK e strumenti). In concreto, dovresti ottenere la certificazione come programmatore Java se non lo sei già: rimarrai stupito di quanto non sapessi. Ancora meglio, fatelo come parte di un gruppo e spingetevi l'un l'altro. È anche più divertente in questo modo. Inoltre, crea una mailing list dedicata alla tecnologia Java e continua! (Ogni azienda con cui ho lavorato ha questi elenchi, la maggior parte dei quali è in supporto vitale a causa dell'inattività.) Impara dai tuoi sviluppatori peer: sono la tua migliore risorsa.

Appunti:

Se tu o altri membri del tuo team non comprendete il linguaggio di programmazione e la piattaforma, come potete sperare di creare un'applicazione Java aziendale di successo? I forti programmatori Java prendono EJB e J2EE come anatre nell'acqua. Al contrario, i programmatori poveri o inesperti costruiranno applicazioni J2EE di scarsa qualità.

Descrizione: Non capisco EJB

Fase del progetto:

Design

Fase (i) del progetto interessata:

Sviluppo, stabilizzazione

Caratteristiche del sistema interessate:

Manutenzione

Sintomi:

  • EJB che funzionano quando vengono chiamati per la prima volta ma mai in seguito (specialmente i bean di sessione senza stato che vengono restituiti al pool pronto)
  • EJB non riutilizzabili
  • Non sapere di cosa è responsabile lo sviluppatore, rispetto a ciò che fornisce il contenitore
  • EJB che non corrispondono alla specifica (attivazione di thread, caricamento di librerie native, tentativo di eseguire operazioni di I / O e così via)

Soluzione:

Per migliorare la tua conoscenza EJB, prenditi un fine settimana e leggi le specifiche EJB (la versione 1.1 è lunga 314 pagine). Quindi leggi la specifica 2.0 (524 pagine!) Per avere un'idea di ciò che la specifica 1.1 non ha affrontato e dove ti porterà la specifica 2.0. Concentrati sulle parti della specifica che dicono a te, sviluppatore dell'applicazione, quali sono le azioni legali in un EJB. Le sezioni 18.1 e 18.2 sono buoni punti di partenza.

Appunti:

Non guardare il mondo EJB attraverso gli occhi del tuo venditore. Assicurati di conoscere la differenza tra le specifiche alla base del modello EJB e una loro particolare interpretazione. Ciò garantirà anche la possibilità di trasferire le proprie competenze ad altri fornitori (o versioni) secondo necessità.

Descrizione: Non capisco J2EE

Fase del progetto:

Design

Fase (i) del progetto interessata:

Sviluppo

Caratteristiche del sistema interessate:

Manutenzione, scalabilità, prestazioni

Sintomi:

  • Il design "Tutto è un EJB"
  • Gestione manuale delle transazioni invece di utilizzare i meccanismi forniti dal contenitore
  • Implementazioni di sicurezza personalizzate: la piattaforma J2EE ha probabilmente l'architettura di sicurezza più completa e integrata nell'informatica aziendale, dalla presentazione fino al back-end; raramente viene utilizzato al massimo delle sue capacità

Soluzione:

Scopri i componenti chiave di J2EE e i vantaggi e gli svantaggi che ogni componente porta in tavola. Copri ogni servizio a turno; la conoscenza qui è uguale al potere.

Appunti:

Solo la conoscenza può risolvere questi problemi. I buoni sviluppatori Java sono buoni sviluppatori EJB, che a loro volta sono nella posizione ideale per diventare guru J2EE. Maggiore è la conoscenza di Java e J2EE, migliore sarà la progettazione e l'implementazione. Le cose inizieranno a sistemarsi per te in fase di progettazione.

Pericolo 2: Over-engineering (su EJB o non su EJB)

Fase del progetto:

Design

Fase (i) del progetto interessata:

Sviluppo

Caratteristiche del sistema interessate:

Manutenzione, scalabilità, prestazioni

Sintomi:

  • EJB sovradimensionati
  • Sviluppatori che non sono in grado di spiegare cosa fanno i propri bean e le relazioni tra loro
  • EJB, componenti o servizi non riutilizzabili quando dovrebbero essere
  • EJB che iniziano nuove transazioni quando verrà eseguita una transazione esistente
  • Livelli di isolamento dei dati impostati troppo alti (nel tentativo di essere sicuri)

Soluzione:

La soluzione per l'over-engineering deriva direttamente dalla metodologia di programmazione estrema (XP): progetta e codifica il minimo indispensabile per soddisfare i requisiti dello scoping, niente di più. Sebbene sia necessario essere consapevoli dei requisiti futuri, ad esempio i requisiti di carico medio futuri o il comportamento del sistema nei periodi di caricamento di punta, non provare a indovinare come dovrà essere il sistema in futuro. Inoltre, la piattaforma J2EE definisce caratteristiche come scalabilità e failover come attività che l'infrastruttura del server dovrebbe gestire per te.

Con sistemi minimi, composti da piccoli componenti progettati per fare una cosa e farla bene, il livello di riutilizzo migliora, così come la stabilità del sistema. Inoltre, la manutenibilità del tuo sistema si rafforza e le esigenze future possono essere aggiunte molto più facilmente.

Appunti:

Oltre alle soluzioni sopra elencate, utilizza modelli di progettazione: migliorano notevolmente la progettazione del sistema. Il modello EJB stesso utilizza ampiamente i design pattern. Ad esempio, il file

Home

l'interfaccia di ogni EJB è un esempio di un pattern Finder e Factory. L'interfaccia remota di un bean funge da proxy per l'effettiva implementazione del bean ed è fondamentale per la capacità del container di intercettare le chiamate e fornire servizi come il bilanciamento del carico trasparente. Ignora il valore dei modelli di design a tuo rischio e pericolo.

Un altro pericolo da cui metto continuamente in guardia: usare EJB per il gusto di farlo. Non solo alcune parti dell'applicazione potrebbero essere modellate come EJB quando non dovrebbero, l' intera applicazione potrebbe utilizzare EJB senza alcun guadagno misurabile. Questa è un'ingegneria eccessiva portata agli estremi, ma ho visto servlet perfettamente funzionanti e applicazioni JavaBean strappate, riprogettate e implementate utilizzando EJB per nessuna buona ragione tecnica.

Pericolo 3: non separare la logica di presentazione dalla logica di business

Fase del progetto:

Design

Fase (i) del progetto interessata:

Sviluppo

Caratteristiche del sistema interessate:

Manutenibilità, estensibilità, prestazioni

Sintomi:

  • JSP grandi e ingombranti
  • Ti ritrovi a modificare i JSP quando la logica aziendale cambia
  • Una modifica nei requisiti di visualizzazione obbliga a modificare e ridistribuire EJB e altri componenti di backend

Soluzione:

La piattaforma J2EE offre l'opportunità di separare la logica di presentazione dalla navigazione e dal controllo e infine dalla logica di business. Si chiama architettura Model 2 (vedi Risorse per un buon articolo). Se sei già caduto in questa trappola, è necessaria una forte dose di refactoring. Dovresti almeno avere sezioni verticali sottili che sono per la maggior parte autonome (ovvero, il modo in cui ordino un widget è una sezione separata da come cambio il mio nome utente o la password). Usa questa organizzazione implicita del tuo sistema per eseguire il refactoring in più fasi.

Appunti:

L'utilizzo di un design coerente in combinazione con un framework dell'interfaccia utente (taglib per esempio) contribuirà anche a garantire di evitare problemi di separazione logica nel progetto. Non preoccuparti di creare un altro framework GUI per le tue esigenze, ci sono troppe buone implementazioni prontamente disponibili. Valuta ciascuno a turno e adotta il framework più adatto alle tue esigenze.

Pericolo 4: non distribuire dove si sviluppa

Fase del progetto:

Sviluppo

Fase (i) del progetto interessata:

Stabilizzazione, parallela, live

Caratteristiche del sistema interessate:

La tua sanità mentale

Sintomi:

  • Transizioni di più giorni o di una settimana a sistemi live
  • Il rischio connesso alla messa in servizio è notevole, con molte incognite e scenari di utilizzo principali non testati
  • I dati nei sistemi live non sono gli stessi dei dati nelle configurazioni di sviluppo o stabilizzazione
  • Impossibilità di eseguire build sui computer degli sviluppatori
  • Il comportamento dell'applicazione non è lo stesso negli ambienti di sviluppo, stabilizzazione e produzione

Soluzione:

La soluzione a Danger 4 inizia con la duplicazione fedele dell'ambiente di produzione nell'ambiente di sviluppo. Sviluppa esattamente la stessa configurazione su cui intendi andare a vivere: non sviluppare su JDK 1.3 e Red Hat Linux quando prevedi di andare in diretta su JDK 1.2.2 e Solaris 7. Inoltre, non sviluppare su un server delle applicazioni e andare in diretta su un altro. Inoltre, ottieni un'istantanea dei dati dal database di produzione e usala per i test, non fare affidamento su dati creati artificialmente. Se i dati di produzione sono sensibili, desensibilizzarli e caricarli. I dati di produzione imprevisti si interromperanno:

  • Regole di convalida dei dati
  • Comportamento del sistema testato
  • Contratti tra componenti del sistema (in particolare EJB-EJB e EJB-database)

Peggio ancora, ognuno di questi si tradurrà in eccezioni, puntatori nulli e comportamenti che non hai mai visto prima.

Appunti:

Gli sviluppatori spesso lasciano la sicurezza fino alla stabilizzazione ("Sì, gli schermi funzionano, ora aggiungiamo le cose di convalida dell'utente."). Evita questa trappola dedicando allo stesso tempo all'implementazione della sicurezza la stessa quantità di tempo che dedichi alla logica aziendale.