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