Öregszem. Már nincsen mindenkiről és mindenről olyan hamar kiforrott véleményem, mint régen. És megbocsátóbb is vagyok. Ha valaki bevág elém autóval, veszélyeztetve az épségemet, nem felkoncolnám először, hanem az jut eszembe: biztos jó oka van sietni. Pedig valószínűleg többnyire nincs. A gyerekeimet sem úgy nevelném, mint ahogy tettem, amikor kicsik voltak, és amikor még én is fiatalabb voltam. Ha nem működik rendesen egy szoftver, vagy nincs rendes dokumentációja (ez utóbbira jó példa az Apache Shiro, leánynevén JSecurity), nem dobom rögtön el, mondván: ez szar, tudok ezerszer jobbat írni (pedig de tényleg).
Levelezünk a JavaListán (javalist@javagrund.hu), és vélhetően fiatalabb kollégám szememre veti elnéző megfogalmazásomat. Azt találtam mondani, hogy egy szoftverben nem olyan nagy baj, ha egy hibás használat során (nem felhasználói hiba, hanem programozói hiba, programból nem úgy használunk egy drivert, mint ahogy azt kell) nem definiáltan működik, esetleg nem kezeli le azt a hibát, amelyet nem is ő követett el, hanem az a programozó, aki felhasználta a könyvtárat. Ki lettem oktatva, hogy pedig erre oda kell figyelni, és a konkrét esetben milyen egyszerű lett volna, és írjak csak én is olyan kódot, ami nem dúlja fel az egész rendszert a másik programozó apró hibája miatt.
Ebben igaza van kollégámnak, és meg is írtam neki, hogy egyetértünk. Ha tehetem nem írok ilyen kódot (persze nem szándékosan becsúszhat ilyen hiba, bármilyen: ezért működnek az atomreaktorok 40 éves, kipróbált technológiákkal (remélem)), de ha valakinek ilyen sikerül még nem kiáltom azt, hogy szar. Mert ez van. Ha szar, akkor szar. Akkor ezzel kell trágyázni. De még mindig jobb, mintha még Perl-ben kellene programozni (vagy nem?).
Nem úgy működik a program, mint ahogy várom. Na de hogy jövök én ahhoz, hogy várjak valamit? Maximum a dokumentáció alapján. Mit mond a JavaDoc? Sokszor semmit. Üres, kigenerált oldalak érdemi információ nélkül. Persze a metódusok nevei is lehetnek beszédesek, de azért mégis. A Javadoc az osztály, a metódus specifikációja. Ha nincs, akkor nincs specifikáció. Ha nincs, akkor nem lehet azt mondani, hogy a program unit szinten megfelel a specifikációjának, mert az nincs neki. Akkor azt sem lehet mondani, hogy hiba van benne, vagy, hogy nincs benne hiba.
Ugyanakkor azt látom, hogy olyan fejlesztő csapatok, mint az Atlassian gyakorlatilag nem írnak JavaDoc-ot. Lehetetlen mennyiségű unit tesztjük van (az jó, azt szeretjük), de JavaDoc szinte nulla.
Nemrég debuggoltam egy programot, amit hárman írunk. Nem működött egy funkció. Nézem a kódot: nem rosszul működik, hanem nincs implementálva. Elkezdem írni. Rákeresek egy metódusom nevére: nézd már! Ilyen van máshol is. Akkor ez mégis implementálva lett? És hol használja a projekt ezt az osztályt? Sehol. (bummer). Hogyan kellene használnom (ne írjam meg már mégegyszer). Nézem a kódot: értem. Majdnem jó, de hibás. Beleírok. Fel is kommentelem... hamár. Aztán nézem tovább. Következő metódus. Ez épp azt csinálja, ami az előzőből kimaradt. Ja, hogy ezt meg kell hívni a másik előtt. JavaDoc nem mondta, mert nem volt. Vissza a javításom, JavaDoc módosít.
Hogy csinálja az Atlassian JavaDoc nélkül? És hogyan használjam az Apache Shiro-t rendes dokumentáció nélkül? Hogyan döntsem el, hogy melyik a jövő útja? Apache Shiro? JAAS? Spring Security (leánynevén acegi)? A Seam egyes, erre a kérdésre adott részei? Bezzeg a Microsoft megoldások, vagy az ORACLE. Tonnaszámra van dokumentáció, sokszor nem is rossz, akár bele is fulladhatok.
Erről eszembe jutott az emberorvos, meg az állatorvos története, amikor az állatorvos megbetegedett, kihívta az emberorvost. Megkérdezi az ember orvos: mi a baj? hol fáj? Mire az állatorvos: "Ja, úgy könnyű!"
Hol van a dokumentáció? "Ja, úgy könnyű!"
Persze ha könnyű lenne, akkor nem lenne olyan élvezetes, nagyobb lenne a konkurencia, minden más hülye is programozással foglalkozna, és annyi munka se csurranna, mint amennyi kevés most a válság idején.
Olvasom a kevés dokumentációt az open source programokról... Lesz munkánk.
