Dažādos amatos kā attīstītājs, vecākais izstrādātājs un arhitekts esmu redzējis labo, slikto un neglīto, kad runa ir par uzņēmuma Java projektiem! Kad es sev jautāju, kas liek vienam projektam gūt panākumus, bet otram neizdoties, ir grūti atrast ideālu atbildi, jo izrādās, ka panākumus visi programmatūras projekti. J2EE projekti nav izņēmums. Tā vietā projekti dažādās pakāpēs gūst panākumus vai neizdodas. Šajā rakstā es cenšos aplūkot 10 populārākās briesmas, kas ietekmē uzņēmuma Java projekta panākumus, un parādīt tās jums, lasītājam.
Dažas no šīm briesmām vienkārši palēnina projektu, dažas ir viltus takas, un vēl citas var tieši sabojāt visas veiksmes iespējas. Tomēr no visiem var izvairīties ar labu sagatavošanos, zināšanām par turpmāko braucienu un vietējiem gidiem, kuri zina reljefu.
Šis raksts pēc struktūras ir vienkāršs; Katru apdraudējumu es aplūkošu šādi:
- Bīstamības nosaukums: Viena līnijpārvadātājs, kas izklāsta bīstamību
- Projekta fāze: Projekta posms, kurā notiek bīstamība
- Ietekmētā (-ās) projekta fāze (-es): Daudzos gadījumos apdraudējumiem var būt papildu ietekme uz turpmākajām projekta fāzēm
- Simptomi: Simptomi, kas saistīti ar šo bīstamību
- Risinājums: Veidi, kā vispār izvairīties no apdraudējuma, un kā samazināt tā ietekmi uz jūsu projektu
- Piezīmes: Punkti, kurus es vēlos sniegt, kas attiecas uz bīstamību, bet neietilpst iepriekšējās kategorijās
Kā minēts iepriekš, mēs pārbaudīsim katru apdraudējumu uzņēmuma Java projekta kontekstā, kā arī tā svarīgos posmus. Projekta fāzes aptver:
- Pārdevēja atlase: Labākā iespējamā rīku kombinācijas izvēle pirms J2EE projekta uzsākšanas - sākot no lietojumprogrammu servera līdz pat jūsu kafijas zīmolam.
- Dizains: Starp stingru ūdenskrituma metodoloģiju un pieeju "kodē un redzi" slēpjas mana izpratne par dizainu: es daru pietiekami daudz dizaina, lai varētu ērti pāriet uz attīstību. Es uzskatu, ka mana projektēšanas fāze ir pabeigta, kad es precīzi zinu, ko būvēju un kā to būvēšu. Turklāt es izmantoju dizaina veidnes, lai pārliecinātos, ka pirms virzības uz attīstību esmu uzdevis visus pareizos jautājumus par sevi un savu piedāvāto risinājumu. Tomēr es nebaidos kodēt šajā fāzē; dažreiz tas ir vienīgais veids, kā atbildēt uz teiciena, izpildījuma vai modularitātes jautājumu.
- Attīstība: Projekta posms, kurā būs redzams iepriekšējos posmos paveiktā darba apjoms. Laba rīku izvēle kopā ar labu dizainu ne vienmēr nozīmē ļoti vienmērīgu attīstību, taču tas noteikti palīdz!
- Stabilizācija / slodzes pārbaude: Šajā posmā sistēmas arhitekts un projekta vadītājs uzliks funkciju iesaldēšanu un koncentrēsies uz uzbūves kvalitāti, kā arī nodrošinās, ka var izpildīt sistēmas vitālo statistiku - vienlaicīgo lietotāju skaitu, kļūmjpārlēces scenārijus utt. Tomēr līdz šai fāzei nevajadzētu ignorēt kvalitāti un veiktspēju. Patiešām, jūs nevarat rakstīt sliktas kvalitātes vai lēnu kodu un atstāt to līdz stabilizācijai, lai to labotu.
- Tiešraide: Šis patiesībā nav projekta posms, tas ir akmens iecirsts datums. Šis posms ir saistīts ar sagatavošanos. Šeit atgriežas pagātnes kļūdu spoki, kas vajā jūsu projektu, sākot no slikta dizaina un izstrādes līdz sliktai pārdevēju izvēlei.
1. attēlā ir parādītas projekta fāzes, kuras visvairāk ietekmē dažādi cēloņi (un jo īpaši papildu efekti).
Nu tad, bez liekas aizķeršanās, ienirsim tieši desmitniekā!
1. bīstamība: nesaprot Java, nesaprot EJB, nesaprot J2EE
Pareizi, es to sadalīšu trīs apakšelementos, lai būtu vieglāk analizēt.
Apraksts: Nesaprot Java
Projekta fāze:
Attīstība
Ietekmētā (-ās) projekta fāze (-es):
Dizains, stabilizācija, tiešraide
Ietekmētās sistēmas īpašības:
Uzturamība, mērogojamība, veiktspēja
Simptomi:
- Atjaunot funkcionalitāti un klases, kas jau ir JDK pamata API
- Nezinot, kas ir vai visi no šiem un ko viņi dara (šis saraksts ir tikai tēmu paraugs):
- Atkritumu savācējs (vilciens, paaudzes, inkrementālais, sinhronais, asinhronais)
- Kad objekti var tikt savākti atkritumos - noraizējas atsauces
- Java lieto mantojuma mehānismus (un to kompromisus)
- Pārmērīga braukšanas un pārslodzes metode
- Kāpēc
java.lang.Strings(šeit aizstājiet savu iecienīto klasi!) izrādās slikti sniegumam - Java garāmgājienu atsauces semantika (salīdzinājumā ar garāmgājēju vērtības semantiku EJB)
- Izmantojot
==pretvienāds ()metode neprimitīviem - Kā Java ieplāno pavedienus dažādās platformās (piemēram, iepriekšēji vai nē)
- Zaļie pavedieni pret vietējiem pavedieniem
- Hotspot (un kāpēc vecās veiktspējas regulēšanas metodes noliedz Hotspot optimizāciju)
- JIT un tad, kad labiem JIT ir slikti (nenoteikti
JAVA_KOMPILERSun jūsu kods darbojas lieliski utt.) - Kolekciju API
- RMI
Risinājums:
Jums jāuzlabo zināšanas par Java, it īpaši tās stiprās un vājās puses. Java pastāv tālu ārpus valodas. Tikpat svarīgi ir saprast platformu (JDK un rīkus). Konkrēti, jums vajadzētu kļūt par Java programmētāja sertifikātu, ja vēl neesat - jūs būsiet pārsteigts, cik daudz jūs nezināt. Vēl labāk, dariet to kā daļu no grupas un virziet viens otru. Šādā veidā ir arī jautrāk. Turklāt izveidojiet Java tehnoloģijai veltītu adresātu sarakstu un turpiniet to turpināt! (Katram uzņēmumam, ar kuru esmu strādājis, ir šie saraksti, no kuriem lielākā daļa ir nedzīvības dēļ atbalstīti dzīvības uzturēšanā.) Mācieties no saviem vienaudžu izstrādātājiem - viņi ir jūsu labākais resurss.
Piezīmes:
Ja jūs vai citi jūsu komandas locekļi nesaprot programmēšanas valodu un platformu, kā jūs varat cerēt izveidot veiksmīgu uzņēmuma Java lietojumprogrammu? Spēcīgi Java programmētāji aizved uz EJB un J2EE kā pīles pie ūdens. Turpretī slikti vai nepieredzējuši programmētāji konstruēs sliktas kvalitātes J2EE lietojumprogrammas.
Apraksts: Nesaprotot EJB
Projekta fāze:
Dizains
Ietekmētā (-ās) projekta fāze (-es):
Attīstība, stabilizācija
Ietekmētās sistēmas īpašības:
Apkope
Simptomi:
- EJB, kas darbojas, kad tos pirmo reizi izsauc, bet nekad pēc tam (jo īpaši bezvalstnieku sesijas pupiņas, kas tiek atgrieztas gatavajā baseinā)
- Vienreizlietojamas EJB
- Nezinot, par ko atbild izstrādātājs, salīdzinot ar konteinera sniegto
- EJB, kas neatbilst specifikācijai (aktivizēt pavedienus, ielādēt vietējās bibliotēkas, mēģināt veikt I / O utt.)
Risinājums:
Lai uzlabotu savas zināšanas par EJB, dodieties nedēļas nogalē un izlasiet EJB specifikāciju (1.1 versija ir 314 lappuses). Pēc tam izlasiet 2.0 specifikāciju (524 lpp.!), Lai uzzinātu, ko 1.1 specifikācija nerisināja un kur jūs aizvedīs 2.0 specifikācija. Koncentrējieties uz tām specifikācijas daļām, kas jums, lietojumprogrammas izstrādātājam, norāda, kādas ir juridiskas darbības EJB. 18.1. Un 18.2. Sadaļa ir laba vieta, kur sākt.
Piezīmes:
Neskatieties uz EJB pasauli ar pārdevēja acīm. Pārliecinieties, ka zināt atšķirību starp specifikācijām, kas ir EJB modeļa pamatā, un konkrētu to pārņemšanu. Tas arī nodrošinās, ka pēc nepieciešamības varat nodot savas prasmes citiem piegādātājiem (vai versijām).
Apraksts: Nesaprotu J2EE
Projekta fāze:
Dizains
Ietekmētā (-ās) projekta fāze (-es):
Attīstība
Ietekmētās sistēmas īpašības:
Apkope, mērogojamība, veiktspēja
Simptomi:
- "Viss ir EJB" dizains
- Manuāla darījumu pārvaldība, nevis konteinera nodrošināto mehānismu izmantošana
- Pielāgotas drošības ieviešanas - J2EE platformai, iespējams, ir vispilnīgākā un integrētākā uzņēmuma arhitektūras drošības arhitektūra, sākot no prezentācijas līdz pat aizmugurē; tas tiek reti izmantots, lai pilnībā izmantotu savas iespējas
Risinājums:
Uzziniet J2EE galvenos komponentus un to, kādas priekšrocības un trūkumus katrs komponents rada tabulā. Katru pakalpojumu sedz pēc kārtas; zināšanas šeit ir vienādas ar varu.
Piezīmes:
Šīs problēmas var novērst tikai zināšanas. Labi Java izstrādātāji ir labi EJB izstrādātāji, kuri savukārt ir ideāli piemēroti, lai kļūtu par J2EE guru. Jo vairāk jums ir Java un J2EE zināšanu, jo labāk jūs būsiet izstrādājis un ieviesis. Projektēšanas laikā lietas sāks ievietot jūsu vietā.
2. bīstamība: pārmērīga inženierija (EJB vai ne EJB)
Projekta fāze:
Dizains
Ietekmētā (-ās) projekta fāze (-es):
Attīstība
Ietekmētās sistēmas īpašības:
Apkope, mērogojamība, veiktspēja
Simptomi:
- Liela izmēra EJB
- Izstrādātāji, kuri nevar izskaidrot to, ko dara viņu EJB, un attiecības starp viņiem
- Vienreizlietojami EJB, komponenti vai pakalpojumi, kad tiem vajadzētu būt
- EJB sāk jaunus darījumus, kad darīs esošs darījums
- Datu izolācijas līmeņi ir iestatīti pārāk augsti (lai būtu droši)
Risinājums:
Pārmērīgas inženierijas risinājums nāk tieši no galējās programmēšanas (XP) metodikas: noformējiet un kodējiet minimālo minimumu, lai izpildītu darbības jomas prasības, nekas vairāk. Lai gan jums jāapzinās nākotnes prasības, piemēram, nākotnes vidējās slodzes prasības vai sistēmas uzvedība maksimālās ielādes laikā, nemēģiniet otrreiz uzminēt, kādai sistēmai būs jāizskatās nākotnē. Turklāt J2EE platforma kā uzdevumus, kas jums jāapstrādā servera infrastruktūrā, definē tādas īpašības kā mērogojamība un kļūmjpārlēce.
Ar minimālām sistēmām, kas sastāv no mazām sastāvdaļām, kas paredzētas vienas lietas veikšanai un veiksmīgai veikšanai, uzlabojas atkārtotas izmantošanas līmenis, kā arī sistēmas stabilitāte. Turklāt jūsu sistēmas uzturēšana stiprinās, un nākotnes prasības var pievienot daudz vieglāk.
Piezīmes:
Papildus iepriekš uzskaitītajiem risinājumiem izmantojiet dizaina modeļus - tie ievērojami uzlabo jūsu sistēmas dizainu. EJB modelis pats par sevi daudz izmanto dizaina modeļus. Piemēram,
Mājas
katra EJB interfeiss ir Finder un Factory modeļa piemērs. EJB attālā saskarne darbojas kā starpnieks faktiskai pupiņu ieviešanai, un tai ir galvenā nozīme konteinera spējā pārtvert zvanus un sniegt tādus pakalpojumus kā pārredzama slodzes līdzsvarošana. Ignorējiet dizaina modeļu vērtību jūsu briesmās.
Vēl viena briesma, no kuras es pastāvīgi brīdinu: EJB izmantošana tā labā. Dažas jūsu lietojumprogrammas daļas var tikt modelētas kā EJB, kad tām nevajadzētu būt, jūsu viss lietojumprogramma var izmantot EJB, lai iegūtu izmērāmu ieguvumu. Šī ir pārmērīga inženierija, kas novirzīta līdz galējībām, taču es esmu redzējis pilnīgi labas servlet un JavaBean lietojumprogrammas, kas nav saprātīgi tehnisku iemeslu dēļ saplēstas, pārveidotas un ieviestas, izmantojot EJB.
3. bīstamība: prezentācijas loģika netiek nošķirta no biznesa loģikas
Projekta fāze:
Dizains
Ietekmētā (-ās) projekta fāze (-es):
Attīstība
Ietekmētās sistēmas īpašības:
Uzturamība, paplašināmība, veiktspēja
Simptomi:
- Lieli un apgrūtinoši JSP
- Kad mainās biznesa loģika, jūs rediģējat JSP
- Displeja prasību maiņa liek rediģēt un pārvietot EJB un citus aizmugures komponentus
Risinājums:
J2EE platforma dod jums iespēju nošķirt prezentācijas loģiku no navigācijas un vadības, visbeidzot no biznesa loģikas. To sauc par 2. modeļa arhitektūru (laba raksta skat. Resursi). Ja jūs jau esat nokļuvis šajā slazdā, ir nepieciešama stingra refaktorēšanas deva. Jums vajadzētu būt vismaz plānām vertikālām šķēlītēm, kas lielākoties ir pašpietiekamas (tas ir, logrīka pasūtīšana ir atsevišķa šķēle no tā, kā es mainu savu lietotājvārdu vai paroli). Izmantojiet šo netiešo savas sistēmas organizāciju, lai pakāpeniski pārveidotu.
Piezīmes:
Izmantojot konsekventu dizainu kopā ar lietotāja saskarnes sistēmu (piemēram, taglibs), tas arī palīdzēs nodrošināt, ka jūsu projektā tiek novērstas loģiskās atdalīšanas problēmas. Neuztraucieties, veidojot citu GUI sistēmu savām vajadzībām, ir viegli pieejams pārāk daudz labu ieviešanu. Novērtējiet katru pēc kārtas un pieņemiet sistēmu, kas vislabāk atbilst jūsu vajadzībām.
4. bīstamība: neizvietojiet to, kur attīstāties
Projekta fāze:
Attīstība
Ietekmētā (-ās) projekta fāze (-es):
Stabilizācija, paralēli, tiešraidē
Ietekmētās sistēmas īpašības:
Jūsu saprāts
Simptomi:
- Vairāku dienu vai nedēļas garas pārejas uz dzīvām sistēmām
- Risks, kas saistīts ar tiešraides uzsākšanu, ir ievērojams, un daudzi nezināmie un galvenie lietošanas scenāriji nav pārbaudīti
- Dati aktīvās sistēmās nav tādi paši kā izstrādes vai stabilizācijas iestatījumu dati
- Nespēja darboties balstās uz izstrādātāju mašīnām
- Lietošanas uzvedība nav vienāda izstrādes, stabilizācijas un ražošanas vidē
Risinājums:
Danger 4 risinājums sākas ar ražošanas vides patiesu dublēšanu jūsu attīstības vidē. Izstrādājiet tieši tajā pašā iestatījumā, kādā plānojat dzīvot - neattīstieties JDK 1.3 un Red Hat Linux, kad plānojat sākt darboties JDK 1.2.2 un Solaris 7. Turklāt neattīstieties vienā lietojumprogrammu serverī un sāk darboties citā. Iegūstiet arī momentuzņēmumu no ražošanas datu bāzes un izmantojiet to testēšanai, nepaļaujieties uz mākslīgi izveidotiem datiem. Ja ražošanas dati ir sensitīvi, desensibilizējiet tos un ielādējiet tos. Negaidīti ražošanas dati tiks sadalīti:
- Datu validācijas noteikumi
- Pārbaudīta sistēmas darbība
- Līgumi starp sistēmas komponentiem (jo īpaši EJB-EJB un EJB datu bāze)
Vissliktākais, ka katrs no tiem radīs izņēmumus, nulles norādes un uzvedību, kuru jūs nekad iepriekš neesat redzējuši.
Piezīmes:
Izstrādātāji bieži atstāj drošību līdz stabilizācijai ("Jā, ekrāni darbojas, tagad pievienosim lietotāju validācijas lietas."). Izvairieties no šiem slazdiem, drošības ieviešanai veltot tikpat daudz laika kā biznesa loģikai.
