Blog
Skip to end of metadata
Go to start of metadata

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:

  1. A tervező jobban ismeri a PowerPoint programot, mint a fejlesztőeszközöket.
  2. 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.
  3. 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.
  4. Az alkalmazás szerver reprodukálható hibája lassan - vagy egyáltalán nem javul.
  5. Nehéz olyan fejlesztői gépet találni, amelyen az Enterprise fejlesztőeszközök jól és gyorsan futnak...
  6. 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.
  7. 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á)?
  8. A tervező végletekig a vízesés modell híve, esetleg tele van felkapott szakszavakkal és HBR-ekkel - amúgy szakmailag üres.
  9. 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.
  10. 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.
  11. HA, clustering, és a többi használata már egy "vendégkönyv" összetettségű projekt esetén is.
  12. 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

  1. 7. 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á)?
    Szerintem az, hogy ujrafelhasznalhato komponensekbol allitjuk ossze az alkalmazasunkat, az megfelelo hasznalat eseten gyorsit a fejlesztes meneten. Az eredeti cikkben a csako XML overhead-et irt, na ez peldaul micsoda egy spring alkalmazasnal...

    Mi ennyire erdekes abban, hogy masoknak is van szar projectje?
    1. 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.

  2. 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

    1. 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.

  3. 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.

  4. 2. Pár DVD kell csak és jópár óra elrepül, amíg az alap infrastuktúra (egy alkalmazás- és egy adatbázis szerver) feltelepül a gépedre.

    disk image?

    3. 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.

    +1 Ennek a hatása kb. plusz hetekben mérhető :(

    4. Az alkalmazás szerver reprodukálható hibája lassan - vagy egyátalán nem javul.

    a nem determinisztikusan reprodukálhatóakról nem is beszélve :)

    5. Nehéz olyan fejlesztői gépet találni, amelyen az Enterprise fejlesztőeszközök jól és gyorsan futnak...

    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

    6. 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ópár osztály kell példányosítani.

    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

    1. 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.

  5. 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 :(

    1. 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.

      1. 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ú... (smile)

        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... (smile)