Joel a szoftverről szoftvermenedzsment egyszerűen

Joel lapja

Gerilla magyar fordítások

Hivatalos fordítások

Lord Palmerston és a programozás

Írta: Joel Spolsky (2002. december 11.)
Fordította: Verók István (2003. január 20.)
Lektorálta: Nagy Balázs (2003. december 1.)
Az eredeti cikk

Valaha az IBM PC-k programozását az ember egyetlen Peter Norton-könyv elolvasásával kimerítően megismerhette. Az elmúlt 20 évben pedig egyre újabb és újabb, a PC-programozást könnyítő és segítő absztrakciók kerültek ki szorgos programozók kezei alól.

A szivárgó absztrakciók törvénye következtében azonban a programozást könnyíteni hivatott absztrakciók szaporodásával párhuzamosan a programozói hivatáshoz (pláne egy jó szakembernek) szükséges tudásanyag is egyre csak nő.

Egyetlen programozási nyelv kiismerése (annak minden zegzugával együtt) is évekbe telik. Sok fürge eszű tizenéves persze egy hét alatt meg tudja tanulni a Delphi-t, a rákövetkezõ héten a Python-t, ezek után újabb egyhetes elfoglaltságnak beférhet a Perl is, és ettől tapasztalt kódiparosnak hiszik magukat, miközben halványlila fogalmuk sincs a tudásuk tényleges hiányosságairól.

Jómagam az ASP és a VBScript első megjelenése óta dolgozom ezekkel. A VBScript-nél girnyóbb nyelvet még nem hordott hátán a Föld, az ASP pedig mintegy 5 osztály ismeretét takarja, ezekből talán kettő a gyakrabban is használatos. És mégis csak mostanra tapasztaltam ki, hogy hogyan érdemes ASP/VBScript alkalmazásokat készíteni. Mostanra érett meg bennem, hogy hol van az adatbázis-elérő kód természetes helye, hogy hogyan lehet az ADO-val a legjobban rekordok közt turkálni, hogyan érdemes a HTML-t és a programkódot különválasztani, stb. A saját különbejáratú szöveggyúró függvényeimről is csak mostanra szoktam át a reguláris kifejezésekre. Az újrafordítandó COM-objektumok (webszerver újraindítása nélküli) memóriából kiirtásának művészetét pedig csak egy hete sajátítottam el.

Cégem, a Fog Creek túl kicsi, nincsenek különféle területekre szakosodott specialistáink. Amikor a FogBUGZ (ASP/VBScript termékünk) remekbe szabott telepítőjét bűvöltem, építenem kellett többéves C++/MFC-tapasztalatomra, a Windows API-ban szerzett jártasságomra, a varázsló sarkába tett képhez pedig a Corel PhotoPaint elfogadható ismerete kellett. A FogBUGZ zökkenőmentes Unicode-kezeléséhez C++-ban (ATL-lel) kellett egy rövidke ActiveX-kódot összehoznom, amiben segítségemre volt többéves C++- és COM-tudásom, na meg a CityDesk fejlesztésekor karakterkódlapokkal eltöltött egy hét is.

A fentiek tükrében talán nem meglepő, hogy egy fura, csak NT 4.0-n előjövő hiba kijavítása mindössze 3 percemet vette igénybe, hiszen régebben már használtam VMWare-t, azalatt telepítve is volt egy sima NT 4.0, a Visual C++-os távoli hibavadászat sem volt újdonság számomra, valamint a függvény visszatérési értékét az EAX-regiszterbe helyező hívási konvenciót is ismertem. Előzetes tapasztalatok híján más egy órát is eltölthetett volna ezen, nekem azonban segítségemre voltak az (1982-es első PC-m és Norton-könyvem óta egyre gyülemlő) ismereteim.

