V svojih različnih mandatih kot razvijalec, starejši razvijalec in arhitekt sem videl dobre, slabe in grde, ko gre za podjetniške projekte Java! Ko se vprašam, kaj naredi en projekt uspešen, drugi pa neuspešen, je težko najti popoln odgovor, saj je uspeh težko določiti za vse projekti programske opreme. Projekti J2EE niso nobena izjema. Namesto tega projekti različno uspevajo ali propadajo. V tem članku želim izkoristiti 10 najboljših nevarnosti, ki vplivajo na uspeh poslovnega Java projekta, in jih predstaviti vam, bralcu.
Nekatere od teh nevarnosti preprosto upočasnijo projekt, nekatere so napačne poti, spet druge pa lahko naravnost uničijo vse možnosti za uspeh. Vsem pa se je mogoče izogniti z dobro pripravo, znanjem o poti naprej in lokalnimi vodniki, ki poznajo teren.
Ta članek je preproste strukture; Vsako nevarnost bom pokril na naslednji način:
- Ime nevarnosti: Enoslojna linija, ki opisuje nevarnost
- Faza projekta: Faza projekta, v kateri se pojavi nevarnost
- Prizadete faze projekta: V mnogih primerih lahko nevarnosti vplivajo na poznejše faze projekta
- Simptomi: Simptomi, povezani s to nevarnostjo
- Rešitev: Načini, kako se nevarnosti popolnoma izogniti in kako zmanjšati njene učinke na vaš projekt
- Opombe: Točke, ki jih želim dati, ki se nanašajo na nevarnost, vendar ne spadajo v prejšnje kategorije
Kot smo že omenili, bomo vsako nevarnost preučili v kontekstu poslovnega projekta Java, skupaj z njegovimi pomembnimi fazami. Faze projekta zajemajo:
- Izbira prodajalca: Postopek izbiranja najboljše možne kombinacije orodij, preden začnete svoj projekt J2EE - od aplikacijskega strežnika do vaše blagovne znamke kave.
- Oblika: Med strogo metodologijo slapa in pristopom »kodiraj in poglej« leži moj pogled na oblikovanje: delam dovolj zasnove, da se lahko udobno premaknem v razvoj. Menim, da je moja faza projektiranja končana, ko natančno vem, kaj gradim in kako jo bom zgradil. Poleg tega se z oblikovalskimi predlogami prepričam, da sem pred prehodom v razvoj postavil vsa prava vprašanja o sebi in predlagani rešitvi. Vendar se v tej fazi ne bojim kodiranja; včasih je to edini način, da odgovorim na vprašanje, recimo, zmogljivost ali modularnost.
- Razvoj: Faza projekta, kjer bo prikazana količina opravljenega dela v prejšnjih fazah. Dobra izbira orodij skupaj z dobrim dizajnom ne pomeni vedno izjemno gladkega razvoja, a vsekakor pomaga!
- Preskušanje stabilizacije / obremenitve: V tej fazi bo sistemski arhitekt in vodja projekta naložil zamrznitev funkcij in se osredotočil na kakovost izdelave ter zagotovil, da bo mogoče izpolniti vitalne statistike sistema - število sočasnih uporabnikov, scenarije odpovedi itd. Vendar pa do te faze ne bi smeli zanemarjati kakovosti in zmogljivosti. Dejansko ne morete pisati nekakovostne ali počasne kode in jo pustiti, da se popravi do stabilizacije.
- V živo: To v resnici ni projektna faza, ampak datum, določen v kamnu. V tej fazi gre za pripravo. Tam se bodo vrnili duhovi preteklih napak, ki bodo preganjali vaš projekt, od slabe zasnove in razvoja do slabe izbire prodajalcev.
Slika 1 prikazuje faze projekta, na katere so različni vzroki najbolj vplivali (in zlasti učinki).
No, brez nadaljnjega se potopimo v prvih 10!
Nevarnost 1: Ne razumem Jave, ne razumem EJB, ne razumem J2EE
Prav, tega bom razdelil na tri podelemente za lažjo analizo.
Opis: Nerazumevanje Jave
Faza projekta:
Razvoj
Prizadete faze projekta:
Oblikovanje, stabilizacija, živo
Prizadete sistemske značilnosti:
Vzdrževalnost, razširljivost, zmogljivost
Simptomi:
- Ponovno izvajanje funkcionalnosti in razredov, ki jih že vsebujejo jedrni API-ji JDK
- Ne vedoč, kaj vse ali vse od naštetega je in kaj počne (ta seznam predstavlja le vzorec tem):
- Zbiralnik smeti (vlak, generacijski, inkrementalni, sinhroni, asinhroni)
- Kdaj je mogoče predmete zbirati smeti - viseče reference
- Mehanizmi dedovanja, ki se uporabljajo (in njihovi kompromisi) v Javi
- Prekomerna vožnja in preobremenitev
- Zakaj
java.lang.String(tukaj zamenjajte svoj najljubši razred!) se izkaže za slabo - Prenosna referenčna semantika Jave (v primerjavi s semantiko vrednosti posredovane vrednosti v EJB)
- Uporaba
==v primerjavi z izvajanjemenako ()metoda za neprimitive - Kako Java razporeja niti na različnih platformah (na primer prednostno ali ne)
- Zelene niti v primerjavi z izvornimi nitmi
- Hotspot (in zakaj stare tehnike za nastavitev zmogljivosti zanikajo optimizacije Hotspot-a)
- JIT in kdaj se dobri JIT pokvari (ni nastavljen
JAVA_COMPILERin vaša koda deluje v redu itd.) - API zbirk
- RMI
Rešitev:
Izboljšati morate svoje znanje Jave, zlasti njene prednosti in slabosti. Java obstaja daleč dlje od samo jezika. Prav tako je pomembno razumeti platformo (JDK in orodja). Konkretno bi morali postati certificirani programator Java, če tega še niste storili - presenečeni boste, koliko niste vedeli. Še bolje, naredite to kot del skupine in se potiskajte. Tudi na ta način je bolj zabavno. Nadalje nastavite poštni seznam, namenjen tehnologiji Java, in tako nadaljujte! (Vsako podjetje, s katerim sem sodeloval, ima te sezname, večina jih je zaradi neaktivnosti na življenjski podpori.) Naučite se od vrstniških razvijalcev - to je vaš najboljši vir.
Opombe:
Če vi ali drugi člani vaše ekipe ne razumete programskega jezika in platforme, kako lahko upate, da boste ustvarili uspešno poslovno aplikacijo Java? Močni programerji Java se na EJB in J2EE odpravijo kot račke v vodo. Nasprotno pa bodo slabi ali neizkušeni programerji sestavljali nekakovostne aplikacije J2EE.
Opis: Ne razumem EJB
Faza projekta:
Oblikovanje
Prizadete faze projekta:
Razvoj, stabilizacija
Prizadete sistemske značilnosti:
Vzdrževanje
Simptomi:
- EJB-ji, ki delujejo, ko so prvič poklicani, vendar nikoli pozneje (še posebej fižol seje brez stanja, ki se vrne v pripravljeno področje)
- EJB, ki jih ni mogoče ponovno uporabiti
- Ne vedoč, za kaj je odgovoren razvijalec, v primerjavi s tem, kar ponuja vsebnik
- EJB-ji, ki ne ustrezajo specifikaciji (sproži niti, naloži izvorne knjižnice, poskus izvede I / O itd.)
Rešitev:
Če želite izboljšati svoje znanje o EJB, si vzemite vikend in preberite specifikacijo EJB (različica 1.1 je dolga 314 strani). Nato preberite specifikacijo 2.0 (524 strani!), Da dobite občutek, kaj specifikacija 1.1 ni obravnavala in kam vas bo vodila specifikacija 2.0. Osredotočite se na dele specifikacije, ki vam, razvijalcu aplikacije, povedo, kakšni so pravni postopki v EJB. Oddelka 18.1 in 18.2 je dobro začeti.
Opombe:
Ne glejte na svet EJB skozi oči prodajalca. Prepričajte se, da poznate razliko med specifikacijami, na katerih temelji model EJB, in njihovim določenim stališčem. To bo zagotovilo tudi, da lahko svoje znanje po potrebi prenesete na druge ponudnike (ali različice).
Opis: Ne razumem J2EE
Faza projekta:
Oblikovanje
Prizadete faze projekta:
Razvoj
Prizadete sistemske značilnosti:
Vzdrževanje, razširljivost, zmogljivost
Simptomi:
- Dizajn "Vse je EJB"
- Ročno upravljanje transakcij namesto uporabe mehanizmov, ki jih zagotavlja zabojnik
- Varnostne izvedbe po meri - platforma J2EE ima verjetno najbolj popolno in integrirano varnostno arhitekturo v računalništvu podjetja, od predstavitve do konca; le redko se navadi v celoti
Rešitev:
Spoznajte ključne komponente J2EE ter prednosti in slabosti posameznih komponent. Pokrivajte vsako storitev po vrsti; znanje je tu enako moči.
Opombe:
Te težave lahko odpravi samo znanje. Dobri razvijalci Java so dobri razvijalci EJB, ki pa so v idealnem položaju, da postanejo guruji J2EE. Čim več znanja o Javi in J2EE imate, tem bolje boste pri načrtovanju in izvedbi. Stvari se bodo začele postavljati na svoje mesto v času načrtovanja.
Nevarnost 2: Prekomerni inženiring (za EJB ali ne za EJB)
Faza projekta:
Oblikovanje
Prizadete faze projekta:
Razvoj
Prizadete sistemske značilnosti:
Vzdrževanje, razširljivost, zmogljivost
Simptomi:
- Veliki EJB-ji
- Razvijalci, ki ne znajo razložiti, kaj počnejo njihovi EJB-ji in kakšen je odnos med njimi
- EJB, komponente ali storitve, ki jih ni mogoče ponovno uporabiti, kadar bi morali biti
- EJB začnejo nove transakcije, ko bo to storila obstoječa transakcija
- Stopnje izolacije podatkov so nastavljene previsoko (v poskusu varnosti)
Rešitev:
Rešitev za pretirano inženirstvo izhaja neposredno iz metodologije ekstremnega programiranja (XP): oblikujte in kodirajte čim manj, da izpolnite zahteve glede obsega, nič več. Čeprav se morate zavedati prihodnjih zahtev, na primer prihodnjih zahtev glede povprečne obremenitve ali vedenja sistema v času največje obremenitve, ne poskušajte ugibati, kako bo sistem izgledal v prihodnosti. Poleg tega platforma J2EE opredeljuje značilnosti, kot sta razširljivost in preusmeritev, kot naloge, ki jih mora strežniška infrastruktura obravnavati za vas.
Z minimalnimi sistemi, sestavljenimi iz majhnih komponent, zasnovanih tako, da naredijo eno stvar in to dobro, se raven ponovne uporabe izboljša, prav tako pa tudi stabilnost sistema. Poleg tega se vzdržnost vašega sistema krepi in prihodnje zahteve lahko dodate veliko lažje.
Opombe:
Poleg zgoraj naštetih rešitev uporabite tudi vzorce oblikovanja - bistveno izboljšajo zasnovo vašega sistema. Sam model EJB široko uporablja vzorce oblikovanja. Na primer
Domov
Vmesnik vsakega EJB je primer vzorca Finder in Factory. Oddaljeni vmesnik EJB deluje kot posrednik za dejansko izvedbo fižola in je osrednjega pomena za sposobnost vsebnika, da prestreže klice in zagotavlja storitve, kot je pregledno uravnoteženje obremenitve. Na svojo nevarnost prezrite vrednost vzorcev oblikovanja.
Druga nevarnost, na katero neprestano opozarjam: uporaba EJB zaradi tega. Nekateri deli vaše aplikacije se ne bi mogli modelirati samo kot EJB, kadar ne bi smeli, ampak tudi vaši celoten aplikacija lahko uporablja EJB-je brez merljivega dobička. To je pretirano inženirstvo privedlo do skrajnosti, vendar sem videl, da so popolnoma dobri programi za servlet in JavaBean raztrgani, preoblikovani in implementirani z uporabo EJB-jev brez tehtnih razlogov.
Nevarnost 3: Ločevanje predstavitvene logike od poslovne logike ni ločeno
Faza projekta:
Oblikovanje
Prizadete faze projekta:
Razvoj
Prizadete sistemske značilnosti:
Vzdrževalnost, razširljivost, zmogljivost
Simptomi:
- Veliki in okorni JSP-ji
- Urejate JSP, ko se spremeni poslovna logika
- Sprememba zahtev zaslona vas prisili v urejanje in prerazporeditev EJB-jev in drugih komponent ozadja
Rešitev:
Platforma J2EE vam omogoča, da predstavitveno logiko ločite od navigacije in nadzora ter na koncu od poslovne logike. Imenuje se arhitektura modela 2 (za dober članek glejte Vire). Če ste že padli v to past, je potreben velik odmerek. Imeti bi morali vsaj tanke navpične rezine, ki so večinoma samostojne (to je, kako naročim gradnik, je ločeno od tega, kako spremenim svoje uporabniško ime ali geslo). Uporabite to implicitno organizacijo vašega sistema za faktorsko refaktoriranje.
Opombe:
Uporaba dosledne zasnove v povezavi z ogrodjem uporabniškega vmesnika (na primer taglibi) vam bo pomagala zagotoviti, da se izognete težavam z ločevanjem logike v vašem projektu. Ne obremenjujte se z izdelavo novega ogrodja uporabniškega vmesnika za svoje potrebe, preveč dobrih izvedb je na voljo takoj. Ocenite vsakega po vrsti in sprejmite okvir, ki najbolje ustreza vašim potrebam.
Nevarnost 4: Nerazporejanje tam, kjer se razvijate
Faza projekta:
Razvoj
Prizadete faze projekta:
Stabilizacija, vzporedno, v živo
Prizadete sistemske značilnosti:
Vaša razumnost
Simptomi:
- Večdnevni ali celotedenski prehodi na žive sisteme
- Tveganje za začetek delovanja je precejšnje, saj veliko neznank in glavnih scenarijev uporabe ni preizkušenih
- Podatki v sistemih pod napetostjo niso enaki podatkom v programih za razvoj ali stabilizacijo
- Nezmožnost izvajanja nadgradenj na strojih za razvijalce
- Obnašanje aplikacij ni enako v razvojnem, stabilizacijskem in proizvodnem okolju
Rešitev:
Rešitev Danger 4 se začne z natančnim kopiranjem proizvodnega okolja v vašem razvojnem okolju. Razvijte popolnoma enako kot pri tisti, za katero nameravate živeti - ne razvijajte se na JDK 1.3 in Red Hat Linux, če nameravate v živo na JDK 1.2.2 in Solaris 7. Nadalje ne razvijajte na enem aplikacijskem strežniku in v živo na drugem. Pridobite tudi posnetek podatkov iz delovne baze podatkov in ga uporabite za testiranje, ne zanašajte se na umetno ustvarjene podatke. Če so proizvodni podatki občutljivi, jih občutljivo občutite in naložite. Nepričakovani proizvodni podatki se bodo zlomili:
- Pravila za preverjanje veljavnosti podatkov
- Preizkušeno vedenje sistema
- Pogodbe med sistemskimi komponentami (zlasti EJB-EJB in EJB-baza podatkov)
Najhuje pa je, da bo vsaka od njih povzročila izjeme, ničelne kazalce in vedenje, ki ga še niste videli.
Opombe:
Razvijalci pogosto pustijo varnost do stabilizacije ("Ja, zasloni delujejo, zdaj dodajte še stvari za preverjanje uporabnika."). Izognite se tej pasti, tako da posvečate toliko časa izvajanju varnosti kot poslovni logiki.
