Per įvairias kūrėjo, vyresniojo kūrėjo ir architekto pareigas mačiau gerus, blogus ir negražius, kai kalbama apie įmonės „Java“ projektus! Kai klausiu savęs, dėl ko vienas projektas pavyksta, o kitas žlunga, sunku pateikti tobulą atsakymą, nes paaiškėja, kad sėkmę sunku apibrėžti visi programinės įrangos projektai. J2EE projektai nėra išimtis. Vietoj to, projektai būna sėkmingi arba žlungantys skirtingu laipsniu. Šiame straipsnyje siekiu atkreipti dėmesį į 10 populiariausių pavojų, darančių įtaką įmonės „Java“ projekto sėkmei, ir parodyti juos jums, skaitytojui.
Kai kurie iš šių pavojų paprasčiausiai sulėtina projektą, kiti yra klaidingi takai, o kiti gali visiškai sugadinti bet kokią sėkmės galimybę. Tačiau visų jų galima išvengti gerai pasiruošus, žinant apie būsimą kelionę ir vietinius gidus, kurie žino vietovę.
Šis straipsnis yra paprastos struktūros; Aš apžvelgsiu kiekvieną pavojų taip:
- Pavojaus pavadinimas: Vienvamzdis, apibūdinantis pavojų
- Projekto etapas: Projekto etapas, kuriame kyla pavojus
- Paveiktas projekto etapas (-ai): Daugeliu atvejų pavojai gali turėti įtakos vėlesniems projekto etapams
- Simptomai: Su šiuo pavojumi susiję simptomai
- Sprendimas: Būdai, kaip apskritai išvengti pavojaus, ir kaip sumažinti jo poveikį jūsų projektui
- Pastabos: Taškai, kuriuos noriu perduoti, susiję su pavojumi, tačiau netelpa į ankstesnes kategorijas
Kaip minėta pirmiau, kiekvieną pavojų išnagrinėsime įmonės „Java“ projekto kontekste kartu su svarbiais jo etapais. Projekto etapai apima:
- Tiekėjo pasirinkimas: Pasirinkti geriausią įmanomą įrankių derinį prieš pradedant J2EE projektą - nuo programų serverio iki jūsų prekės ženklo kavos.
- Dizainas: Tarp griežtos krioklio metodikos ir požiūrio „užkoduokite ir pamatykite“ slypi mano požiūris į dizainą: aš darau pakankamai dizaino, kad galėčiau patogiai pereiti į plėtrą. Mano supratimas, kad mano projektavimo etapas baigtas, kai tiksliai žinau, ką statysiu ir kaip tai pastatysiu. Be to, aš naudoju dizaino šablonus, norėdamas įsitikinti, kad prieš pradėdamas kūrimą aš uždaviau visus teisingus klausimus apie save ir savo siūlomą sprendimą. Tačiau šiame etape nebijau koduoti; kartais tai yra vienintelis būdas atsakyti į klausimą apie sakymą, atlikimą ar moduliarumą.
- Plėtra: Projekto etapas, kuriame bus parodytas ankstesniais etapais atlikto darbo kiekis. Geras įrankių pasirinkimas kartu su geru dizainu ne visada reiškia itin sklandų kūrimą, tačiau tikrai padeda!
- Stabilizavimas / apkrovos testavimas: Šiame etape sistemos architektas ir projekto vadovas nustatys funkcijų įšaldymą ir daugiausia dėmesio skirs sukūrimo kokybei, taip pat užtikrins, kad būtų galima įvykdyti sistemos gyvybinę statistiką - vienu metu esančių vartotojų skaičių, perjungimo scenarijus ir pan. Tačiau iki šio etapo nereikėtų ignoruoti kokybės ir našumo. Iš tiesų, negalite rašyti prastos kokybės ar lėto kodo ir palikti jį iki stabilizavimo, kad išspręstumėte.
- Tiesioginis: Tai iš tikrųjų nėra projekto etapas, tai yra akmenyje nustatyta data. Šis etapas yra susijęs su pasiruošimu. Čia praeities klaidų vaiduokliai sugrįš į jūsų projektą - nuo blogo dizaino ir tobulinimo iki prasto pardavėjų pasirinkimo.
1 paveiksle pavaizduoti projekto etapai, kuriuos labiausiai paveikė skirtingos priežastys (ir ypač papildomas poveikis).
Na, tada, be ilgesnio svarstymo, pasinerkime tiesiai į dešimtuką!
1 pavojus: nesuprantate „Java“, nesuprantate EJB, nesuprantate J2EE
Teisingai, aš padalysiu šį į tris pogrupius, kad būtų lengviau analizuoti.
Apibūdinimas: Nesuprantu Java
Projekto etapas:
Plėtra
Paveiktas projekto etapas (-ai):
Dizainas, stabilizavimas, tiesioginis
Paveiktos sistemos charakteristikos:
Palaikomumas, mastelis, našumas
Simptomai:
- Funkcijų ir klasių, esančių JDK pagrindinėse API, atnaujinimas
- Nežinodamas, kas yra arba visi šie dalykai ir ką jie daro (šis sąrašas atspindi tik temų pavyzdį):
- Šiukšlių surinkėjas (traukinys, kartinis, prieauginis, sinchroninis, asinchroninis)
- Kada daiktus galima surinkti šiukšles - kabančios nuorodos
- „Java“ naudojami paveldėjimo mechanizmai (ir jų kompromisai)
- Metodas per didelis važiavimas ir perkrovimas
- Kodėl
java.lang.Stringas(pakeisk savo mėgstamą klasę čia!) pasirodys blogai - „Pass-pass“ „Java“ semantika (palyginti su „pass-pass value semantics in EJB“)
- Naudojant
==palyginti sulygi ()metodas nelaikomiems - Kaip „Java“ suplanuoja gijas skirtingose platformose (pavyzdžiui, iš anksto pasirenkant ar ne)
- Žalios gijos, palyginti su vietinėmis gijomis
- „Hotspot“ (ir kodėl senos našumo derinimo technikos paneigia „Hotspot“ optimizavimą)
- JIT ir tada, kai geri JIT tampa blogi (nenustatyti
JAVA_COMPILERir jūsų kodas veikia puikiai ir t. t.) - Kolekcijų API
- RMI
Sprendimas:
Turite patobulinti savo žinias apie „Java“, ypač apie jos stipriąsias ir silpnąsias puses. „Java“ egzistuoja toli už kalbos ribų. Ne mažiau svarbu suprasti platformą (JDK ir įrankius). Konkrečiai, turėtumėte tapti „Java“ programuotojo sertifikatu, jei dar nesate - nustebsite, kiek nežinote. Dar geriau - darykite tai kaip grupės dalis ir stumkite vienas kitą. Taip pat smagiau. Toliau sukurkite „Java“ technologijai skirtą adresatų sąrašą ir tęskite jį! (Kiekviena įmonė, su kuria dirbau, turi šiuos sąrašus, kurių didžioji dalis yra dėl gyvybės palaikymo dėl neveiklumo.) Mokykitės iš savo bendraamžių kūrėjų - tai geriausias jūsų šaltinis.
Pastabos:
Jei jūs ar kiti jūsų komandos nariai nesupranta programavimo kalbos ir platformos, kaip galite tikėtis sukurti sėkmingą įmonės „Java“ programą? Stiprieji „Java“ programuotojai eina į EJB, o J2EE kaip antys - į vandenį. Priešingai, prasti ar nepatyrę programuotojai sukurs nekokybiškas J2EE programas.
Apibūdinimas: Nesuprantu EJB
Projekto etapas:
Dizainas
Paveiktas projekto etapas (-ai):
Vystymasis, stabilizavimas
Paveiktos sistemos charakteristikos:
Priežiūra
Simptomai:
- EJB, kurie dirba, kai jie pirmą kartą iškviečiami, bet niekada vėliau (ypač sesijos be pilietybės, kurios grąžinamos į paruoštą baseiną)
- Vienkartiniai EJB
- Nežinia, už ką atsakingas kūrėjas, palyginti su tuo, ką teikia sudėtinis rodinys
- EJB, kurie neatitinka specifikacijos (įjungti gijas, įkelti vietines bibliotekas, bandyti atlikti įvestį / išvestį ir pan.)
Sprendimas:
Norėdami pagerinti savo žinias apie EJB, praleiskite savaitgalį ir perskaitykite EJB specifikaciją (1.1 versija yra 314 puslapių). Tada perskaitykite 2.0 specifikaciją (524 puslapiai!), Kad pajustumėte, ko 1.1 specifikacija nesprendė ir kur jus nuveš 2.0 specifikacija. Susikoncentruokite ties tomis specifikacijos dalimis, kurios jums, programos kūrėjui, nurodo teisinius veiksmus EJB. 18.1 ir 18.2 skyriai yra tinkamos vietos pradėti.
Pastabos:
Nežiūrėkite į EJB pasaulį savo pardavėjo akimis. Įsitikinkite, kad žinote skirtumą tarp specifikacijų, kuriomis grindžiamas EJB modelis, ir jų konkretaus pasirinkimo. Tai taip pat užtikrins, kad prireikus galėsite perduoti savo įgūdžius kitiems pardavėjams (arba versijoms).
Apibūdinimas: Nesuprantu J2EE
Projekto etapas:
Dizainas
Paveiktas projekto etapas (-ai):
Plėtra
Paveiktos sistemos charakteristikos:
Priežiūra, mastelis, našumas
Simptomai:
- „Viskas yra EJB“ dizainas
- Rankinis operacijų valdymas, o ne konteinerių teikiamų mechanizmų naudojimas
- Pasirinktiniai saugumo diegimai - „J2EE“ platforma turi bene išsamiausią ir integruotą saugos skaičiavimą įmonės skaičiavimuose, nuo pateikimo iki pabaigos. jis retai naudojamas visomis galimybėmis
Sprendimas:
Sužinokite apie pagrindinius J2EE komponentus ir kokius privalumus bei trūkumus kiekvienas komponentas atneša į lentelę. Apima kiekvieną paslaugą paeiliui; žinios čia lygios galiai.
Pastabos:
Šias problemas gali išspręsti tik žinios. Geri „Java“ kūrėjai yra geri EJB kūrėjai, kurie savo ruožtu yra idealioje padėtyje tapti J2EE guru. Kuo daugiau turėsite „Java“ ir „J2EE“ žinių, tuo geriau mokėsite kurti ir įgyvendinti. Projektavimo metu viskas pradės veikti jūsų vietoje.
2 pavojus: per didelė inžinerija (EJB ar ne EJB)
Projekto etapas:
Dizainas
Paveiktas projekto etapas (-ai):
Plėtra
Paveiktos sistemos charakteristikos:
Priežiūra, mastelis, našumas
Simptomai:
- Negabaritinės EJB
- Kūrėjai, negalintys paaiškinti, ką daro jų EJB ir tarpusavio santykiai
- Vienkartiniai EJB, komponentai ar paslaugos, kai jie turėtų būti
- ETT pradeda naujas operacijas tada, kai bus atliktas esamas sandoris
- Duomenų izoliavimo lygiai nustatyti per aukštai (siekiant būti saugiems)
Sprendimas:
Inžinerijos sprendimas gaunamas tiesiai iš kraštutinio programavimo (XP) metodikos: suprojektuokite ir užkoduokite minimalų minimumą, kad atitiktų taikymo srities reikalavimus, nieko daugiau. Nors turite žinoti būsimus reikalavimus, pvz., Būsimus vidutinius apkrovos reikalavimus ar sistemos elgseną, kai apkrova yra didžiausia, nebandykite iš anksto atspėti, kaip sistema turės atrodyti ateityje. Be to, „J2EE“ platforma apibrėžia tokias savybes kaip mastelis ir perjungimas kaip užduotis, kurias jums turėtų atlikti serverio infrastruktūra.
Naudojant minimalias sistemas, sudarytas iš mažų komponentų, suprojektuotų atlikti vieną dalyką ir tai padaryti gerai, pagerėja pakartotinio naudojimo lygis, kaip ir sistemos stabilumas. Be to, sustiprėja jūsų sistemos išlaikomumas, todėl būsimus reikalavimus galima pridėti daug lengviau.
Pastabos:
Be aukščiau išvardytų sprendimų, naudokite dizaino modelius - jie žymiai pagerina jūsų sistemos dizainą. Pats EJB modelis plačiai naudoja dizaino modelius. Pavyzdžiui,
Namai
kiekvieno EJB sąsaja yra „Finder“ ir „Factory“ modelio pavyzdys. Nuotolinė EJB sąsaja veikia kaip tarpinis faktinis pupelių įgyvendinimas ir yra svarbiausias konteinerio gebėjimui perimti skambučius ir teikti tokias paslaugas kaip skaidrus apkrovos balansavimas. Nepaisykite dizaino modelių vertės.
Dar vienas pavojus, nuo kurio nuolat perspėju: naudodamasis EJB. Kai kurios jūsų programos dalys gali būti modeliuotos kaip EJB, kai jos neturėtų būti, jūsų visas programa gali naudoti EJB, kad nebūtų matuojamas pelnas. Tai yra per daug inžinerijos, perimta į kraštutinumus, bet aš mačiau, kad visiškai geros servleto ir „JavaBean“ programos buvo suplėšytos, pertvarkytos ir įdiegtos naudojant EJB be gerų techninių priežasčių.
3 pavojus: neatskiriama pateikimo logika nuo verslo logikos
Projekto etapas:
Dizainas
Paveiktas projekto etapas (-ai):
Plėtra
Paveiktos sistemos charakteristikos:
Palaikomumas, išplėtimas, našumas
Simptomai:
- Dideli ir nepatogūs JSP
- Redaguodami JSP, kai pasikeičia verslo logika
- Vaizdo reikalavimų pasikeitimas verčia redaguoti ir perdaryti EJB ir kitus vidinius komponentus
Sprendimas:
J2EE platforma suteikia jums galimybę atskirti pristatymo logiką nuo naršymo ir valdymo, galiausiai nuo verslo logikos. Tai vadinama „Model 2“ architektūra (gero straipsnio ieškokite šaltiniuose). Jei jau patekote į šį spąstą, reikalinga griežta refaktoravimo dozė. Turėtumėte turėti bent jau plonus vertikalius pjūvius, kurie dažniausiai yra savarankiški (tai yra, kaip užsisakyti valdiklį, yra atskira dalis, kaip pakeisti vartotojo vardą ar slaptažodį). Naudokite šią numanomą savo sistemos organizaciją, kad galėtumėte pertvarkyti etapais.
Pastabos:
Nuoseklaus dizaino naudojimas kartu su vartotojo sąsajos sistema (pvz., „Taglibs“) taip pat padės užtikrinti, kad projekte išvengsite loginio atskyrimo problemų. Nesivarginkite kurdami kitą GUI sistemą savo poreikiams, lengvai pasiekiama daugybė gerų įdiegimų. Įvertinkite kiekvieną iš eilės ir patvirtinkite sistemą, kuri geriausiai atitinka jūsų poreikius.
4 pavojus: nesikreipkite ten, kur vystotės
Projekto etapas:
Plėtra
Paveiktas projekto etapas (-ai):
Stabilizavimas, lygiagretus, tiesioginis
Paveiktos sistemos charakteristikos:
Tavo protas
Simptomai:
- Kelios dienos ar savaitės trukmės perėjimai į veikiančias sistemas
- Rizika, susijusi su tiesioginiu išleidimu, yra didelė, daugybė nežinomų dalykų ir pagrindiniai naudojimo scenarijai nėra išbandyti
- Duomenys veikiančiose sistemose nėra tokie patys kaip kūrimo ar stabilizavimo sąrankų duomenys
- Nesugebėjimas paleisti remiasi kūrėjų mašinomis
- Programos elgsena nėra vienoda kūrimo, stabilizavimo ir gamybos aplinkoje
Sprendimas:
„Danger 4“ sprendimas prasideda nuo to, kad jūsų aplinka yra teisingai pakartota gamybos aplinka. Sukurkite tą pačią sąranką, kaip ir planuojate gyventi - nekurkite JDK 1.3 ir „Red Hat Linux“, kai planuojate pradėti veikti JDK 1.2.2 ir „Solaris 7“. viename programų serveryje, o tiesiogiai - kitame. Be to, gaukite duomenų momentinę kopiją iš gamybos duomenų bazės ir naudokite ją bandymams, nepasikliaukite dirbtinai sukurtais duomenimis. Jei gamybos duomenys yra neskelbtini, juos desensibilizuokite ir įkelkite. Netikėti gamybos duomenys bus nutraukti:
- Duomenų tikrinimo taisyklės
- Išbandyta sistemos elgsena
- Sutartys tarp sistemos komponentų (visų pirma EJB-EJB ir EJB duomenų bazėje)
Blogiausia, kad kiekviena iš jų sukels išimtis, niekinius rodiklius ir elgesį, kurio dar niekada nematėte.
Pastabos:
Kūrėjai dažnai palieka saugumą iki stabilizavimo („Taip, ekranai veikia, dabar pridėkime vartotojo patvirtinimo dalykus“.). Venkite šių spąstų, saugumo užtikrinimui skirdami tiek pat laiko, kiek ir verslo logikai.
