Programmering

J2EE-projektets farer!

I mine forskellige ansættelsesperioder som udvikler, seniorudvikler og arkitekt har jeg set det gode, det dårlige og det grimme, når det kommer til Java-projekter til virksomheder! Når jeg spørger mig selv, hvad der får et projekt til at lykkes og et andet mislykkes, er det svært at komme med det perfekte svar, da succes viser sig at være vanskelig at definere for alle softwareprojekter. J2EE-projekter er ingen undtagelse. I stedet lykkes eller mislykkes projekter i varierende grad. I denne artikel tilstræber jeg at tage de top 10 farer, der påvirker succesen med et enterprise Java-projekt, og fremvise dem for dig, læseren.

Nogle af disse farer sænker simpelthen projektet, nogle er falske stier, og stadig andre kan direkte ødelægge enhver chance for succes. Imidlertid er alle undgåelige med god forberedelse, viden om rejsen fremad og lokale guider, der kender terrænet.

Denne artikel er enkel i struktur; Jeg vil dække hver fare som følger:

  • Fare navn: One-liner, der beskriver faren
  • Projektfase: Projektfasen, hvor faren opstår
  • Berørt (e) projektfase (r): I mange tilfælde kan farer påvirke senere projektfaser
  • Symptomer: Symptomer forbundet med denne fare
  • Opløsning: Måder at undgå faren helt, og hvordan man minimerer dens virkninger på dit projekt
  • Bemærkninger: Point, jeg ønsker at give, der vedrører faren, men ikke passer ind i de tidligere kategorier

Som nævnt ovenfor undersøger vi hver fare i forbindelse med et Java-projekt til virksomheder sammen med dets vigtige faser. Projektets faser dækker:

  • Valg af leverandør: Processen med at vælge den bedst mulige blanding af værktøjer, før du starter dit J2EE-projekt - fra applikationsserveren helt ned til dit kaffemærke.
  • Design: Ind imellem en streng vandfaldsmetode og en tilgang til "kode det og se" ligger min opfattelse af design: Jeg laver nok design, så jeg kan bevæge mig komfortabelt i udvikling. Jeg betragter min designfase som afsluttet, når jeg ved nøjagtigt, hvad jeg bygger, og hvordan jeg skal bygge den. Desuden bruger jeg designskabeloner til at sikre, at jeg har stillet alle de rigtige spørgsmål om mig selv og min foreslåede løsning, inden jeg går videre til udvikling. Jeg er dog ikke bange for at kode i denne fase; nogle gange er det den eneste måde at besvare et spørgsmål om siger, ydeevne eller modularitet.
  • Udvikling: Projektfasen, hvor mængden af ​​arbejde, der er udført i tidligere faser, viser. Et godt valg af værktøjer kombineret med et godt design betyder ikke altid en superglad udvikling, men det hjælper bestemt!
  • Stabilisering / belastningstest: I denne fase vil systemarkitekten og projektlederen pålægge en funktionsfrysning og fokus på byggekvalitet samt sikre, at systemets vitale statistikker - antal samtidige brugere, failover-scenarier osv. - kan opfyldes. Kvalitet og ydeevne bør dog ikke ignoreres før denne fase. Faktisk kan du ikke skrive dårlig kvalitet eller langsom kode og lade den være, indtil den er stabiliseret.
  • Direkte: Dette er ikke rigtig en projektfase, det er en dato, der er sat i sten. Denne fase handler om forberedelse. Det er her spøgelserne fra tidligere fejl kommer tilbage for at hjemsøge dit projekt, fra dårlig design og udvikling til et dårligt valg af leverandører.

Figur 1 illustrerer de projektfaser, der er mest berørt af de forskellige årsager (og især knock-on-effekterne).

Nå så, uden videre, lad os dykke lige ind i top 10!

Fare 1: Ikke forstå Java, ikke forstå EJB, ikke forstå J2EE

Det skal jeg opdele i tre underelementer for lettere analyse.

Beskrivelse: Forstår ikke Java

Projektfase:

Udvikling

Berørt (e) projektfase (r):

Design, stabilisering, live

Berørte systemegenskaber:

Vedligeholdelse, skalerbarhed, ydeevne

Symptomer:

  • Genimplementering af funktionalitet og klasser, der allerede er indeholdt i JDK-kerne-API'erne
  • Ved ikke at vide, hvad et eller alle af følgende er, og hvad de gør (denne liste repræsenterer kun et eksempel på emner):
    • Affaldssamler (tog, generation, trinvis, synkron, asynkron)
    • Når genstande kan indsamles skrald - dinglende referencer
    • Arvsmekanismer anvendt (og deres kompromiser) i Java
    • Metodeoverkørsel og overbelastning
    • Hvorfor java.lang.Streng (erstat din favoritklasse her!) viser sig dårligt for ydeevnen
    • Pass-by reference semantik af Java (versus pass-by værdi semantik i EJB)
    • Ved brug af == versus implementering af lige med() metode til ikke-primitive
    • Hvordan Java planlægger tråde på forskellige platforme (for eksempel forebyggende eller ej)
    • Grønne tråde versus indfødte tråde
    • Hotspot (og hvorfor gamle præstationsjusteringsteknikker negerer Hotspot-optimeringer)
    • JIT'en og når gode JIT'er går dårligt (frakoblet JAVA_COMPILER og din kode kører fint osv.)
    • Samlingens API
    • RMI

