Blog from March, 2008

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... :)

Az objektum orientált programozás terjedésével a monolitikus programokban hívők egyik nagy ellenérve az öröklődéssel és a polimorfizmussal kapcsolatban a túlzott erőforrásigény volt. A JavaSpecialist blog gazdája készített egy mérést, amely alapján mi is készítettünk méréseket, amelyek meglepő eredménnyel zárultak. Egészséges Java öntudattal az ember azt kell gondolja, hogy az interface vagy az abstract osztályok használata nem lassít a program futásán, kis gyanakvással pedig úgy gondolja, hogy "jó-jó, biztos lassít valamit, de nem sokat". Nosza, mérésre fel. Az alapkoncepció egyszerűen az, hogy írjunk egy csomó osztályt, amelyek megvalósítják a tesztelendő folyamatokat:

public class Used
{
  public int echo(int param)
  {
    return param;
  }
}

illetve

public class Use
{
  private final Used used;
  public Use(Used used)
  {
    this.used = used;
  }
 
  public int run(int i)
  {
    return used.echo(i);
  }
}

Ezekből kiindulva csinálunk sima interfész-implementációt, többszörös implementációt, absztrakt-kiterjesztést, többszörös absztakt-kiterjesztést, illetve absztrakt-kiterjesztést továbbörökítünk. A program megméri, hogy 500 millió ciklus mennyi idő alatt fut le a run metódusból, illetve minimumot, maximumot és átlagot számol. Nézzünk néhány mérési eredményt, amelyek különféle JVM-en készültek:

Mint látható, az eredmények igen változatosak... elgondolkodtató, hogy melyik eredményt miért kapjuk... :)

A (NetBeans) projekt, forrásokkal együtt letölthető a Polymorph.zip.