Počas svojich rôznych pozícií ako vývojár, senior vývojár a architekt som videl dobré, zlé a škaredé, pokiaľ ide o podnikové projekty Java! Keď sa pýtam sám seba, kvôli čomu je jeden projekt úspešný a iný zlyhá, je ťažké prísť s dokonalou odpoveďou, pretože úspech sa ťažko definuje pre všetko softvérové projekty. Výnimkou nie sú ani projekty J2EE. Namiesto toho projekty v rôznej miere uspejú alebo zlyhajú. V tomto článku sa chcem zamerať na 10 najdôležitejších nebezpečenstiev, ktoré ovplyvňujú úspešnosť podnikového projektu Java, a predstaviť ich vám, čitateľovi.
Niektoré z týchto nebezpečenstiev projekt jednoducho spomalia, niektoré sú falošné, iné môžu úplne zničiť akúkoľvek šancu na úspech. Všetkým sa však dá vyhnúť dobrou prípravou, znalosťami o ceste vpred a miestnymi sprievodcami, ktorí poznajú terén.
Štruktúra tohto článku je jednoduchá; Každé nebezpečenstvo pokryjem nasledovne:
- Meno nebezpečenstva: Jedna línia popisujúca nebezpečenstvo
- Fáza projektu: Fáza projektu, v ktorej dôjde k nebezpečenstvu
- Dotknuté fázy projektu: V mnohých prípadoch môžu mať riziká vedľajší účinok v neskorších fázach projektu
- Príznaky: Príznaky spojené s týmto nebezpečenstvom
- Riešenie: Spôsoby, ako sa úplne vyhnúť nebezpečenstvu a ako minimalizovať jeho vplyv na váš projekt
- Poznámky: Body, ktoré by som rád odovzdal a ktoré sa týkajú nebezpečenstva, ale nezapadajú do predchádzajúcich kategórií
Ako bolo uvedené vyššie, preskúmame každé nebezpečenstvo v kontexte podnikového projektu Java spolu s jeho dôležitými fázami. Fázy projektu zahŕňajú:
- Výber dodávateľa: Proces výberu najlepšej kombinácie nástrojov pred spustením projektu J2EE - od aplikačného servera až po značku kávy.
- Dizajn: Medzi dôslednou metodológiou vodopádu a prístupom „kóduj a uvidíš“ leží môj pohľad na dizajn: robím dosť dizajnu, aby som sa mohol pohodlne pohybovať vo vývoji. Svoju fázu návrhu považujem za ukončenú, keď viem presne, čo staviam a ako to budem stavať. Okrem toho používam návrhové šablóny, aby som sa ubezpečil, že som pred prechodom do vývoja položil všetky správne otázky seba a svojho navrhovaného riešenia. Nebojím sa však v tejto fáze kódovať; niekedy je to jediný spôsob, ako odpovedať na povedzme výkon alebo modularitu.
- Vývoj: Fáza projektu, kde sa ukáže množstvo práce vykonanej v predchádzajúcich fázach. Dobrá voľba nástrojov spojená s dobrým dizajnom nemusí vždy znamenať superhladký vývoj, ale určite pomáha!
- Stabilizácia / skúška zaťaženia: V tejto fáze systémový architekt a projektový manažér uložia zmrazenie funkcií a zamerajú sa na kvalitu zostavenia, ako aj zabezpečia, aby bolo možné splniť základné štatistické údaje systému - počet súbežných používateľov, scenáre zlyhania atď. Do tejto fázy by sa však nemala ignorovať kvalita a výkon. Skutočne nemôžete napísať nekvalitný alebo pomalý kód a nechať ho opraviť, kým nebude stabilizovaný.
- Naživo: Toto nie je skutočne projektová fáza, je to dátum vytesaný do kameňa. Táto fáza je predovšetkým o príprave. Je to miesto, kde sa duchovia minulých chýb vrátia späť, aby vás prenasledovali vo vašom projekte, od zlého dizajnu a vývoja až po zlý výber dodávateľov.
Obrázok 1 zobrazuje fázy projektu, ktoré sú najviac ovplyvnené rôznymi príčinami (a najmä vedľajšími účinkami).
Potom sa bez ďalších okolkov ponoríme priamo do top 10!
Nebezpečenstvo 1: Nerozumenie jazyku Java, nerozumenie EJB, nerozumenie J2EE
Správne, rozdelím tento na tri čiastkové prvky pre ľahšiu analýzu.
Popis: Nerozumiem Jave
Fáza projektu:
Rozvoj
Dotknuté fázy projektu:
Dizajn, stabilizácia, naživo
Ovplyvnené vlastnosti systému:
Udržateľnosť, škálovateľnosť, výkon
Príznaky:
- Opätovná implementácia funkčnosti a tried, ktoré sú už obsiahnuté v základných rozhraniach API JDK
- Neviem, čo všetko alebo všetko z toho a čo robia (tento zoznam predstavuje iba ukážku tém):
- Zberač odpadu (vlak, generačný, prírastkový, synchrónny, asynchrónny)
- Kedy môžu byť predmety zbierané odpadky - visiace odkazy
- Mechanizmy dedenia použité (a ich kompromisy) v Jave
- Metóda nadmerného jazdenia a nadmerného zaťaženia
- Prečo
java.lang.String(tu si môžete nahradiť svoju obľúbenú triedu!) sa ukazuje ako zlý výkon - Pass-by referenčná sémantika Java (proti sémantike hodnoty pass-by v EJB)
- Použitím
==oproti implementáciirovná sa ()metóda pre nonprimitive - Ako Java plánuje vlákna na rôznych platformách (napríklad preventívne alebo nie)
- Zelené vlákna verzus prirodzené vlákna
- Hotspot (a prečo staré techniky ladenia výkonu negujú optimalizácie hotspotov)
- JIT a keď sa dobré JIT pokazia (deaktivované
JAVA_COMPILERa váš kód beží v poriadku atď.) - Rozhranie API zbierok
- RMI
Riešenie:
Musíte si vylepšiť vedomosti o Jave, najmä o jej silných a slabých stránkach. Java existuje nielen za jazykom. Rovnako dôležité je pochopiť platformu (JDK a nástroje). Konkrétne by ste sa mali stať certifikovaným programátorom Java, ak ním ešte nie ste - budete sa diviť, koľko ste toho nevedeli. Ešte lepšie je to urobiť ako súčasť skupiny a navzájom sa tlačiť. Takto je to aj zábavnejšie. Ďalej vytvorte e-mailovú konferenciu venovanú technológii Java a pokračujte! (Každá spoločnosť, s ktorou som spolupracoval, má tieto zoznamy, z ktorých väčšina je zameraná na podporu života kvôli nečinnosti.) Učte sa od svojich rovnocenných vývojárov - sú vaším najlepším zdrojom.
Poznámky:
Ak vy alebo ďalší členovia vášho tímu nerozumiete programovacím jazykom a platforme, ako môžete dúfať, že postavíte úspešnú podnikovú aplikáciu Java? Silní programátori jazyka Java berú na EJB a J2EE ako kačice na vodu. Naproti tomu chudobní alebo neskúsení programátori skonštruujú nekvalitné aplikácie J2EE.
Popis: Nerozumenie EJB
Fáza projektu:
Dizajn
Dotknuté fázy projektu:
Rozvoj, stabilizácia
Ovplyvnené vlastnosti systému:
Údržba
Príznaky:
- EJB, ktoré fungujú pri prvom volaní, ale nikdy potom (najmä fazuľa bez štátnej príslušnosti, ktorá sa vráti do pripravenej oblasti)
- Nenávratné EJB
- Neviem, za čo je zodpovedný vývojár, v porovnaní s tým, čo poskytuje kontajner
- EJB, ktoré nezodpovedajú špecifikácii (požiarne vlákna, načítanie natívnych knižníc, pokus o vykonanie I / O atď.)
Riešenie:
Ak si chcete vylepšiť svoje vedomosti o EJB, urobte si víkend a prečítajte si špecifikáciu EJB (verzia 1.1 má 314 strán). Potom si prečítajte špecifikáciu 2.0 (524 strán!), Aby ste získali prehľad o tom, čo špecifikácia 1.1 neriešila a kam vás špecifikácia 2.0 zavedie. Zamerajte sa na tie časti špecifikácie, ktoré vám, vývojárom aplikácií, povedia, aké sú právne kroky v rámci EJB. Dobrým východiskovým bodom sú oddiely 18.1 a 18.2.
Poznámky:
Nepozerajte sa na svet EJB očami vášho dodávateľa. Uistite sa, že poznáte rozdiel medzi špecifikáciami, ktoré sú základom modelu EJB, a osobitným zameraním na ne. To tiež zaistí, že budete môcť svoje zručnosti podľa potreby preniesť na iných dodávateľov (alebo verzie).
Popis: Nerozumiem J2EE
Fáza projektu:
Dizajn
Dotknuté fázy projektu:
Rozvoj
Ovplyvnené vlastnosti systému:
Údržba, škálovateľnosť, výkon
Príznaky:
- Dizajn „Všetko je EJB“
- Manuálna správa transakcií namiesto použitia mechanizmov poskytovaných kontajnerom
- Zákaznícke implementácie zabezpečenia - platforma J2EE má pravdepodobne najkompletnejšiu a najintegrovanejšiu bezpečnostnú architektúru v podnikových počítačoch, od prezentácie až po zadný koniec; zriedka sa používa na plné využitie svojich schopností
Riešenie:
Zoznámte sa s kľúčovými komponentmi J2EE a s informáciami o tom, aké výhody a nevýhody prináša každý komponent do tabuľky. Postupne pokryte každú službu; vedomosti sa tu rovnajú sile.
Poznámky:
Tieto problémy môžu vyriešiť iba vedomosti. Dobrí vývojári Java robia dobrých vývojárov EJB, ktorí majú zase ideálnu pozíciu na to, aby sa stali guru J2EE. Čím viac znalostí Java a J2EE vlastníte, tým lepšie budete pri návrhu a implementácii. Veci vám začnú zapadať na svoje miesto v čase návrhu.
Nebezpečenstvo 2: Prepracovanie (na EJB alebo nie na EJB)
Fáza projektu:
Dizajn
Dotknuté fázy projektu:
Rozvoj
Ovplyvnené vlastnosti systému:
Údržba, škálovateľnosť, výkon
Príznaky:
- Nadrozmerné EJB
- Vývojári, ktorí nedokážu vysvetliť, čo robia ich EJB a vzťahy medzi nimi
- Neaplikovateľné EJB, komponenty alebo služby, keď majú byť
- EJB začína nové transakcie, keď sa uskutoční existujúca transakcia
- Úrovne izolácie údajov sú nastavené príliš vysoké (v snahe byť v bezpečí)
Riešenie:
Riešenie nadmerného inžinierstva vychádza priamo z metodiky extrémneho programovania (XP): navrhujte a kódujte nevyhnutné minimum, aby ste splnili požiadavky rozsahu, nič viac. Aj keď si musíte byť vedomí budúcich požiadaviek, napríklad budúcich požiadaviek na priemerné zaťaženie alebo správania systému v špičkách, neskúšajte druhoradé odhadnúť, ako bude musieť systém v budúcnosti vyzerať. Platforma J2EE navyše definuje charakteristiky ako škálovateľnosť a prepnutie po zlyhaní ako úlohy, ktoré by za vás mala serverová infraštruktúra spracovať.
S minimálnymi systémami zloženými z malých komponentov určených na to, aby dokázali jednu vec a robili ju dobre, sa úroveň opätovného použitia zlepšuje, rovnako ako stabilita systému. Okrem toho sa posilňuje udržiavateľnosť vášho systému a budúce požiadavky je možné pridať oveľa jednoduchšie.
Poznámky:
Okrem vyššie uvedených riešení používajte návrhové vzory - výrazne zlepšujú návrh vášho systému. Samotný model EJB vo veľkej miere využíva dizajnové vzory. Napríklad
Domov
rozhranie každého EJB je príkladom vzoru Finder and Factory. Diaľkové rozhranie EJB slúži ako Proxy pre skutočnú implementáciu fazule a je ústredné v schopnosti kontajnera zachytávať hovory a poskytovať služby, ako je transparentné vyváženie záťaže. Ignorujte hodnotu dizajnových vzorov podľa vášho nebezpečenstva.
Ďalšie nebezpečenstvo, pred ktorým neustále varujem: používanie EJB kvôli tomu. Nielenže niektoré časti vašej aplikácie môžu byť modelované ako EJB, keď by nemali byť, vaše celý aplikácia môže používať EJB bez merateľného zisku. Toto je nadmerné inžinierstvo zaberané do extrémov, ale videl som, že úplne dobré aplikácie servletov a JavaBeanov sú roztrhané, prepracované a implementované pomocou EJB bez dobrých technických dôvodov.
Nebezpečenstvo 3: Neoddelenie logiky prezentácie od obchodnej logiky
Fáza projektu:
Dizajn
Dotknuté fázy projektu:
Rozvoj
Ovplyvnené vlastnosti systému:
Udržateľnosť, rozšíriteľnosť, výkon
Príznaky:
- Veľké a nepraktické JSP
- Pri zmene obchodnej logiky sa ocitnete v úprave JSP
- Zmena v požiadavkách na displej vás prinúti upravovať a znova nasadiť EJB a ďalšie komponenty servera
Riešenie:
Platforma J2EE vám dáva príležitosť oddeliť prezentačnú logiku od navigácie a riadenia a nakoniec od obchodnej logiky. Nazýva sa to architektúra modelu 2 (dobrý článok nájdete v časti Zdroje). Ak ste už do tejto pasce spadli, vyžaduje sa tuhá dávka refaktoringu. Mali by ste mať aspoň tenké zvislé plátky, ktoré sú z väčšej časti samostatné (to znamená, ako si objednám widget, je samostatná časť od toho, ako si zmením svoje používateľské meno alebo heslo). Túto implicitnú organizáciu vášho systému používajte na postupné refaktorovanie po etapách.
Poznámky:
Použitie konzistentného dizajnu v spojení s rámcom používateľského rozhrania (napríklad taglibs) tiež pomôže zaistiť, aby ste sa vyhli problémom s logickým oddelením vo svojom projekte. Nerobte si starosti s vytváraním iného rámca GUI pre svoje vlastné potreby, je ľahko dostupných príliš veľa dobrých implementácií. Vyhodnoťte každého postupne a osvojte si rámec, ktorý najlepšie vyhovuje vašim potrebám.
Nebezpečenstvo 4: Nie je nasadenie tam, kde sa vyvíjate
Fáza projektu:
Rozvoj
Dotknuté fázy projektu:
Stabilizácia, paralelné, naživo
Ovplyvnené vlastnosti systému:
Tvoj rozum
Príznaky:
- Viacdňové alebo týždenné prechody do živých systémov
- Riziko spojené s uvedením do prevádzky je značné a veľa testov neznámych a scenárov hlavných použití sa netestuje
- Údaje v živých systémoch nie sú rovnaké ako údaje vo vývoji alebo stabilizácii
- Neschopnosť spustiť stavia na vývojových strojoch
- Správanie sa aplikácií nie je rovnaké vo vývojovom, stabilizačnom a produkčnom prostredí
Riešenie:
Riešenie hry Danger 4 začína vernou duplikáciou produkčného prostredia vo vašom vývojovom prostredí. Vyvíjajte na presne rovnakom nastavení, aké máte v pláne žiť - nevyvíjajte na JDK 1.3 a Red Hat Linux, ak plánujete ísť naživo na JDK 1.2.2 a Solaris 7. Ďalej nevyvíjajte na jednom aplikačnom serveri a zverejniť na inom. Získajte tiež prehľad údajov z produkčnej databázy a použite ich na testovanie. Nespoliehajte sa na umelo vytvorené údaje. Ak sú výrobné údaje citlivé, desenzibilizujte ich a načítajte. Neočakávané výrobné údaje sa zlomia:
- Pravidlá overovania údajov
- Testované správanie systému
- Zmluvy medzi komponentmi systému (najmä EJB-EJB a EJB-databáza)
Najhoršie zo všetkého je, že každé z nich bude mať za následok výnimky, nulové ukazovatele a správanie, ktoré ste nikdy predtým nevideli.
Poznámky:
Vývojári často nechávajú zabezpečenie až do stabilizácie („Áno, obrazovky fungujú, teraz pridajme informácie o overovaní používateľov.“). Vyhnite sa tejto pasci tým, že implementácii zabezpečenia venujete rovnako veľa času, ako tomu je v prípade obchodnej logiky.
