Nebezpečí projektu J2EE!

V mých různých funkcích jako vývojář, vedoucí vývojář a architekt jsem viděl dobré, špatné a ošklivé, pokud jde o podnikové projekty Java! Když se ptám sám sebe, díky čemu je jeden projekt úspěšný a druhý neúspěšný, je těžké přijít s dokonalou odpovědí, protože úspěch se obtížně definuje pro Všechno softwarové projekty. Projekty J2EE nejsou výjimkou. Místo toho projekty v různé míře uspějí nebo selžou. V tomto článku se zaměřím na to, abych vzal 10 hlavních nebezpečí, která ovlivňují úspěch podnikového projektu Java, a představím je vám, čtenáři.

Některá z těchto nebezpečí jednoduše zpomalují projekt, některá jsou falešnými stopami a další mohou úplně zničit jakoukoli šanci na úspěch. Všem se však dá vyhnout dobrou přípravou, znalostmi o cestě vpřed a místními průvodci, kteří znají terén.

Tento článek má jednoduchou strukturu; Každé nebezpečí pokryji následovně:

Název nebezpečí: Jedna linka popisující nebezpečí
Fáze projektu: Fáze projektu, kde k nebezpečí dochází
Dotčené fáze projektu: V mnoha případech mohou mít rizika vliv na pozdější fáze projektu
Příznaky: Příznaky spojené s tímto nebezpečím
Řešení: Způsoby, jak se nebezpečí úplně vyhnout a jak minimalizovat jeho dopady na váš projekt
Poznámky: Body, které chci předat a které se týkají nebezpečí, ale nezapadají do předchozích kategorií

Jak je uvedeno výše, prozkoumáme každé nebezpečí v kontextu podnikového projektu Java spolu s jeho důležitými fázemi. Fáze projektu zahrnují:

Výběr dodavatele: Proces výběru nejlepší možné kombinace nástrojů před zahájením projektu J2EE - od aplikačního serveru až po vaši značku kávy.
Design: Mezi přísnou metodikou vodopádu a přístupem „kóduj a uvidíš“ leží můj pohled na design: dělám dost designu, abych se mohl pohodlně dostat do vývoje. Svou fázi návrhu považuji za dokončenou, když přesně vím, co stavím a jak to postavím. Kromě toho používám návrhové šablony, abych se ujistil, že jsem se před přechodem do vývoje zeptal na všechny správné otázky sebe a svého navrhovaného řešení. Nebojím se však v této fázi kódovat; někdy je to jediný způsob, jak odpovědět na otázku, řekněme, výkon nebo modularitu.
Rozvoj: Fáze projektu, kde se ukáže množství práce provedené v dřívějších fázích. Dobrá volba nástrojů spojená s dobrým designem nemusí vždy znamenat superhladký vývoj, ale určitě pomůže!
Stabilizace / testování zátěže: V této fázi systémový architekt a projektový manažer uloží zmrazení funkcí a zaměří se na kvalitu sestavení a zajistí, aby bylo možné splnit důležité statistiky systému - počet souběžných uživatelů, scénáře převzetí služeb při selhání atd. Do této fáze by však neměla být ignorována kvalita a výkon. Opravdu nemůžete psát nekvalitní nebo pomalý kód a nechat to opravit až do stabilizace.
Žít: Ve skutečnosti nejde o projektovou fázi, ale o datum vytesané do kamene. Tato fáze je o přípravě. Je to místo, kde se duchové minulých chyb budou vracet k pronásledování vašeho projektu, od špatného designu a vývoje až po špatný výběr prodejců.

Obrázek 1 ilustruje fáze projektu, které jsou nejvíce ovlivněny různými příčinami (a zejména vedlejšími účinky).

No, bez dalších okolků, pojďme se ponořit přímo do top 10!

Nebezpečí 1: Nerozumění Javě, nerozumění EJB, nerozumění J2EE

Správně, pro snazší analýzu rozdělím tento do tří dílčích prvků.

Popis: Nerozumím Javě

Fáze projektu:

Rozvoj

Dotčené fáze projektu:

Design, stabilizace, live

Ovlivněné charakteristiky systému:

Udržovatelnost, škálovatelnost, výkon

Příznaky:

Reimplementace funkcí a tříd již obsažených v základních rozhraních API JDK
Nevím, co je nebo co z toho a co dělají (tento seznam představuje pouze ukázku témat):
- Garbage collector (vlak, generační, přírůstkové, synchronní, asynchronní)
- Když objekty mohou být shromažďovány odpadky - visící odkazy
- Mechanismy dědičnosti používané (a jejich kompromisy) v Javě
- Metoda předjíždění a přetížení
- Proč řetězec java.lang (zde nahraďte svou oblíbenou třídu!) se ukazuje jako špatný výkon
- Pass-by referenční sémantika Javy (versus pass-by hodnotová sémantika v EJB)
- Použitím == versus implementace se rovná() metoda pro nonprimitive
- Jak Java plánuje vlákna na různých platformách (například preventivní nebo ne)
- Zelená vlákna versus nativní vlákna
- Hotspot (a proč staré techniky ladění výkonu negují optimalizace hotspotů)
- JIT a když se dobré JIT pokazí (deaktivováno JAVA_COMPILER a váš kód běží dobře atd.)
- Kolekce API
- RMI

