I mine ulike ansettelsesperioder som utvikler, seniorutvikler og arkitekt, har jeg sett det gode, det dårlige og det stygge når det gjelder enterprise Java-prosjekter! Når jeg spør meg selv hva som får et prosjekt til å lykkes og et annet mislykkes, er det vanskelig å komme med det perfekte svaret, ettersom suksess viser seg vanskelig å definere for alle programvareprosjekter. J2EE-prosjekter er ikke noe unntak. I stedet lykkes eller mislykkes prosjekter i varierende grad. I denne artikkelen tar jeg sikte på å ta de 10 beste farene som påvirker suksessen til et Java-prosjekt, og vise dem for deg som leser.
Noen av disse farene bremser bare prosjektet, noen er falske spor, og andre kan direkte ødelegge enhver sjanse for suksess. Imidlertid kan alle unngås med god forberedelse, kunnskap om reisen fremover og lokale guider som kjenner terrenget.
Denne artikkelen er enkel i struktur; Jeg vil dekke hver fare som følger:
- Fare navn: One-liner som skisserer faren
- Prosjektfase: Prosjektfasen der faren oppstår
- Berørt (e) prosjektfase (r): I mange tilfeller kan farer påvirke senere prosjektfaser
- Symptomer: Symptomer forbundet med denne faren
- Løsning: Måter å unngå faren helt og hvordan du minimerer effekten av dette på prosjektet ditt
- Merknader: Poeng jeg ønsker å formidle som er knyttet til faren, men som ikke passer inn i de forrige kategoriene
Som nevnt ovenfor, vil vi undersøke hver fare i sammenheng med et Java-prosjekt, sammen med viktige faser. Prosjektets faser dekker:
- Valg av leverandør: Prosessen med å velge den best mulige blandingen av verktøy før du starter J2EE-prosjektet ditt - fra applikasjonsserveren helt ned til kaffemerket ditt.
- Design: Innimellom en streng fossemetodikk og en tilnærming med "kode det og se", ligger mitt inntrykk på design: Jeg gjør nok design slik at jeg kan gå komfortabelt inn i utvikling. Jeg vurderer designfasen min som fullført når jeg vet nøyaktig hva jeg bygger og hvordan jeg skal bygge den. Videre bruker jeg designmaler for å være sikker på at jeg har stilt alle de riktige spørsmålene til meg selv og den foreslåtte løsningen før jeg går over til utvikling. Imidlertid er jeg ikke redd for å kode i denne fasen; noen ganger er det den eneste måten å svare på et spørsmål om si, ytelse eller modularitet.
- Utvikling: Prosjektfasen hvor mengden arbeid som er utført i tidligere faser vil vise. Et godt utvalg av verktøy kombinert med god design betyr ikke alltid en superjevn utvikling, men det hjelper sikkert!
- Stabilisering / belastningstesting: I denne fasen vil systemarkitekten og prosjektlederen pålegge en funksjonsfrysing og fokusere på byggekvalitet, samt sikre at systemets vitale statistikk - antall samtidige brukere, failover-scenarier og så videre - kan oppfylles. Imidlertid bør kvalitet og ytelse ikke ignoreres før denne fasen. Faktisk kan du ikke skrive dårlig kvalitet eller treg kode og la den stå til stabilisering for å fikse.
- Bo: Dette er egentlig ikke en prosjektfase, det er en dato satt i stein. Denne fasen handler om forberedelse. Det er der spøkelsene fra tidligere feil vil komme tilbake for å hjemsøke prosjektet ditt, fra dårlig design og utvikling til et dårlig utvalg av leverandører.
Figur 1 illustrerer prosjektfasene som er mest berørt av de forskjellige årsakene (og spesielt bankeeffektene).
Vel, uten videre, la oss dykke rett inn i topp 10!
Fare 1: Ikke forstå Java, ikke forstå EJB, ikke forstå J2EE
Ikke sant, jeg skal dele denne i tre underelementer for enklere analyse.
Beskrivelse: Forstår ikke Java
Prosjektfase:
Utvikling
Berørt (e) prosjektfase (r):
Design, stabilisering, live
Berørte systemegenskaper:
Vedlikehold, skalerbarhet, ytelse
Symptomer:
- Reimplementering av funksjonalitet og klasser som allerede finnes i JDK-kjernen APIer
- Ikke å vite hva noe av eller alt av følgende er og hva de gjør (denne listen representerer bare et utvalg av emner):
- Søppeloppsamler (tog, generasjon, inkrementell, synkron, asynkron)
- Når gjenstander kan samles søppel - dinglende referanser
- Arvsmekanismer brukt (og deres kompromisser) i Java
- Metodeoverkjøring og overbelastning
- Hvorfor
java.lang.Streng(erstatt favorittklassen din her!) viser seg dårlig for ytelsen - Pass-by referansesemantikk til Java (versus pass-by-semantikk i EJB)
- Ved hjelp av
==versus implementering aver lik()metode for ikke-primitiver - Hvordan Java planlegger tråder på forskjellige plattformer (for eksempel forebyggende eller ikke)
- Grønne tråder kontra innfødte tråder
- Hotspot (og hvorfor gamle ytelsesteknikker negerer Hotspot-optimaliseringer)
- JIT og når gode JIT-er går dårlig (ikke satt
JAVA_COMPILERog koden din går helt fint osv.) - Samlingen API
- RMI
Løsning:
Du må forbedre din kunnskap om Java, spesielt dens styrker og svakheter. Java eksisterer langt utover bare språket. Det er like viktig å forstå plattformen (JDK og verktøy). Konkret bør du bli sertifisert som Java-programmerer hvis du ikke allerede er det - du vil bli overrasket over hvor mye du ikke visste. Enda bedre, gjør det som en del av en gruppe og dytt hverandre. Det er også morsommere på denne måten. Videre, sett opp en adresseliste viet til Java-teknologi og hold den gående! (Hvert selskap jeg har jobbet med har disse listene, hvorav de fleste har livsstøtte på grunn av inaktivitet.) Lær av jevnaldrende utviklere - de er din beste ressurs.
Merknader:
Hvis du eller andre medlemmer av teamet ditt ikke forstår programmeringsspråket og plattformen, hvordan kan du håpe å bygge en vellykket Java-applikasjon? Sterke Java-programmerere tar til EJB og J2EE som ender til vann. I motsetning til dette vil dårlige eller uerfarne programmerere konstruere J2EE-applikasjoner av dårlig kvalitet.
Beskrivelse: Forstår ikke EJB
Prosjektfase:
Design
Berørt (e) prosjektfase (r):
Utvikling, stabilisering
Berørte systemegenskaper:
Vedlikehold
Symptomer:
- EJB som fungerer når de først blir ringt, men aldri deretter (spesielt statsløse sesjonsbønner som returneres til det klare bassenget)
- Ikke-gjenbrukbare EJBer
- Ikke å vite for hva utvikleren er ansvarlig, sammenlignet med hva containeren gir
- EJB-er som ikke samsvarer med spesifikasjonen (branntråder, laster innfødte biblioteker, prøver å utføre I / O og så videre)
Løsning:
For å forbedre EJB-kunnskapen din, ta en helg og les EJB-spesifikasjonen (1.1-versjonen er 314 sider lang). Les deretter 2.0-spesifikasjonen (524 sider!) For å få en følelse av hva 1.1-spesifikasjonen ikke adresserte, og hvor 2.0-spesifikasjonen vil ta deg. Konsentrer deg om de delene av spesifikasjonen som forteller deg, applikasjonsutvikleren, hva som er lovlige handlinger i en EJB. Avsnitt 18.1 og 18.2 er gode steder å starte.
Merknader:
Ikke se på EJB-verden gjennom leverandørens øyne. Forsikre deg om at du vet forskjellen mellom spesifikasjonene som ligger til grunn for EJB-modellen og en spesiell oppfatning av dem. Dette vil også sikre at du kan overføre ferdighetene dine til andre leverandører (eller versjoner) etter behov.
Beskrivelse: Forstår ikke J2EE
Prosjektfase:
Design
Berørt (e) prosjektfase (r):
Utvikling
Berørte systemegenskaper:
Vedlikehold, skalerbarhet, ytelse
Symptomer:
- Designet "Everything is an EJB"
- Manuell transaksjonsstyring i stedet for å bruke de mekanismene som leveres av containere
- Egendefinerte sikkerhetsimplementeringer - J2EE-plattformen har sannsynligvis den mest komplette og integrerte sikkerhetsarkitekturen i bedriftens databehandling, fra presentasjon til bakenden; den brukes sjelden til sin fulle evne
Løsning:
Lær J2EEs nøkkelkomponenter og hvilke fordeler og ulemper hver komponent bringer til bordet. Dekke hver tjeneste etter tur; kunnskap er lik kraft her.
Merknader:
Bare kunnskap kan løse disse problemene. Gode Java-utviklere er gode EJB-utviklere, som igjen er ideelt posisjonert til å bli J2EE-guruer. Jo mer Java- og J2EE-kunnskap du har, desto bedre blir du med design og implementering. Ting vil begynne å komme på plass for deg ved designtid.
Fare 2: Over-engineering (til EJB eller ikke til EJB)
Prosjektfase:
Design
Berørt (e) prosjektfase (r):
Utvikling
Berørte systemegenskaper:
Vedlikehold, skalerbarhet, ytelse
Symptomer:
- Store EJBer
- Utviklere som ikke kan forklare hva EJB-ene deres gjør og forholdet mellom dem
- Ikke-gjenbrukbare EJB, komponenter eller tjenester når de skulle være det
- EJB starter nye transaksjoner når en eksisterende transaksjon vil gjøre det
- Dataisolasjonsnivåer satt for høyt (i et forsøk på å være trygge)
Løsning:
Løsningen for overteknikk kommer rett fra ekstrem programmering (XP) -metoden: design og kode det minste for å oppfylle kravene fra scoping, ikke mer. Selv om du må være klar over fremtidige krav, for eksempel fremtidige gjennomsnittlige belastningskrav eller oppførsel til systemet ved toppbelastningstider, ikke prøv å gjette hvordan systemet trenger å se ut i fremtiden. I tillegg definerer J2EE-plattformen egenskaper som skalerbarhet og failover som oppgaver serverinfrastrukturen skal håndtere for deg.
Med minimale systemer, sammensatt av små komponenter designet for å gjøre en ting og gjøre det bra, forbedres gjenbruksnivået, det samme gjør systemstabiliteten. Videre styrker systemets vedlikeholdsevne, og fremtidige krav kan legges til mye lettere.
Merknader:
I tillegg til løsningene som er oppført ovenfor, bruk designmønstre - de forbedrer systemdesignen din betydelig. Selve EJB-modellen bruker designmønstre i stor utstrekning. For eksempel
Hjem
grensesnitt for hver EJB er et eksempel på et Finder- og Factory-mønster. Det eksterne grensesnittet til en EJB fungerer som en proxy for den faktiske implementeringen av bønner og er sentral for containerens evne til å fange opp samtaler og tilby tjenester som gjennomsiktig lastbalansering. Ignorer verdien av designmønstre på din fare.
En annen fare som jeg stadig advarer mot: å bruke EJB for den skyld. Ikke bare kan noen deler av applikasjonen din modelleres som EJB når de ikke burde være din hel applikasjonen kan bruke EJB uten målbar gevinst. Dette er over-engineering tatt til ekstremer, men jeg har sett helt gode servlet- og JavaBean-applikasjoner revet fra hverandre, redesignet og implementert ved bruk av EJB-er uten gode tekniske grunner.
Fare 3: Skiller ikke presentasjonslogikk fra forretningslogikk
Prosjektfase:
Design
Berørt (e) prosjektfase (r):
Utvikling
Berørte systemegenskaper:
Vedlikehold, utvidbarhet, ytelse
Symptomer:
- Store og uhåndterlige JSP-er
- Du befinner deg i å redigere JSP når bedriftslogikken endres
- En endring i skjermkravene tvinger deg til å redigere og omplassere EJB og andre backend-komponenter
Løsning:
J2EE-plattformen gir deg muligheten til å skille presentasjonslogikk fra navigasjon og kontroll, og til slutt fra forretningslogikk. Det kalles Model 2-arkitekturen (se Resources for en god artikkel). Hvis du allerede har falt i denne fellen, kreves det en stiv dose refactoring. Du bør i det minste ha tynne vertikale skiver som for det meste er selvforsynte (det vil si at hvordan jeg bestiller en widget er et eget stykke fra hvordan jeg endrer brukernavn eller passord). Bruk denne implisitte organisasjonen av systemet ditt til å refaktorere i trinn.
Merknader:
Å bruke en konsekvent design i forbindelse med et brukergrensesnitt (for eksempel taglibs) vil også bidra til at du unngår logiske separasjonsproblemer i prosjektet ditt. Ikke bry deg om å bygge et annet GUI-rammeverk for dine egne behov, det er for mange gode implementeringer lett tilgjengelige. Evaluere hver i sin tur og vedta rammeverket som passer best til dine behov.
Fare 4: Ikke distribuere der du utvikler deg
Prosjektfase:
Utvikling
Berørt (e) prosjektfase (r):
Stabilisering, parallell, live
Berørte systemegenskaper:
Din tilregnelighet
Symptomer:
- Flergangs eller ukes lange overganger til live-systemer
- Risikoen ved å gå live er betydelig, med mange ukjente og store bruksscenarier som ikke er testet
- Data i live systemer er ikke det samme som data i utviklings- eller stabiliseringsoppsett
- Manglende evne til å kjøre bygger på utviklermaskiner
- Søknadsadferd er ikke den samme i utviklings-, stabiliserings- og produksjonsmiljøene
Løsning:
Løsningen på Danger 4 begynner med å duplisere produksjonsmiljøet trofast i utviklingsmiljøet ditt. Utvikle på nøyaktig samme oppsett som du planlegger å leve på - ikke utvikle på JDK 1.3 og Red Hat Linux når du planlegger å gå live på JDK 1.2.2 og Solaris 7. Videre, ikke utvikle på en applikasjonsserver og gå live på en annen. Få også et øyeblikksbilde av data fra produksjonsdatabasen og bruk den til testing, ikke stol på kunstig opprettet data. Hvis produksjonsdata er sensitive, følsomme dem og last dem opp. Uventede produksjonsdata vil bryte:
- Datavalideringsregler
- Testet systematferd
- Kontrakter mellom systemkomponenter (spesielt EJB-EJB og EJB-database)
Verst av alt, hver av disse vil resultere i unntak, nullpekere og atferd som du aldri har sett før.
Merknader:
Utviklere forlater ofte sikkerhet til stabilisering ("Ja, skjermene fungerer, la oss nå legge til brukervaliderings ting."). Unngå denne fellen ved å bruke like mye tid på å implementere sikkerhet som du gjør til forretningslogikk.