A szivárgó absztrakciók miatt a tanulandók mennyiségét ábrázoló időfüggvény egy hokiütő alakját követi: a nap mint nap használt dolgok 90%-a egyheti tanulással elsajátítható. A maradék 10% azonban több év lefolyása alatt csordogál be. A valóban szerteágazó tapasztalatokkal bíró programozók ezért jobbak a „mit nekem akármilyen feladat, könyvből sitty-sutty elsajátítom” mentalitásúaknál. Csapatépítéskor ügyelni kell tehát, hogy a kód nagy részét absztrakt eszközökkel kitermelő, kevésbé tapasztalt kódolók mellett legyenek igazán tapasztalt, a fogós problémákat is megoldani tudó tagok is, különben az egész kudarcba fullad.

A programozás sok világra oszlik, az igazán készségszintű használat azonban mindegyikben hatalmas tudásanyagra épül. Jómagam e háromban vagyok leginkább otthon:

• MFC/C++/Windows
• VBScript/ASP
• Visual Basic

Alapvetően mind a Windows-programozás körébe esik. Igen, írtam Unix és Java programokat is, de nem sokat. Az én saját lételemem azért leginkább a Windows-programozás, mert nemcsak az alapvető technológiákat, hanem az egész támogató infrastruktúrát is ismerem. Azt állítom tehát, hogy a jó Windows-programozói készségemet az következő járulékos ismeretek alapozzák igazán meg: COM, ATL, C++, 80x86 assembler, Windows API-k, IDispatch (OLE Automation), HTML, a DOM, az Internet Explorer objektummodellje, a Windows NT és a Windows 95 belső rejtelmei, a LAN Manager és az NT hálózatkezelése, a biztonsági dolgok (ACE-k, ACL-ek, meg minden idevágó), az SQL és az SQL Server, a Jet és az Access, JavaScript, XML, no meg az átfogó négyzetéről szóló néhány egyéb vidám tény. És amikor, teszem azt, a VB StrConv függvénye nem az én szájízem szerint működik, akkor minden további nélkül össze tudok ütni helyette egy COM-vezérlőelemet (hogy meghívhassam a C++-os ATL MLang-függvényeit). Évek kellettek, hogy idáig jussak.

Sok más programozói világ is létezik. A BEA Weblogic alá fejlesztők világa például olyan ismereteket ölel fel, mint a J2EE, az Oracle, és még egy sereg egyéb Javás dolog, amiket még felsorolni sem tudnék. A Macintosh-fejlesztőguruk tarsolyában pedig a CodeWarrior, az MPW, a System 6 és a MacOS X közti összes verzió felhasználóifelület-programozásának részletei, a Cocoa, a Carbon, meg még az OpenDoc-hoz hasonló, mára elavult és hasznavehetetlen ismeretek is lapulnak.

Egy vagy két világnál többet nagyon kevesen látnak át, mivel egyszerűen akkora tudásanyagról van szó, hogy az elmélyült ismeretekhez világonként súlyos éveket kell rászánni.

Tanulni azonban muszáj.

Egyesek elkenődnek, amikor egy állásinterjún Win32 (vagy J2EE, vagy Mac-programozás, mindegy) tapasztalatok hiányában csúsznak el. Vagy azon húzzák fel magukat, hogy tudatlan fejvadászok (akik akkor sem tudnák, hogy most egy MSMQ-t látnak, ha az történetesen éppen leharapná a micsodájukat) telefonon aziránt érdeklődnek, hogy „megvan-e már az ötévnyi MSMQ-juk.”

Huzamosabb Windows-programozási gyakorlat híján az ember azt hihetné, hogy a Win32 is (mint minden osztálykönyvtár) átlátható könyvből, megjegyezhető, az így szerzett tapasztalatok pedig szükség esetén mozgósíthatók. Úgy tűnhet, mintha a C++-tudás (vagy hasonló alapvető programozási készség) lenne úgy 90%, az API-k pedig a pár hét alatt behozható 10%-ot adnák. Az így gondolkodók szíves figyelmébe ajánlom a tényt: az idők változnak. Az arány mára megfordult.