Řešení:

Musíte zlepšit své znalosti jazyka Java, zejména jeho silných a slabých stránek. Java existuje mnohem víc než jen jazyk. Stejně důležité je pochopit platformu (JDK a nástroje). Konkrétně byste se měli stát certifikovaným programátorem Java, pokud ještě nejste - budete se divit, kolik jste toho nevěděli. Ještě lépe, udělejte to jako součást skupiny a tlačte se navzájem. Tímto způsobem je to také zábavnější. Dále vytvořte seznam adresátů věnovaný technologii Java a pokračujte! (Každá společnost, se kterou jsem pracoval, má tyto seznamy, z nichž většina je z důvodu nečinnosti v oblasti podpory života.) Učte se od svých vývojářů - jsou vaším nejlepším zdrojem.

Poznámky:

Pokud vy nebo ostatní členové vašeho týmu nerozumíte programovacímu jazyku a platformě, jak můžete doufat, že vytvoříte úspěšnou podnikovou aplikaci Java? Silní programátoři Java berou na EJB a J2EE jako kachny do vody. Naproti tomu chudí nebo nezkušení programátoři budou konstruovat nekvalitní aplikace J2EE.

Popis: Nerozumím EJB

Fáze projektu:

Design

Dotčené fáze projektu:

Rozvoj, stabilizace

Ovlivněné charakteristiky systému:

Údržba

Příznaky:

EJB, které fungují při prvním volání, ale nikdy poté (zejména fazole bez státní příslušnosti, které se vracejí do připraveného fondu)
Nenávratné EJB
Nevím, za co je zodpovědný vývojář, ve srovnání s tím, co poskytuje kontejner
EJB, které neodpovídají specifikaci (požární vlákna, načtení nativních knihoven, pokus o provedení I / O atd.)

Řešení:

Chcete-li zlepšit své znalosti EJB, udělejte si víkend a přečtěte si specifikaci EJB (verze 1.1 má 314 stránek). Poté si přečtěte specifikaci 2.0 (524 stránek!), Abyste získali představu o tom, co specifikace 1.1 neřešila a kam vás specifikace 2.0 zavede. Soustřeďte se na části specifikace, které vám, vývojáři aplikací, řeknou, jaké jsou právní kroky v EJB. Oddíly 18.1 a 18.2 jsou dobrým výchozím bodem.

Poznámky:

Nedívejte se na svět EJB očima vašeho prodejce. Ujistěte se, že znáte rozdíl mezi specifikacemi, na nichž je založen model EJB, a konkrétním pojetím. Tím také zajistíte, že můžete své dovednosti podle potřeby přenést na jiné prodejce (nebo verze).

Popis: Nerozumím J2EE

Fáze projektu:

Design

Dotčené fáze projektu:

Rozvoj

Ovlivněné charakteristiky systému:

Údržba, škálovatelnost, výkon

Příznaky:

Design „Všechno je EJB“
Ruční správa transakcí namísto použití mechanismů poskytovaných kontejnerem
Zakázkové implementace zabezpečení - platforma J2EE má pravděpodobně nejkompletnější a nejintegrovanější bezpečnostní architekturu v podnikových počítačích, od prezentace až po back-end; to je zřídka zvyklý na jeho plné schopnosti

Řešení:

Naučte se klíčové komponenty J2EE a jaké výhody a nevýhody každá součást přináší tabulce. Pokryjte každou službu postupně; znalosti se zde rovnají síle.

Poznámky:

Tyto problémy mohou vyřešit pouze znalosti. Dobří vývojáři Java dělají dobré vývojáře EJB, kteří mají zase ideální pozici, aby se stali guru J2EE. Čím více znalostí Java a J2EE máte, tím lépe budete při navrhování a implementaci. Věci vám začnou zapadat na místo v době návrhu.

Nebezpečí 2: Přepracování (na EJB nebo ne na EJB)

Fáze projektu:

Design

Dotčené fáze projektu:

Rozvoj

Ovlivněné charakteristiky systému:

Údržba, škálovatelnost, výkon

Příznaky:

Nadměrné EJB
Vývojáři, kteří nemohou vysvětlit, co dělají jejich EJB a vztahy mezi nimi
Nelze opakovaně použít EJB, komponenty nebo služby, pokud by měly být
EJB začínají nové transakce, když bude existovat transakce
Úrovně izolace dat jsou nastaveny příliš vysoko (ve snaze být v bezpečí)

Řešení:

Řešení pro over-engineering vychází přímo z metodiky extrémního programování (XP): navrhujte a kódujte minimum, aby splňovalo požadavky z rozsahu, nic víc. I když si musíte být vědomi budoucích požadavků, například budoucích požadavků na průměrné zatížení nebo chování systému ve špičkách, nezkoušejte druhý odhad, jak bude systém v budoucnu vypadat. Platforma J2EE navíc definuje vlastnosti, jako je škálovatelnost a převzetí služeb při selhání, jako úkoly, které by za vás měla serverová infrastruktura zpracovat.