Opløsning:

Du skal forbedre din viden om Java, især dens styrker og svagheder. Java eksisterer langt ud over blot sproget. Det er lige så vigtigt at forstå platformen (JDK og værktøjer). Konkret skal du blive certificeret som en Java-programmør, hvis du ikke allerede er det - du vil blive overrasket over, hvor meget du ikke vidste. Endnu bedre, gør det som en del af en gruppe og skub hinanden. Det er også sjovere på denne måde. Opret desuden en mailingliste, der er afsat til Java-teknologi, og hold den i gang! (Alle virksomheder, jeg har arbejdet med, har disse lister, hvoraf de fleste er på livsstøtte på grund af inaktivitet.) Lær af dine peer-udviklere - de er din bedste ressource.

Bemærkninger:

Hvis du eller andre medlemmer af dit team ikke forstår programmeringssproget og platformen, hvordan kan du så håbe på at opbygge en vellykket Java-applikation? Stærke Java-programmører tager til EJB og J2EE som ænder til vand. I modsætning hertil konstruerer dårlige eller uerfarne programmører J2EE-applikationer af dårlig kvalitet.

Beskrivelse: Forstår ikke EJB

Projektfase:

Design

Berørt (e) projektfase (r):

Udvikling, stabilisering

Berørte systemegenskaber:

Vedligeholdelse

Symptomer:

  • EJB'er, der fungerer, når de først kaldes, men aldrig derefter (især statsløse sessionbønner, der returneres til den klar pool)
  • Ikke-genanvendelige EJB'er
  • Ikke at vide for hvad udvikleren er ansvarlig sammenlignet med hvad containeren leverer
  • EJB'er, der ikke svarer til specifikationen (brandtråde, indlæser indfødte biblioteker, forsøger at udføre I / O osv.)

Opløsning:

For at forbedre din EJB-viden skal du tage en weekend og læse EJB-specifikationen (1.1-versionen er 314 sider lang). Læs derefter 2.0-specifikationen (524 sider!) For at få en fornemmelse for, hvad 1.1-specifikationen ikke adresserede, og hvor 2.0-specifikationen vil føre dig. Koncentrer dig om de dele af specifikationen, der fortæller dig, applikationsudvikleren, hvad der er juridiske handlinger i en EJB. Afsnit 18.1 og 18.2 er gode steder at starte.

Bemærkninger:

Se ikke på EJB-verdenen gennem din leverandørs øjne. Sørg for, at du kender forskellen mellem de specifikationer, der ligger til grund for EJB-modellen, og en bestemt tilgang til dem. Dette vil også sikre, at du kan overføre dine færdigheder til andre leverandører (eller versioner) efter behov.

Beskrivelse: Forstår ikke J2EE

Projektfase:

Design

Berørt (e) projektfase (r):

Udvikling

Berørte systemegenskaber:

Vedligeholdelse, skalerbarhed, ydeevne

Symptomer:

  • Designet "Everything is an EJB"
  • Manuel transaktionsstyring i stedet for at bruge de mekanismer, der leveres af containere
  • Brugerdefinerede sikkerhedsimplementeringer - J2EE-platformen har sandsynligvis den mest komplette og integrerede sikkerhedsarkitektur i enterprise computing, lige fra præsentation til back-end; det bruges sjældent til sin fulde kapacitet

Opløsning:

Lær J2EEs nøglekomponenter, og hvilke fordele og ulemper hver komponent bringer til bordet. Dæk hver tjeneste efter tur viden er lig med magt her.

Bemærkninger:

Kun viden kan løse disse problemer. Gode ​​Java-udviklere er gode EJB-udviklere, som igen er ideelt placeret til at blive J2EE-guruer. Jo mere Java- og J2EE-viden du besidder, jo bedre bliver du til design og implementering. Tingene begynder at gå på plads for dig på designtidspunktet.

Fare 2: Over-engineering (til EJB eller ikke til EJB)

Projektfase:

Design

Berørt (e) projektfase (r):

Udvikling

Berørte systemegenskaber:

Vedligeholdelse, skalerbarhed, ydeevne

Symptomer:

  • For store EJB'er
  • Udviklere, der ikke kan forklare, hvad deres EJB'er gør, og forholdet mellem dem
  • Ikke-genanvendelige EJB'er, komponenter eller tjenester, når de skulle være
  • EJB'er starter nye transaktioner, når en eksisterende transaktion vil gøre
  • Dataisoleringsniveauer er for høje (i et forsøg på at være sikker)

Opløsning:

Løsningen til over-engineering kommer lige fra ekstrem programmeringsmetoden (XP): design og kode det absolutte minimum for at opfylde kravene fra scoping, ikke mere. Mens du skal være opmærksom på de fremtidige krav, for eksempel fremtidige gennemsnitlige belastningskrav eller opførsel af systemet ved maksimale belastningstider, skal du ikke prøve at gætte, hvordan systemet skal se ud i fremtiden. Derudover definerer J2EE-platformen egenskaber som skalerbarhed og failover som opgaver, som serverinfrastrukturen skal håndtere for dig.

