É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:
- 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.
- Használjunk reflection-t illetve dinamikus proxy-kat, ahol csak tudunk. Ahol nem tudunk, ott változtassunk futásidőben a bytecode-on.
- 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.
- Naplózzunk mindent vagy semmit. Ha mindent naplózunk, akkor minden használt keretrendszer is bő lére eresztve naplózzon.
- Mindig csináljunk wrapper kivétel osztályt, és csak ettől kezdve írjunk stacktrace-t a naplóba.
- 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.
- 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.
- 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.
- 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.
- 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
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.
Laszlo Hornyak
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 :-)
Auth Gábor AUTHOR
Böszörményi Péter
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...
Böszörményi Péter
Papp György Vilmos
tvik
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.