Ma már kevesek dolgozhatnak alacsonyszintű, bitbabráló C algoritmusokon. Legtöbbünk egész munkanapja API-hívásokkal, nem bitmozgatással telik. Egy API-kat nem ismerő, de egyébként fantasztikus C++-programozó az API-kat használó programok írásához kellő mindennapi tudás mindössze 10%-ával rendelkezik. Egy jól menő gazdasági helyzetben ez nem számít. Még így is lehet munkát kapni, a munkáltató pedig fizeti a platform betanulásának költségeit. Egy csehül álló gazdasági helyzetben azonban, amikor minden munkahelyre 600 jelentkező akad, a munkáltató kiválogathatja a kérdéses platformot már kívül-belül ismerőket. Olyanokat, akik Visual Basic kódban négyféleképpen tudnak fájlt FTP-zni, és mindegyik mód előnyeivel és hátrányaival is tisztábn vannak.

E programozási világok hatalmas felszíne értelmetlen egymás közti vitákat szokott provokálni. Ezt a szenteskedő megjegyzést a vitafórumom egyik névtelen hozzászólója tette:

„Már csak ezért is szeretek a 'szabad világban' élni. A felszabadító érzések közt ott a szólásszabadság (majdnem teljesen) valamint a telepítőprogramokkal és rendszerleíró adatbázisokkal vesződés teljes hiánya – egyebek közt.”

Azt hiszem, ezzel az illető azt akarta mondani, hogy a Linux világában nem kell telepítőprogramokat írni. Ebben sajnos muszáj csalódást okoznom, ugyanis éppolyan komplikált dolgokat viszont kell: imake, make, konfigurációs fájlok meg miegymás, a terjesztésre jutó alkalmazásban pedig ott egy 20KB méretű INSTALL fájl, olyan elmés tudnivalókkal, mint „Kelleni fog a zlib” (hogy micsoda?) és „Ez eltart egy darabig. Nyomás kávézni.” Ami pedig a rendszerleíró adatbázist illeti – név/érték párok egyetlen helyre szervezett halmaza helyett ezerféle különböző fájlformátum, minden alkalmazásnak megvan a sajátja, és mind .bigyórc meg izé.conf fájlokkal szemeteli tele a lemezt. Egyszerű beállítások megváltoztatásához is az emacs-ban egyenesen lisp-programozói tudás kell, a különböző parancssori környezetek is mind a saját parancsnyelv-dialektusukhoz ragaszkodnak, és így tovább, és így tovább.

A csak egy világban jártas emberek néha elég undokul tudnak viszonyulni a többiekhez: a többi világ bonyolult részleteit taglaló hírek hallatán azt kezdik hinni, hogy az ő világukban nincsenek túlbonyolítások. Pedig vannak. A hozzáértők már annyira hozzájuk is szoktak, hogy észre sem veszik azokat. A világokat tehát már lehetetlen közvetlenül egymással összehasonlítani, annyira szerteágazóra nőttek. Lord Palmerston mondta: „A schleswig-holsteini kérdés annyira bonyolult, hogy az idők során mindössze három európai látta át. Egyikük a néhai Albert herceg volt. A második egy német professzor, aki megőrült. A harmadik én vagyok, de én már elfelejtettem az egészet.” A szoftvervilágok olyan hatalmas kiterjedésűek, bonyolultak és sokrétűek, hogy amikor egyébként intelligens emberek webnaplójában „a Microsoft nem ért az operációs rendszerekhez” jelentés nélküli, indokolatlan kitételt olvasom, akkor csak magukat teszik nevetségessé. Hogy is lehetne sokezer programozótól származó, évtizedek alatt felgyűlt, többszáz nagyobb funkciócsoportot implementáló sokmillió kódsort így összefoglalni, mikor ennek többségét senki sem tudja átlátni sem? Ezzel még csak nem is védem a Microsoftot, szerintem csupán a mély tudatlanságból tett nagy elkenő általánosítgatásoknál manapság kevés nagyobb időpazarlást lehetne találni a hálón folyó eszmecserék közt.

Hűséges olvasóimnak már bizonyára feltűnt, hogy foglalkoztat az alkalmazások Linux-, Macintosh- és Windows-verzióinak készítése, de az első kettőre persze nem akaródzik aránytalanul sokat ráfordítanom. Szükség van tehát valamifajta többplatformos könyvtárra.