Med minimale systemer, der består af små komponenter designet til at gøre en ting og gøre det godt, forbedres genbrugsniveauet, ligesom systemets stabilitet. Desuden styrkes dit systems vedligeholdelsesevne, og fremtidige krav kan tilføjes meget lettere.

Bemærkninger:

Ud over de ovennævnte løsninger skal du anvende designmønstre - de forbedrer dit systemdesign markant. Selve EJB-modellen bruger designmønstre i vid udstrækning. F.eks

Hjem

interface til hver EJB er et eksempel på et Finder- og Factory-mønster. Den eksterne grænseflade til en EJB fungerer som en proxy til den faktiske implementering af bønner og er central for containerens evne til at opfange opkald og levere tjenester såsom gennemsigtig belastningsbalancering. Ignorer værdien af ​​designmønstre på din fare.

En anden fare, som jeg konstant advarer mod: at bruge EJB af hensyn til det. Ikke kun kan nogle dele af din applikation modelleres som EJB'er, når de ikke skulle være din hel applikation bruger muligvis EJB'er uden nogen målbar gevinst. Dette er over-engineering taget til ekstremer, men jeg har set perfekt gode servlet- og JavaBean-applikationer revet fra hinanden, redesignet og implementeret ved hjælp af EJB'er uden gode tekniske grunde.

Fare 3: Adskiller ikke præsentationslogik fra forretningslogik

Projektfase:

Design

Berørt (e) projektfase (r):

Udvikling

Berørte systemegenskaber:

Vedligeholdelse, udvidelighed, ydeevne

Symptomer:

  • Store og uhåndterlige JSP'er
  • Du befinder dig i at redigere JSP'er, når forretningslogikken ændres
  • En ændring i skærmkrav tvinger dig til at redigere og omplacere EJB'er og andre backend-komponenter

Opløsning:

J2EE-platformen giver dig mulighed for at adskille præsentationslogik fra navigation og kontrol og endelig fra forretningslogik. Det hedder Model 2-arkitekturen (se Ressourcer for en god artikel). Hvis du allerede er faldet i denne fælde, kræves der en stiv dosis refactoring. Du skal i det mindste have tynde lodrette skiver, der for det meste er selvstændige (det vil sige, hvordan jeg bestiller en widget, er et separat stykke fra, hvordan jeg ændrer mit brugernavn eller adgangskode). Brug denne implicitte organisering af dit system til at refaktorere i etaper.

Bemærkninger:

Brug af et ensartet design i forbindelse med en brugergrænseflade (f.eks. Taglibs) hjælper også med at sikre, at du undgår logiske separationsproblemer på dit projekt. Lad være med at opbygge en anden GUI-ramme til dine egne behov, der er for mange gode implementeringer, der er let tilgængelige. Evaluer hver efter hinanden og vedtag de rammer, der passer bedst til dine behov.

Fare 4: Implementerer ikke, hvor du udvikler dig

Projektfase:

Udvikling

Berørt (e) projektfase (r):

Stabilisering, Parallel, Live

Berørte systemegenskaber:

Din tilregnelighed

Symptomer:

  • Flerdages- eller ugelange overgange til live-systemer
  • Risikoen ved at gå live er betydelig, idet mange ukendte og store brugsscenarier ikke er testet
  • Data i live systemer er ikke de samme som data i udviklings- eller stabiliseringsopsætninger
  • Manglende evne til at køre bygger på udviklermaskiner
  • Applikationsadfærd er ikke den samme i udviklings-, stabiliserings- og produktionsmiljøer

Opløsning:

Løsningen til Fare 4 begynder med at duplikere produktionsmiljøet trofast i dit udviklingsmiljø. Udvikl på nøjagtigt den samme opsætning som den, du planlægger at gå til live - udvikl ikke på JDK 1.3 og Red Hat Linux, når du planlægger at gå live på JDK 1.2.2 og Solaris 7. Yderligere, udvikl ikke på en applikationsserver og gå live på en anden. Få også et øjebliksbillede af data fra produktionsdatabasen og brug det til test, ikke stole på kunstigt oprettede data. Hvis produktionsdata er følsomme, skal du fjerne følsomhed over dem og indlæse dem. Uventede produktionsdata bryder:

  • Datavalideringsregler
  • Testet systemadfærd
  • Kontrakter mellem systemkomponenter (især EJB-EJB og EJB-database)

Værst af alt, hver af disse vil resultere i undtagelser, nulpunkter og adfærd, som du aldrig har set før.

Bemærkninger:

Udviklere forlader ofte sikkerhed indtil stabilisering ("Ja, skærmene fungerer, lad os nu tilføje brugervaliderings ting."). Undgå denne fælde ved at bruge samme tid på at implementere sikkerhed som du gør til forretningslogik.

Har måske også

$config[zx-auto] not found$config[zx-overlay] not found