Döbbenetes hülyeségek élnek a köztudatban arról, hogy mit jelent az a szó, hogy "konzervatív", és mit jelent az a szó, hogy "hagyomány". Roger Scruton megfigyelése mentén - aki szerint mindenki konzervatív abban a szakmában, amihez ért - szeretném most a "legmodernebb" szakmán keresztül bemutatni, hogy ez a szó valójában mit jelent - hogy nem a modernitás és a haladás mint olyan ellenzését, hanem pusztán annak egy aspektusának, egy módszerének ellenzését. Olyan elveket fogok most bemutatni, amelyek a legtöbb programozó számára - igazából a legtöbb műszaki ember számára - természetesenek számítanak, hozzátéve, hogy valójában ezek konzervatív elvek, csak most egy kicsit máshogy fogalmazzuk meg őket.
Modularitás a rendszerekben
Egy nagy rendszer akkor működőképes, ha viszonylag önálló, önszabályozó, egymástól jól
elkülöníthető részegységekből áll - egyrészt ilyenkor sokkal hibatűrőbb, másrészt ilyenkor lehet úgy fejleszteni a rendszert, hogy egy-egy modult cserélünk ki egy újabbra, jobbra - viszonylag alacsony kockázattal. A nagy, monolitikus, piramisszerű rendszerek veszélyesek - agyon kell szabályozni őket ahhoz, hogy működjenek, ám minden egyes újabb szabály újabb kockázati tényezőt jelent, növeli a hibalehetőséget - és ráadásul egy rossz helyen bekövetkező hiba az egész leállását eredményezheti. Tudjátok, hogy működik a Google? Van egy marha nagy szuperszámítógép, ami azt rengeteg keresésést kiszolgálja? Fenét! Kicsi, olcsó gépek ezrei, talán tízezrei vannak összekötve... és nem egy telephelyen és nem egy országban. Egyszerűen - elpusztíthatatlan...Modularitás a módszertanokban
A módszertanok, "legjobb gyakorlatok" úgy alakulnak ki, hogy valaki valamit valahogy megpróbál megoldani, és az sikerül. Ekkor ez bekerül a közös tudáskincsbe - ilyen és ilyen helyzetben ezt és ezt érdemes tenni. A fejlődés sohasem áll meg - de minden egyes lépés egy-egy vagy legfeljebb néhány modul lecserelését jelenti. Olyan nagyon ritkán van, hogy az egész felhalmozott tapasztalatkincset ki kelljen dobni a kukába. Ezt nevezzük hagyománynak - NEM azt, amikor valaki vakon ragaszkodik ahhoz, amit megszokott. Azt hülyének nevezzük. Ragaszkodjunk a pontos definíciókhoz :-) A hagyomány fogalma egészen egyszerűen moduláris fejlődést jelent, amikor egy-egy módszert cserélünk le, nem egyszerre az egészet.
Moduláris fejlődés
Mindebből következik, hogy az igazi forradalmak ritkák és nemkívánatosak. Ennek némileg ellentmond, hogy előszeretettel nevezünk új technológiákat forradalminak. Ez viszont csak retorika, valójában nagyon ritkák azok. Például mostanában a Ruby on Rails "forradalmasítja" a webalkalmazások fejlesztését, de ha jobban megnézzük, ez is csak egy modul kicserélést jelenti. Mert miből is áll egy webalkalmazás? Van egy webszerver, van egy adatbázis, van egy HTML/JavaScript felület, és van a kettő között egy szerveroldali scriptréteg, ami ezt összeköti. Ez a szerveroldali scriptréteg bármilyen olyan programozási nyelven megírható, amire létezik Apache modul - az meg nagyjából mindenre létezik. Namost, egyrészt korábban is használtak Rubyt szerveroldali programozásra - nem sokat, nem elterjedten, de használtak, elég régóta van mod_ruby az Apache-hoz. Másrészt korábban is volt már olyan, hogy a relációs adatbázist objektumorientáltan kezeltek, például Java frameworkok, mint a Hibernate és Struts. A Rails-ben annyi történt, hogy a összrakták a már létező Ruby rugalmasságát ezeknek a már létező objektum-relációs mappereknek a működésével, és az eredmény egy nagyon kényelmes, nagyon kellemes, nagyon kevés konfigurálgatást igénylő szerveroldali framework lett. Forradalomnak nézhet ki, mert akár ötödére is csökkentheti a fejlesztési időt, de valójában ez csak a rendszer egy moduljának kicserélése, két korábban is létező modulra építve, tehát nem forradalom, hanem a moduláris fejlődés egyik lépése, semmi több. Az igaz, hogy nagy lépés a szerencsétlen, éjszakákat átszopó programozónak :-) - de a rendszer egészét nézve ez csak kicsi és korlátozott változtatás.Sandbox-elv
Ez csak annyi, hogy egy új ötletet nem szabadítunk rá egy nagy, éles rendszerre azonnal. Először egy tesztrendszerben próbáljuk ki, aztán egy éles rendszer viszonylag jól elkülöníthető moduljában, hogy minimalizáljuk a kockázatot, és ha az bevált, csak akkor vezetjük be az egész rendszerben. Kísérletezni nem csak hogy szabad, de kell is, csak nem az éles rendszeren.
Az ideológiák kudarca és a tökéletlenség elfogadása
Hogyan kell egy szoftverfejlesztési projektet megtervezni és menedzselni? Egészen sokáig gyakorlatilag a józan ész volt az egyetlen módszertan, ami egészen egyszerűen azt jelenti, hogy az ember a felhalmozott közös tapasztalatkincsre támaszkodva minden helyzetben próbálja megtalálni a legjobb megoldást. Amikor valamilyen bonyolult matematikai modellt kell megvalósítani, akkor pontos specifikációt ír, amikor viszont csak arról van szó, hogy a felhasználónak kényelmes legyen, akkor csak úgy összerak nagyjából valamit, aztán finomítgatja a visszajelzések alapján, és így tovább. Természetesen ez nem tökéletes. Emberek vagyunk, hibázunk, néha nem elegendő a tapasztalatunk, néha figyelmetlenek vagyunk. Valahol a józan ész arról szól, hogy miközben folyamatosan próbáljuk egyre jobban csinálni a dolgokat, tudjuk és elfogadjuk, hogy tévedhetünk és tévedünk is (ezért kell a sandbox-elv), és sohasem lehet valamit tökéletesen csinálni. Más kérdés, hogy akiben van egy adag szakmai büszkeség, az törekszik arra, hogy elegáns megoldásokat hozzon létre - de tökéleteset nem lehet.
Az ideológiák akkor jönnek létre, amikor olyan emberek, akik összeolvastak egy csomó marhaságot, de gyakorlati tapasztalatuk nem sok van, kitalálják, hogy az egész tudáskincs úgy, ahogy van rossz, és a tökéletlen megoldásoknak nem az ember tökéletlen mivolta az oka, hanem csupán a rossz módszertan - tehát azt el kell hajítani, és egy alapjaiban, radikálisan új módszertant követni. A következő lépésben dörzsölt és gátlástalan emberek lépnek a színre, akik saját céljaik - a politikában hatalom, az informatikában inkább csak pénz - érdekében magukévá teszik ezeknek a naív marháknak a jól hangzó elképzeléseit, mert tudják, hogy egy csomóan be fogják kajálni őket.
Ilyen ideológia volt például a nyolcvanas években elterjedt, és Magyarországon sajnos a mai napig uralkodó "vízesés-módszer", hogy először pontosan le kell írni a szoftverrel szemben támasztott követelményeket, utána leírni a logikai rendszertervet, utána a fizikai rendszertervet, utána megvalósítani, tesztelni stb. Ez azért nem működik, mert egyrészt a felhasználók nem tudják pontosan megmondani, hogy mit akarnak addig, amíg nincs legalább valami, amivel el tudnak játszogatni, másrészt pedig a követlemények folyamatosan változnak, és ez a módszer túl rugalmatlan ahhoz, hogy ezeket a változásokat kövesese, mert mint egy lépcsős vízesésnél, minden új igénynek végig kell mennie ezeken a fázisokon. Ez tehát egyértelműen egy mesterséges ideológia, nem a moduláris tapasztalatkincs része.
Megjelent tehát az először extrém programozásnak, később agilis fejlesztésnek hívott módszertan, ami eleinte nagyon jó ötletnek tűnt, mert éppen a fenti problémákra kínált megoldást, egy sokkal rugalmasabb, egyszerűbb módszertan keretében. Az agilis fejlesztés alapötlete lényegében megegyezik a józan ésszel ill. hagyománnyal: az ember először úgy nagyjából begyűjti a felhasználóktól, hogy mit akarnak, gyorsan összerak egy prototípust, majd ezt ők kipróbálják, elmondják, hogy mi nem jó, ekkor új prototípust készít és így tovább. Ez első körben tehát visszatérést jelentett a hagyományhoz.
Ám hamarosan az agilis programozásban is megjelentek az ideológusok, akik merev módszertant készítettek belőle, mint például a SCRUM, hogy egy iterációnak hány hétig KELL tartania és hány naponta KELL milyen meetinget tartani. Ezáltal ez valaha rugalmas és népszerű módszer is ideológiává vált, ergo: nem működik.
Egész egyszerűen arról van szó, hogy nincs szükség merev módszertanokra, mert a valóság mindig más és más. Okosnak kell lenni, tanulni a tapasztalatokból, tanulni mások tapasztalataiból - ezt hívjuk hagyománynak -, igyekezni egyre jobban csinálni, mindig azt az eszközt használni, ami az adott helyzethez a legjobban passzol, legyen az precíz tervezés avagy "eldobható" prototípusok gyors összedobása - és kész. Ennyi. Nem lesz tökéletes, mert az ember nem tökéletes, de egyre jobb lesz. Ennyit lehet tenni és nem többet.
Van viszont itt valami, amit ki kell emelnünk - és majd egyszer fogok külön is írni róla. Most röviden: létezik egyfajta általánosan elfogadott legenda, hogy a világban mindig minden az egyre nagyobb rugalmasság fele halad, a merev dolgok egyre inkább kimennek a divatból. Ez egész egyszerűen nem igaz. A politikatörténetben is mély megdöbbenésként ért engem, hogy 1940-ben az átlagember, de főleg az átlagos értelmiségi, egyértelműen fasisztoidabb hozzállású volt, egyértelműen kevésbé hitt a szabadságban, mint 1840-ben. Nem csak Mussolini meg Hitler: Amerikában is majdnem gazdasági diktátort csinált
Rooseveltből a New Deal, alig tudták - alkotmányossági alapon - leszerelni a vadabb ötleit. NEM IGAZ, hogy mindig minden a nagyobb rugalmasság és nyitottság irányába fejlődik. Hiszen éppen azért tudom összehozni a konzervativizmust a klasszikus liberalizmussal, mert a hagyomány nagyon sokszor a szabadság hagyománya volt - mert a modernitás, a "haladás" nagyon sokszor a merevebb, agyonszabályozottabb és babonásabb rendszerek irányába történő haladást jelenti! Annyi igaz csak belőle, hogy divatos dolog a nyitottság és rugalmasság NEVÉBEN érvelni, ez igaz, de ettől még sokan vannak, akik csak egy "nyitott vagyok" feliratú dobozba zárják magukat - és zárnának másokat is. Ugyanez történt a programozásban ezzel az agilis fejlesztés c. dologgal - egy rugalmas,
gyakorlatias hozzállásként indult, és ugyanolyan merev rendszer lett belőle, mint az, amelyiket leváltani volt hivatott. Nézzétek meg baloldalt ezt a folyamatábrát! Ez a SCRUM. Ez lenne a rugalmasság és nyitottság? Ne vicceljünk már. Igen, simán létezik olyan, hogy valaki nyitottságról és rugalmasságról dumál, és közben egy merev, fasisztoid ideológiát vezet be. Úgyhogy, vigyázni kell...
Egyszerűség
A bonyolult megoldások hajlamosak nem működni - pontosan azért, mert annyi változó van bennük, amennyit az ember már nem képest áttekinteni. Az is gyakran van egyébként, hogy bonyolult megoldások mögött az egó van - valaki "villantani" akar. Az igazán nagy programozókra az a jellemző, hogy képesek olyan egyszerű kódot írni, amit egy kezdő is meg tud érteni. Különösen a Unix rendszerekre jellemző az egyszerűség mint tervezési filozófia - és jelentem, ezerrel jön a Unix, illetve modern változata, a Linux. (Meg a Macintosh is valójában egy BSD Unix.) Most még nem egyértelmű, hogy "győzni" fog-e a Linux, bár én inkább hiszek az egymás mellett élésben és a választási lehetőségekben, mint valamiféle kizárólagos "Endsieg"-ben, de mindenesetre a növekvő népszerűségének oka a Unix-filozófiára vezethető vissza, ami lényegében nem más, mint az egyszerűség szépsége.
Elegancia és esztétikum
Az a tapasztalat, hogy a praktikusnak látszó, de ronda megoldások hosszú távon nem is
szoktak igazán jónak bizonyulni. Azt hiszem, az ember úgy működik, hogy valaminek a minőségét a szépségén keresztül érzékeljük - a szép annak a jele, hogy jó is. Ezért van értelme szép, esztétikus megoldásokra törekedni akkor is, ha ez az adott pillanatban egy kicsit öncélúnak, drágának, nem kellően költséghatékonynak tűnik, mert hosszú távon megéri.
Néha nem a legjobb a legújabb
A világ második legrégebbi magas szintű programozási nyelve a LISP (az első a FORTRAN) - régebbi, mint az ALGOL vagy COBOL, a C-ről vagy Pascalról nem is beszélve! Mégis, Paul Graham és Robert Morris az egyik LISP-dialektusban építették meg a Viaweb nevű alkalmazást, amit 40 millió dollárért adtak el a Yahoo!-nak, és aztán a Yahoo! Stores lett belőle. Paul Graham egyértelműen állítja, hogy sikerük oka az, hogy LISP-et használtak, mert napok alatt tudtak olyan funkciókat hozzáadni a rendszerhez, ami a konkurrenciának, aki "modernebb" programozási nyelvet (akkoriban főleg C++ és Perl - rég volt) használt, heteket vagy hónapokat vett igénybe. És érdekes, hogy a programozási nyelvek egyre inkább a LISP-fele haladnak "vissza", pl. Guy Steele komolyan állította, hogy a Java célja a C++ programozókat a LISP fele "húzni", és ez úgy félig sikerült is, illetve a már említett Ruby kitalálója is említette, hogy ez voltaképpen akár egy LISP-dialektusnak is tekinthető. Nem megyek most bele a részletekbe, hogy miért, a lényeg az, és ez afféle Zen-koan: nincs és nem létezhet tökéletes nyelv, ám mivel a LISP nem nyelv, ezért tökéletes nyelv :-) Csak az a tökéletes X, ami nem X. Bővebben itt. Na, de nem ez a lényeg, hanem az, hogy a modern programozási nyelvek gőzerővel haladnak vissza a LISP felé, ami bizony az ötvenes évek terméke. Itt is az történt, amit fentebb írtam, hogy a fejlődés nem mindig a nagyobb nyitottság és rugalmasság irányába halad. A LISP végtelenül rugalmas volt - de a hetvenes évektől kezdve elterjedt az a fasisztoid ideológia, hogy olyan programozási nyelvekre van szükség, amik megakadályozzák, hogy a gyengébb programozók nagy hülyeségeket csináljanak. Csak most kezdünk végre rájönni újra arra, amit valójában némi józan ésszel élve mindig is tudtunk, hogy ahogy az ember egyre hülyebiztosabb rendszereket próbál létrehozni, a természet/Isten (tessék választani, részemről: természet) mindig rátromfol azzal, hogy egyre nagyobb és nagyobb hülyéket hoz létre. Tehát nem a hülyebiztosság működik, hanem az, hogy hülyéket el kell küldeni a McDonaldsba, a többieknek pedig olyan eszközöket adni a kezükbe, amivel hatékonyan dolgozhatnak. Nem az a lényeg tehát, hogy valami új-e, hanem hogy jó-e. Nem mindig a legújabb a legjobb - a fejlődés útja eléggé girbe-gurba.
Utolsó kommentek