Opasnosti od J2EE projekta!

U svojim raznim mandatima programera, starijeg programera i arhitekta vidio sam dobro, loše i ružno što se tiče poslovnih Java projekata! Kad se pitam što čini jedan projekt uspješnim, a drugi neuspješnim, teško je doći do savršenog odgovora, jer se za sve softverske projekte teško može definirati uspjeh . J2EE projekti nisu iznimka. Umjesto toga, projekti uspijevaju ili propadaju različitim stupnjevima. U ovom članku želim preuzeti 10 najboljih opasnosti koje utječu na uspjeh poslovnog Java projekta i prikazati ih vama, čitatelju.

Neke od ovih opasnosti jednostavno usporavaju projekt, neke su lažne staze, a druge mogu izravno pokvariti svaku šansu za uspjeh. Međutim, sve se mogu izbjeći dobrom pripremom, znanjem o putu koji slijedi i lokalnim vodičima koji poznaju teren.

Ovaj je članak jednostavne strukture; Pokrivat ću svaku opasnost na sljedeći način:

  • Naziv opasnosti: jednoslojna linija koja opisuje opasnost
  • Faza projekta: Faza projekta u kojoj se javlja opasnost
  • Pogođene projektne faze: U puno slučajeva opasnosti mogu imati utjecaj na kasnije faze projekta
  • Simptomi: Simptomi povezani s ovom opasnošću
  • Rješenje: Načini da se opasnost potpuno izbjegne i kako umanjiti njene učinke na vaš projekt
  • Napomene: Točke koje želim dati koje se odnose na opasnost, ali se ne uklapaju u prethodne kategorije

Kao što je gore spomenuto, proučit ćemo svaku opasnost u kontekstu poslovnog Java projekta, zajedno s njegovim važnim fazama. Faze projekta obuhvaćaju:

  • Odabir dobavljača: Proces odabira najbolje moguće kombinacije alata prije nego što započnete svoj J2EE projekt - od aplikacijskog poslužitelja do vaše marke kave.
  • Dizajn: Između rigorozne metodologije vodopada i pristupa "kodiraj i vidi" leži moj stav o dizajnu: radim dovoljno dizajna da bih mogao ugodno krenuti u razvoj. Smatram da je moja faza projektiranja završena kad točno znam što gradim i kako ću to graditi. Štoviše, koristim predloške za dizajn kako bih bio siguran da sam postavio sva prava pitanja o sebi i predloženom rješenju prije nego što krenem u razvoj. Međutim, ne bojim se kodiranja u ovoj fazi; ponekad je to jedini način da odgovorite na pitanje o recimo, izvedbi ili modularnosti.
  • Razvoj: Faza projekta gdje će se prikazati količina posla obavljenog u ranijim fazama. Dobar izbor alata u kombinaciji s dobrim dizajnom ne znači uvijek super glatki razvoj, ali sigurno pomaže!
  • Ispitivanje stabilizacije / opterećenja: U ovoj fazi arhitekt sustava i voditelj projekta nametnut će zamrzavanje značajki i usredotočiti se na kvalitetu izrade, kao i osigurati da vitalne statistike sustava - broj istovremenih korisnika, scenariji preusmjeravanja itd. - može se ispuniti. Međutim, kvalitetu i izvedbu ne treba zanemariti do ove faze. Zapravo, ne možete napisati nekvalitetan ili spor kôd i ostaviti ga dok se stabilizacija ne popravi.
  • Uživo: Ovo zapravo nije projektna faza, to je datum postavljen u kamenu. Ova se faza odnosi na pripremu. Tu će se vratiti duhovi prošlih pogrešaka koji će progoniti vaš projekt, od lošeg dizajna i razvoja do lošeg izbora dobavljača.

Slika 1 ilustrira faze projekta na koje su različiti uzroci najviše utjecali (a posebno posljedice).

Pa, onda, bez daljnjega, zaronimo u top 10!

Opasnost 1: Ne razumijem Javu, ne razumijem EJB, ne razumijem J2EE