A Java ugyan megpróbálta betölteni ezt a szerepet, de a Sun nem értett eléggé a grafikus felhasználói felületekhez, az eredményből tehát hiányzik a nagyon beolvadó, natív kinézet. Mint a Star Trek egyik űrlénye, aki teleszkópon át figyelte meg a Földet: ismerte az emberi étel kinézetét, de az íz fontosságát nem értette meg. A Java alkalmazások menüi jó helyen vannak, de a kiosztott gyorsbillentyűk minden más Windows-alkalmazásétól elütnek, a füles párbeszédablakok pedig őszintén szólva rémesen néznek ki. Arra pedig végképp nincs lehetőség, bármennyire is próbálkozik az ember, hogy a menüsorok pontosan az Excel menüsoraira hasonlítsanak. Miért? Mert még ha az absztrakció csődöt mond is, a Java nem ad lehetőséget a natív funkciók elérésére. Az AWT-ben programozva nem tudható az ablak HWND-je, nem hívhatók a Microsoft API függvényei, és természetesen nem lehet elkapni a WM_PAINT eseményt, hogy ott rajzoljunk ki mást. A Sun pedig a napnál is világosabbá tette, hogy ha valaki ilyesmikre vetemedne, akkor az már nem Tiszta. Hanem Szennyezett, vagy mi, és pokolra az ilyenekkel.

Néhány, meglehetősen nagy nyilvánosság előtt kudarcba fulladt Javás GUI-projekt után (pl. a Corel-féle Java Office csomag és a Netscape Javagator-a) már elég sokan ódzkodnak ettől a világtól. Az Eclipse-csapat inkább a semmiből megírta a saját, natív elemeket beillesztő ablakozókönyvtárát, csakhogy Javában kódolhassanak, és a végeredmény még viszonylag ésszerű natív kinézettel is rendelkezzen.

A Mozilla kódolói a többplatformos problémát a saját, XUL nevű találmányukkal oldották meg. Ami még rám is mély benyomást tett. A Mozilla mára már ízében is a valódi ételeket idézi. A Mozillában még a kedvenc kákacsomóm, az ablakot minimalizáló Alt+szóköz N billentyűkombináció is működik. Elég sokáig elpepecseltek vele, de végül sikerült nekik.

A Lotust alapító és az 123-at megalkotó Mitch Kapor a készülőben levő következő alkalmazásához a többplatformos támogatás miatt a wxWindows és a wxPython mellett döntött.

Melyik jobb: az XUL, az Eclipse-féle SWT, vagy a wxWindows? Fogalmam sincs. Mind annyira hatalmas világ, hogy nem tudnám mindet bejárni és kiértékelni. Nem elég csak a kézikönyveket olvasgatni. Egy-két évig vért és verítéket kell beleölni valamelyikbe, hogy kiderüljön, tényleg elég jó-e, vagy minden erőfeszítés ellenére sosem fog valódi ételt eredményezni. Elég szerencsétlen módon a legtöbb projektnél az első kódsor megírása előtt kell kijelölni a használandó világot, viszont a legkevesebb információ éppen ilyenkor szokott rendelkezésre állni. Egy előző munkahelyemen egyszer egy iszonyú architektúrát örököltünk, mert a projekt első programozói még csak annak írásakor tanulták a C++-os Windows-programozást. A legrégebbi kód jelentős része az eseményvezérelt programozás elvének leghalványabb megértése nélkül íródott. A minden alapját képező stringosztály (hát persze, hogy sajátot kellett írni) tipikus állatorvosi ló volt: a C++-os osztálytervezés során szóbajöhető összes létező hibát elkövette. Végül a régi kód nagy részét megtisztítottuk és refaktoráltuk, de jó darabig elvesződtünk vele.

Jobb híján ezért a következőket tudom tanácsolni: új projekt indulásakor az adott nyelvben, osztályokban, API-ban és platformokban többévi gyakorlatot szerzett legalább egy guru is kell. Ha a platformot meg lehet választani, érdemes a csapat számára leginkább ismert mellett dönteni (mégha az nem is a legdivatosabb vagy névleg nem a leghatékonyabb). Absztrakciók és programozási eszközök tervezésekor pedig érdemes külön erőfeszítést fordítani a szivárgásmentesítésre.