S minimálními systémy složenými z malých komponent určených k tomu, aby dokázaly jednu věc a dělaly to dobře, se úroveň opětovného použití zlepšuje, stejně jako stabilita systému. Kromě toho se posiluje udržovatelnost vašeho systému a budoucí požadavky lze přidat mnohem snadněji.

Poznámky:

Kromě výše uvedených řešení využívejte návrhové vzory - výrazně zlepšují návrh vašeho systému. Samotný model EJB značně využívá návrhové vzory. Například

Domov

Rozhraní každého EJB je příkladem vzoru Finder and Factory. Vzdálené rozhraní EJB funguje jako proxy pro skutečnou implementaci fazole a je ústřední pro schopnost kontejneru zachytit volání a poskytovat služby, jako je transparentní vyrovnávání zatížení. Ignorujte hodnotu návrhových vzorů na vlastní nebezpečí.

Další nebezpečí, před kterým neustále varuji: kvůli tomu používám EJB. Některé části vaší aplikace mohou být nejen modelovány jako EJB, když by neměly být, vaše celý aplikace může používat EJB bez měřitelného zisku. To je přehnané inženýrství vedené do extrémů, ale viděl jsem dokonale dobré servletové a JavaBean aplikace roztrhané na kusy, přepracované a implementované pomocí EJB bez dobrých technických důvodů.

Nebezpečí 3: Neoddělující logiku prezentace od logiky obchodní

Fáze projektu:

Design

Dotčené fáze projektu:

Rozvoj

Ovlivněné charakteristiky systému:

Udržovatelnost, rozšiřitelnost, výkon

Příznaky:

Velké a nepraktické JSP
Při změně obchodní logiky se ocitnete v úpravách JSP
Změna požadavků na zobrazení vás nutí upravovat a znovu nasazovat EJB a další backendové komponenty

Řešení:

Platforma J2EE vám dává příležitost oddělit prezentační logiku od navigace a ovládání a nakonec od obchodní logiky. Říká se tomu architektura modelu 2 (viz Zdroje pro dobrý článek). Pokud jste již do této pasti spadli, je vyžadována přísná dávka refaktoringu. Měli byste mít alespoň tenké svislé řezy, které jsou z větší části samostatné (tj. Jak si objednám widget, je samostatný řez od toho, jak změním své uživatelské jméno nebo heslo). Tuto implicitní organizaci vašeho systému použijte k refaktorování ve fázích.

Poznámky:

Použití konzistentního designu ve spojení s rámcem uživatelského rozhraní (například taglibs) také pomůže zajistit, abyste se ve svém projektu vyhnuli problémům s logickým oddělením. Neobtěžujte se budováním dalšího rámce grafického uživatelského rozhraní pro své vlastní potřeby, je k dispozici příliš mnoho dobrých implementací. Vyhodnoťte je postupně a přijměte rámec, který nejlépe vyhovuje vašim potřebám.

Nebezpečí 4: Ne nasazení tam, kde se vyvíjíte

Fáze projektu:

Rozvoj

Dotčené fáze projektu:

Stabilizace, paralelní, živé

Ovlivněné charakteristiky systému:

Tvůj zdravý rozum

Příznaky:

Vícedenní nebo týdenní přechody na živé systémy
Riziko spojené s uvedením do provozu je značné, přičemž mnoho neznámých a hlavních scénářů použití nebylo testováno
Data v živých systémech nejsou stejná jako data v nastavení vývoje nebo stabilizace
Neschopnost spustit staví na vývojářských počítačích
Chování aplikace není ve vývojovém, stabilizačním a produkčním prostředí stejné

Řešení:

Řešení Danger 4 začíná věrnou duplikací produkčního prostředí ve vašem vývojovém prostředí. Vyvíjejte na přesně stejném nastavení, na kterém plánujete žít - nevyvíjejte na JDK 1.3 a Red Hat Linux, pokud plánujete žít na JDK 1.2.2 a Solaris 7. Dále nevyvíjejte na jednom aplikačním serveru a aktivovat na jiném. Také si pořiďte snímek dat z produkční databáze a použijte jej k testování, nespoléhejte na uměle vytvořená data. Pokud jsou produkční data citlivá, desenzibilizujte je a načtěte je. Neočekávaná produkční data se rozbijí:

Pravidla pro ověřování údajů
Testované chování systému
Smlouvy mezi komponentami systému (zejména EJB-EJB a EJB-databáze)

Nejhorší ze všeho bude mít každý z nich za následek výjimky, nulové ukazatele a chování, které jste nikdy předtím neviděli.

Poznámky:

Vývojáři často nechávají zabezpečení až do stabilizace („Ano, obrazovky fungují, přidejme nyní informace o ověřování uživatelů.“). Vyhněte se této pasti tím, že implementaci zabezpečení věnujete stejné množství času jako obchodní logice.