U redu, podijelit ću ovaj na tri podelementa za lakšu analizu.

Opis: Ne razumijem Javu

Faza projekta:

Razvoj

Pogođene projektne faze:

Dizajn, stabilizacija, uživo

Pogođene karakteristike sustava:

Održavanje, skalabilnost, izvedba

Simptomi:

  • Reimplementacija funkcionalnosti i klasa koje su već sadržane u JDK osnovnim API-ima
  • Ne znajući što su ili sve od sljedećeg i što rade (ovaj popis predstavlja samo uzorak tema):
    • Sakupljač smeća (vlak, generacijski, inkrementalni, sinkroni, asinkroni)
    • Kada se predmeti mogu sakupljati smeće - viseće reference
    • Mehanizmi nasljeđivanja koji se koriste (i njihovi razmjeni) u Javi
    • Prekomjerno jahanje i preopterećenje metode
    • Zašto java.lang.String(zamijenite svoj omiljeni razred ovdje!) Pokazuje se lošim za izvedbu
    • Referentna semantika Java-a (naspram semantike vrijednosti pass-by u EJB-u)
    • Korištenje ==naspram primjene equals()metode za neprimitive
    • Kako Java raspoređuje niti na različitim platformama (na primjer, preventivno ili ne)
    • Zelene niti naspram izvornih niti
    • Hotspot (i zašto stare tehnike podešavanja performansi negiraju optimizaciju Hotspota)
    • JIT i kada se dobri JIT-ovi pokvare (ponište se JAVA_COMPILERi vaš kôd radi sasvim u redu, itd.)
    • API za zbirke
    • RMI

Riješenje:

Morate poboljšati svoje znanje o Javi, posebno njezinim prednostima i nedostacima. Java postoji daleko više od samog jezika. Jednako je važno razumjeti platformu (JDK i alati). Konkretno, trebali biste se certificirati za Java programera ako to već niste učinili - začudit ​​ćete se koliko niste znali. Još je bolje da to radite kao dio grupe i forsirate jedni druge. Na ovaj je način i zabavnije. Nadalje, postavite mailing listu posvećenu Java tehnologiji i nastavite! (Svaka tvrtka s kojom sam surađivao ima ove popise, od kojih je većina na životnom osiguranju zbog neaktivnosti.) Naučite od svojih vršnjačkih programera - oni su vaš najbolji resurs.

Bilješke:

Ako vi ili drugi članovi vašeg tima ne razumijete programski jezik i platformu, kako se možete nadati izgradnji uspješne poslovne Java aplikacije? Snažni programeri Java odlaze na EJB i J2EE poput patki u vodu. Suprotno tome, siromašni ili neiskusni programeri konstruirat će nekvalitetne J2EE aplikacije.

Opis: Ne razumijem EJB

Faza projekta:

Oblikovati

Pogođene projektne faze:

Razvoj, stabilizacija

Pogođene karakteristike sustava:

Održavanje

Simptomi:

  • EJB-ovi koji rade kad su prvi put pozvani, ali nikada nakon toga (posebno sesije građe bez državljanstva koje se vraćaju u spremište)
  • EJB-ovi koji se ne mogu ponovno koristiti
  • Ne znajući za što je odgovoran programer u usporedbi s onim što nudi spremnik
  • EJB-ovi koji ne odgovaraju specifikaciji (aktiviranje niti, učitavanje matičnih knjižnica, pokušaj izvođenja U / I i tako dalje)

Riješenje:

Da biste poboljšali svoje znanje o EJB, uzmite si vikend i pročitajte specifikaciju EJB (verzija 1.1 duga je 314 stranica). Zatim pročitajte specifikaciju 2.0 (524 stranice!) Da biste stekli osjećaj za ono što se specifikacija 1.1 nije odnosila i kamo će vas 2.0 specifikacija odvesti. Koncentrirajte se na dijelove specifikacije koji vam, programeru aplikacije, govore koje su pravne radnje u EJB-u. Odjeljci 18.1 i 18.2 dobra su mjesta za početak.

Bilješke:

