Adam Bien összeszedett 12 okot, amelyek miatt a Java EE (és más) projektek sikertelenül záródnak, jobb esetben nem a várakozásoknak megfelelő módon működnek:
- A tervező jobban ismeri a PowerPoint programot, mint a fejlesztőeszközöket.
- Pár DVD kell csak és pár óra elrepül, amíg az alap infrastruktúra (egy alkalmazás- és egy adatbázis szerver) feltelepül a gépedre.
- Jó pár alkalmazás szerver esetén percekig tart, amíg elindul, s szintén percben mérhető idő egy deploy - s ezt naponta tucatnyi alkalommal meg kell tenni.
- Az alkalmazás szerver reprodukálható hibája lassan - vagy egyáltalán nem javul.
- Nehéz olyan fejlesztői gépet találni, amelyen az Enterprise fejlesztőeszközök jól és gyorsan futnak...
- A tervező imádja a rétegeket és a részekre osztott modelleket, s mire egy entitás eljut a perzisztencia rétegtől a prezentációs rétegig, jó sok osztályt kell példányosítani.
- Minden szabadon konfigurálható és cserélhető, emiatt hatalmas az XML adattömeg... felmerül a kérdés: valóban szükséges bármit cserélhetőre készíteni, ha a projektet elfogadták és élesítették (s ezért soha többé nem nyúlnak hozzá)?
- A tervező végletekig a vízesés modell híve, esetleg tele van felkapott szakszavakkal és HBR-ekkel - amúgy szakmailag üres.
- A fejlesztő túlpörgeti magát, komponensek tervezési mintáktól és elegáns megoldásoktól hemzsegnek. Esetleg a laza fejlesztő "csoda, hogy működik" kódot készít.
- A kezdeti fellángolás után - főleg a hosszúra nyúló tervezés és fejlesztés okán - a résztvevők elvesztik lelkesedésüket.
- HA, clustering, és a többi használata már egy "vendégkönyv" összetettségű projekt esetén is.
- A kód QA előírásai (például minden getter és setter dokumentálása) feleslegesen leköti a fejlesztőt és az egekig növeli a fejlesztési költségeket.
Mindez hatványozottan igaz banki szoftverek esetén... :)
Page
viewed times
10 Comments
Laszlo Hornyak
Mi ennyire erdekes abban, hogy masoknak is van szar projectje?
tvik
Nem a csámcsogás érdekes más szar projektjén, hanem hogy hogyan lehetne ezekből a hibákból tanulni. Szerintem a 12-ből jópár visszavezethető arra, hogy nincs igazán profi és tapasztalt vezető fejlesztő, aki tervez, koordinálja a munkát, tartja a frontot a management felé, nem hagyja hogy hülyeséget csináljanak a programozók.
Sok helyen azt látom, hogy a csapatból kijelölnek egy embert a projekt tervezésére (’bazzeg megin én szívok...’) akinek nincs különösebb tudásbeli fölénye a többiekkel szemben. Kialakul egy ’vak vezet világtalant’ helyzet, ami miatt szépen lassan félrecsúszik a projekt.
Auth Gábor AUTHOR
Az utóbbi két hónapban olyan projekten dolgoztam, amelynél a fenti 12 pont mindegyike többé-kevéssé elkövetődött. Tervezési hibák, IBM szoftverek, lassú gépek, az adatoknak 6-8 rétegen kell átjutniuk, mire kikerülnek egy a JSP lapra, egyei TLD-k - arra is, amire van ingyenes keretrendszer, két éve húzódó fejlesztés, értelmetlen QA előírások... :)
És munkahelyváltás után azt látom, hogy nem lesz jobb a következő projekt se... :P
Laszlo Hornyak
Hat akkor felmerul a kerdes hogy vajon jo helyre mentel-e :-)
Egyebkent ezek a csapatepitesi/szervezesi kerdesek tenyleg eleg bonyolultak tudnak lenni. Szerintem csupa uber-hackerbol allo csapatok teljesen mukodeskeptelenek, es ki nem tartja magat uber-hackernek? :-D
Meg egy eszrevetel (bar sok lehetne ezen a cikken): ezek a gebaszok nem csak JEE projectekre allnak.
Szebeni Tamás
Bar meg nekem nincs nagy munka tapasztalatom, de tobb, mint 4 eve fejlesztek Javaban, az utobbi egy evben projectmunkakat vallaltam, es nemreg foallast vallaltam az egyetem mellett, mint Java Programozo (mindharom teruletet beleertve). Az elso heten varhatoan meg is kaptam a feladatom, csatlakozzak egy Struts-os projecthez. Egy het elteltevel, mikor mar atlattam, es elkezdtem volna ujrairni az egyik modult (mert logikai hibaktol hemzseg, es csoda, hogy eddig nem omlott ossze (ertsd ugy, hogy egy beteget sem kezeltek felre...)), erre kitalalja a fonok, hogy hagyjam a jsp/struts projectet, most nehany php-s honlap fontosabb (aminek a projectmanagere egy kozgazdasz), tanuljam meg a nyelvet es kapcsolodjak be, emellett keszitsek marketing tervet egy orvosi eszkoz felhasznalasara es vegezzek is gerillamarketinget internetes forumokon ez ugyben... Kb. mindenki ledobbent, hogy most mit is akar a fonok?! - a programozo marketing tervet keszit, a kozgazdasz koordinalja a fejlesztest... Eloszor nem is tudta, hogy mi a kulonbseg egy jsp app es egy php-s oldal kozott.
Mindezek mellett a honlapok latogatottsagat kellene nehany nagysagrenddel megemelni, cikkekkel, szolgaltatasokkal feltolteni...
Meg probaidon vagyok, es ha kapok versenykepes ajanlatot, nem haboznek., de ha csak marad a jsp project, azt szivesen csinalom, mert azert a munkatarsak rendesek, jo a hangulat.
Kasza Miklós
disk image?
+1 Ennek a hatása kb. plusz hetekben mérhető :(
a nem determinisztikusan reprodukálhatóakról nem is beszélve :)
azért egy kissé erősebb gépen már egész jól megfér egymás mellett egy full-blown eclipse meg egy appserver
a jó tervező gondol arra is, hogy az osztályok példányosítása könnyedén menjen :)
amúgy eléggé igaz ez a 12 pont - sajna
Gábor Garami
Szerintem a jo tervezo eleve keves peldanyositast tervez, mert tudja, hogy ez memoriaigenyes dolog is egyben. Es ugye senki nem szereti, amikor igazza valnak a memek a Java memoriafogyasztasarol.
Unknown User ((k)risztián)
Én webes részen dolgozok(ertd no EJB) de WebService meg hasonlo csodak vannak.
Azert mert az EJB lassu volt nekunk. Igen igy tobbet kell kodolni de szamit a sebesseg.
A 9-est nem szoktam hagyni hogy csinaljak, de nagyobb/ismeretlen fejlesztoi csapat eseteben nem lehet megakadalyozni. 11 nem jellemző szerintem. A tobbi helytálló.
Sajnos :(
Gábor Garami
Nem megakadalyozni kell, csak kordaban tartani. A design patternek alapvetoen jok, hiszen nem veletlenul talaljak ki oket, de a tulhasznalatuk lehet eppoly karos, mint a mellozesuk.
Auth Gábor AUTHOR
Módjával célszerű használni... például EJB3 hívást nem célszerű Command pattern használatával megejteni, ahol a kérés objektum egy Factory-ból esik ki, a metódus meghívása pedig Reflection alapú...
Szerény véleményem szerint a jelenlegi keretrendszerek esetén már nem kell törődni a különféle pattern ismeretekkel, mert a keretrendszer elrejt mindent... mondjuk a keretrendszert fejlesztőknek viszont illene ismernie a tervezési mintákat...