Blog
Skip to end of metadata
Go to start of metadata

Érdekes blogbejegyzést olvashatunk a How to write banking application? címmel, amelyben a szerző bankokban előforduló programok színvonalát mutatja be humoros formában. Lássuk a listát:

  1. A program működését befolyásoló paraméterei közül néhányat tároljuk properties fájlokban, egy részét XML fájlokban, tegyünk belőlük adatbázisba is, illetve legyen beledrótozva a kódba is jó pár.
  2. Használjunk reflection-t illetve dinamikus proxy-kat, ahol csak tudunk. Ahol nem tudunk, ott változtassunk futásidőben a bytecode-on.
  3. Ne adjunk visszajelzéseket, kapjunk el minden kivételt, majd fusson tovább a program. A felhasználónak végképp ne adjunk visszajelzést, kivéve ha a hiba Null Pointer Exception.
  4. Naplózzunk mindent vagy semmit. Ha mindent naplózunk, akkor minden használt keretrendszer is bő lére eresztve naplózzon.
  5. Mindig csináljunk wrapper kivétel osztályt, és csak ettől kezdve írjunk stacktrace-t a naplóba.
  6. Az osztályok mellé adjunk XML konfigurációs és kommunikációs lehetőséget, példányosításkor ennek ellenére követeljük meg a statikus változók használatát.
  7. Találjuk fel a meleg vizet, és fejlesszük ki újra a kereket nulláról. Írjunk saját ORM-et, saját RMI-t, saját gyorstárat, saját GUI keretrendszert, majd ezt teszteljük saját keretrendszerrel. A GUI használjon sok saját widget-et, amelyeket saját script nyelvvel kezelünk, és ezeket jól keverjük össze. Ha kész, írjunk saját benchmark eszközt is, amivel alá tudjuk támasztani, hogy miért csináltuk mindezt.
  8. Legyen a kész programkód mennyisége akkora, amekkora csak lehet. Tegyünk bele egy csomó egyéb osztályt és programkönyvtárat, amelyet nem is használunk. A projekt fordításához követeljünk meg elavult és támogatás nélküli eszközöket, tegyük lehetetlenné a projekt fordítását IDE eszközökből.
  9. Tervezzük sok különálló részből a teljes rendszert, kommunikáljunk FTP protokollon át, adatokat egyszerű fájlokon át cseréljenek a modulok.
  10. A felhasználó közérzete nem fontos, csináljunk lassú és ronda GUI felületet, amely csak több GBájt memória mellett fut.
      
      
Page viewed times

8 Comments

  1. Auth Gábor AUTHOR

    Eddig csak két bank informatikai rendszerének egy részét láttam, de úgy néz ki, hogy valóban van egy ilyen előírás... :)

    Amikor egy paraméterként átadott fájlból beolvassa a program a JDBC kapcsolat paramétereit, majd onnan egy programba drótozott nevű adatbázis táblából kiolvas néhány XML szerkezetet, amelyekben benne van egy újabb JDBC kapcsolat paraméterlistája, illetve pár tábla és mezőnév, a táblán futtatandó elemzések nevei és azok paraméterlistája (amelyet aztán több dispatcher-en át reflection-el meghív)... borzalom. (smile)

  2. Ez ilyen mindennapi agyhalal, sajnos bizonyos helyekre a diploma es a megfelelo megjelenes a belepo, nem pedig a szakmai tudas es a hozzaallas.

    Viszont a torpok elete se csak jatek es mese, ha ez vigasztal :-)

    1. Auth Gábor AUTHOR

      Úgy ki kellett öltöznöm, mintha lakodalomba mentem volna... :D
  3. No, akkor a 25 parameteres fuggvennyel, es az 5 oldalon keresztul kolbaszolo sql - java egyveleggel meg jo vagyok. :)
  4. Unknown User ((k)risztián)

    En meg kiegeszitenem par dologgal:
    11; Adjuk meg a lehetosegek kulso partnereknek a renszerhez valo csatlakozáshoz, úgy hogy
    a; http-n sajat titkosító algoritmust hasznaljunk ami joval gyengebb az ssl-nel
    b; a sajat titlosi library-t csak binarisan(nem byte code, hanem real elf binary) adjuk oda a partnernek, olyan 1992-ben forditott formaban(azota fejlododtt meg a PC architektura is pl 64Bit)
    12; Mindezekhez adjunk olyan dokumentaciot amit egy het elolvasni
    13; Biztositsunk olyan kontactot aki mindig szabadsagon van

    Elso korben talan ennyi...

    1. Hmm, a 11-es pontot csak nem egy bank kulso felulete ihlette?
    2. Azért megjegyzem ez nem teljesen így van. Pl. nem egy külsős fejlesztő megfordult nálunk és néha a hajamat tudnám tépni ha bele kell nyúlni egy kódjukba. Pl.: minden reflection-nel van létrehozva benne :-/ ami egy részt baromság (egy interface-szel megoldható lett volna az egész probléma) más felől meg tetű lassú így.
      1. Mi nem teljesen van hogy? Ezt nem értem.

        A felsorolt 10 pont továbbra is a fejlesztők hibája (most lényegtelen hogy külsős vagy saját). A bank is szerintem egy véletlenszerűen kiragadott, de viszont elég jó példa. Naaagy pénzes vállalatnál mondhatják, hogy höjj, ide nekünk a legdrágább app- és adatbázis szervert, az összes buzzwördöt, meg valami (bunda) csapatot, aki az ajánlatok közül a legolcsóbban lefejleszti a szoftvert, mert valahol spórolni is kell. Olcsó húsnak híg a leve.