Ne gledajte na svijet EJB-a očima vašeg dobavljača. Obavezno znajte razliku između specifikacija na kojima se temelji model EJB i određenog njihovog uzimanja. To će također osigurati da svoje vještine prema potrebi prenesete na druge dobavljače (ili verzije).

Opis: Ne razumijem J2EE

Faza projekta:

Oblikovati

Pogođene projektne faze:

Razvoj

Pogođene karakteristike sustava:

Održavanje, skalabilnost, performanse

Simptomi:

  • Dizajn "Sve je EJB"
  • Ručno upravljanje transakcijama umjesto korištenja mehanizama osiguranih od spremnika
  • Prilagođene sigurnosne implementacije - J2EE platforma ima vjerojatno najcjelovitiju i najintegriraniju sigurnosnu arhitekturu u poslovnom računarstvu, od prezentacije pa sve do pozadine; rijetko se koristi s punim mogućnostima

Riješenje:

Naučite ključne komponente J2EE i koje prednosti i nedostatke svaka komponenta donosi na stol. Pokrivajte svaku uslugu redom; znanje je ovdje jednako snazi.

Bilješke:

Te probleme može riješiti samo znanje. Dobri Java programeri čine dobre EJB programere, koji su pak idealno smješteni da postanu J2EE gurui. Što više znanja o Javi i J2EE posjedujete, to ćete biti bolji u dizajniranju i implementaciji. Stvari će vam se početi postavljati na svoje mjesto u vrijeme dizajniranja.

Opasnost 2: Prekomjerno inženjerstvo (za EJB ili ne za EJB)

Faza projekta:

Oblikovati

Pogođene projektne faze:

Razvoj

Pogođene karakteristike sustava:

Održavanje, skalabilnost, performanse

Simptomi:

  • Predimenzionirani EJB-ovi
  • Programeri koji ne mogu objasniti što rade njihovi EJB-ovi i međusobni odnosi
  • EJB-ovi, komponente ili usluge koji se ne mogu ponovno upotrijebiti kad bi trebali biti
  • EJB-ovi započinju nove transakcije kada će to učiniti postojeća transakcija
  • Postavljene previsoke razine izolacije podataka (u pokušaju da budu sigurni)

Riješenje:

Rješenje za prekomjerno inženjerstvo dolazi izravno iz metodologije ekstremnog programiranja (XP): dizajnirajte i kodirajte najmanji minimum da biste udovoljili zahtjevima opsega, ništa više. Iako morate biti svjesni budućih zahtjeva, na primjer budućih prosječnih zahtjeva za opterećenjem ili ponašanja sustava u vršnim vremenima učitavanja, nemojte pokušavati drugo pogađati kako će sustav trebati izgledati u budućnosti. Uz to, platforma J2EE definira karakteristike poput skalabilnosti i preusmjeravanja kao zadatke koje bi poslužiteljska infrastruktura trebala riješiti za vas.

S minimalnim sustavima, koji se sastoje od malih komponenata dizajniranih da rade jedno i to dobro, razina ponovne upotrebe poboljšava se, kao i stabilnost sustava. Štoviše, održivost vašeg sustava jača i budući se zahtjevi mogu dodati puno lakše.

Bilješke:

Uz gore navedena rješenja, upotrijebite uzorke dizajna - oni značajno poboljšavaju dizajn vašeg sustava. Sam model EJB široko koristi uzorke dizajna. Na primjer,

Home

Sučelje svakog EJB-a primjer je uzorka Finder i Factory. Daljinsko sučelje EJB-a djeluje kao proxy za stvarnu implementaciju graha i ključno je za sposobnost spremnika da presreće pozive i pruža usluge kao što je transparentno uravnoteženje opterećenja. Zanemarite vrijednost dizajnerskih uzoraka na svoju opasnost.

Još jedna opasnost na koju neprestano upozoravam: korištenje EJB-a radi nje. Ne samo da bi se neki dijelovi vaše aplikacije mogli modelirati kao EJB-ovi kad to ne bi trebali biti, cijela vaša aplikacija mogla bi koristiti EJB-ove bez mjerljivog dobitka. Ovo je pretjerano inženjerstvo dovedeno do krajnjih granica, ali vidio sam savršeno dobre servlet i JavaBean aplikacije razvaljene, redizajnirane i implementirane pomoću EJB-ova bez dobrih tehničkih razloga.

Opasnost 3: Ne odvajanje logike prezentacije od poslovne logike

Faza projekta:

Oblikovati

Pogođene projektne faze:

Razvoj

Pogođene karakteristike sustava:

Održavanje, proširivost, izvedba

Simptomi:

  • Veliki i nezgrapni JSP-ovi
  • Nalazite se kako uređujete JSP-ove kad se promijeni poslovna logika
  • Promjena u zahtjevima za prikaz prisiljava vas da uređujete i preraspodjeljujete EJB-ove i druge pozadinske komponente

Riješenje:

Platforma J2EE daje vam priliku da logiku prezentacije odvojite od navigacije i upravljanja i na kraju od poslovne logike. Zove se arhitektura modela 2 (dobar članak pogledajte u Resursima). Ako ste već upali u ovu zamku, traži se jaka doza refaktoriranja. Trebali biste imati barem tanke okomite kriške koji su većinom samostalni (odnosno, kako naručujem widget, odvojena je kriška od toga kako mijenjam korisničko ime ili lozinku). Koristite ovu implicitnu organizaciju vašeg sustava za faktičku refaktorizaciju.

Bilješke:

Korištenje konzistentnog dizajna zajedno s UI okvirom (na primjer taglibs) također će vam pomoći da izbjegnete probleme s logičkim razdvajanjem na vašem projektu. Ne zamarajte se izgradnjom drugog GUI okvira za vlastite potrebe, previše je dobrih implementacija koje su odmah dostupne. Procijenite svaku redom i usvojite okvir koji najbolje odgovara vašim potrebama.

Opasnost 4: Nerazmještanje tamo gdje se razvijate

Faza projekta:

Razvoj

Pogođene projektne faze:

Stabilizacija, paralelno, uživo

Pogođene karakteristike sustava:

Vaš razum

Simptomi:

  • Višednevni ili tjedni prijelazi na žive sustave
  • Rizik uključenja u rad je značajan, jer mnoge nepoznanice i glavni scenariji korištenja nisu testirani
  • Podaci u aktivnim sustavima nisu isti kao podaci u postavkama za razvoj ili stabilizaciju
  • Nemogućnost pokretanja nadogradnji na strojevima za programere
  • Ponašanje aplikacije nije isto u razvojnom, stabilizacijskom i proizvodnom okruženju

Riješenje:

Rješenje za Danger 4 započinje dupliciranjem proizvodnog okruženja u vašem razvojnom okruženju. Razvijte se na potpuno istim postavkama kao i one na kojima planirate ići uživo - ne razvijajte se na JDK 1.3 i Red Hat Linux kad planirate ići uživo na JDK 1.2.2 i Solaris 7. Nadalje, nemojte razvijati na jednom aplikacijskom poslužitelju, a uživo na drugom. Uzmite i snimak podataka iz proizvodne baze podataka i upotrijebite ga za testiranje, ne oslanjajte se na umjetno stvorene podatke. Ako su proizvodni podaci osjetljivi, desenzibilizirajte ih i učitajte. Neočekivani proizvodni podaci će se pokvariti:

  • Pravila provjere valjanosti podataka
  • Testirano ponašanje sustava
  • Ugovori između komponenata sustava (posebno EJB-EJB i EJB-baza podataka)

Najgore od svega je što će svaki od njih rezultirati iznimkama, null pokazivačima i ponašanjem koje nikada prije niste vidjeli.

Bilješke:

Razvojni programeri često ostavljaju sigurnost do stabilizacije ("Da, ekrani rade, sada dodamo stvari za provjeru valjanosti korisnika."). Izbjegnite ovu zamku posvećujući isto toliko vremena provedbi sigurnosti kao i poslovnoj logici.