Joel a szoftverről szoftvermenedzsment egyszerűen

Joel lapja

Gerilla magyar fordítások

Hivatalos fordítások

Nyakig a pácban

Írta: Joel Spolsky (2000. december 2.)
Fordította: Verók István (2003. január 22.)
Még senki sem lektorálta
Az eredeti cikk

A FogBUGZ licenszszerződése egészen a tegnapi napig megígértette a felhasználóval, hogy az nem fogja visszafejteni a programot, meg sem kísérel belepislantani a forráskódba, és módosítani sem fogja. Több becsületes kíváncsiskodó is érdeklődött, mennyibe kerülne egy, saját testreszabásokat is megengedő forráskódlicensz.

Hmmm. Egyáltalán miért is tiltja a licensz a forráskód módosításait? Egyetlen épkézláb ok sem jutott eszembe. Mi több, egész seregnyi ellenérvet találtam, így a licenszszerződést azonnal módosítottam is. Ennek örömére szokás szerint megint elmesélek egy régmúlt időkből származó történetet.

Hajdanában-danában, úgy 1995 táján, a Viacomnál dolgoztam, és sokat próbált úttörők egy kis csapatával különféle Viacom-érdekeltségeknek csinálgattunk weboldalakat.

Azokban az időkben még nem voltak alkalmazásszerverek. A Sybase például olyannyira nem értette az új idők szavát, hogy az Interneten használható adatbázisszoftvereik $150-os licenszdíját a végeredményül kapott webhely minden egyes látogatója után be akarta szedni. A Netscape webszervere az 1.0-ás verzió körül mozgott.

Egy Illustra nevű bátor cég akkoriban kezdte az adatbáziskezelőjét tökéletes webes megoldásként hirdetni. A nagy találmányuk abban állt, hogy némi C-ben írt kódot az adatbáziskezelőhöz linkelve a rendszert egyszerűen lehetett új adattípusokkal felruházni. (Ez persze minden, adatbáziskezeléshez értő programozónak már innen elég veszélyesnek hangzik. C-kódot? Hozzálinkelni? Ojjé!) Az eredeti adattípus-bővítési szándék szélességi és hosszúsági koordinátákkal, idősorokkal és egyéb nyalánkságokkal számolt. Aztán közbeszólt a világháló. Az Illustra kihozott egy „Hálószál” nevű csodát, és hozzá is linkelték a többihez. A félkész állapotban leledző Hálószállal állítólag lehetett adatbázisból adatokat kinyerni és ezekből dinamikus weboldalakat készíteni, ami persze – 1995 lévén – igen elterjedt és égető probléma volt.

Az egyik viacomos kollégámat egy elektronikus kereskedelmi webhely építésével bízták meg, a terméket a közismert videotékalánc, a Blockbuster akarta, nem vicc, CD-k webes árusítására használni. (Hát persze, a Blockbuster névről nyilván mindenkinek ez jut eszébe!) A lényeg, hogy a kollégám fejében az Illustra lépett elő a megoldás tökéletes eszközévé. Az Illustra persze $125 000-ba került, és bár a Viacom eléggé fejőstehén-jellegű volt akkoriban a pénzügyekben, ekkora összeghez azért elég sok tőgyet kellett kézbevenni. A pénz tehát huzamosabb idő alatt gyűlt csak fel. A kollégám még egy „Éhezem, de ez most Illustrára kell!” feliratú papírpoharat is kitett az ajtaja mellé, hogy azzal a pár dollárral is előrébb tartson. Az informatikai osztály nagyfőnöke sokórás kemény tárgyalásokat folytatott az Illustrával, és végül megegyezés született. Feltelepítettük hát az Illustrát és munkához láttunk.

Balszerencsénkre azonban katasztrófa közelgett. Az Illustra Hálószál félkész volta elég gyorsan előtűnt, és szinte semmire nem jutottunk vele. Néhány percenként lefagyott. Amikor futott is, rájöttünk, hogy (életünk egy ritka pillanataként) az általunk valaha látott egyetlen nem-Turing-teljes programozási nyelvvel bizony éppen most akadtunk össze. A licenszfelügyelő modul teljesen váratlan pillanatokban feledkezett el a licenszünkről, ilyenkor a webhely meghalt. Egyszóval nyomasztó emlékeim vannak arról a projektről, a kolléga pedig nemes egyszerűséggel annus horribilisnek (rettenetes évnek) nevezte el azt az időszakot. Amikor tehát rám került a sor: – Joel, csinálj egy webhelyet az MTV-nek, – egyből megállt bennem az ütő. – Ajjaj.

Könyörgőre fogtam. – Ugye nem muszáj Illustrát használnom?

– Nem muszáj, de akkor mit fogsz használni? – Akkoriban egyszerűen nem létezett más alkalmazásszerver. Nem volt PHP, nem volt TCL-ben programozható AOLServer, még a Perl is minden kérés kiszolgálásakor új processzt indított, nem volt penicillin sem, egyszóval rettentő életünk volt.

És a jó hírem függött a dologtól. Akkor jöttem rá, hogy az Illustrában leginkább a fagyás utáni tehetetlenségérzet volt félelmetes – lefagyott, nincs mit tenni. Ha legalább a forráskód meglenne, elmélkedtem, akkor a hiba helyén egy hibakeresővel el lehetne indulni, és lehetne próbálkozni. Valószínűleg egy héten át  kéne (éjszakánként is bentmaradva) más kódjában turkálni, de volna esély. Forráskód nélkül azonban ott állunk nyakig a pácban.

Ekkor érett meg bennem a szoftverarchitektúrák egyik nagy tanulsága: a kívánt feladat létfontosságú részét az ideálisnál eggyel alacsonyabb absztrakciós szintű eszközzel kell megírni. Ha például egy jó kis 3D-s lövöldözős játékot írunk (akkoriban a Quake volt ilyen), és a tömegből a nagyon király grafikánk révén akarunk kitűnni, akkor nem szabad egy valahonnan előszedett 3D-s könyvtárat használni. Saját magunknak kell írni egyet, mert erre épül aztán minden. A DirectX-et és hasonló 3D-s könyvtárakat használó csapatok nem a 3D grafikájuk teljesítményével akarnak piacvezetővé válni. (Hanem mondjuk a csábító történet révén.)

Így hát úgy döntöttem, nem bízom meg mindenféle jöttment alkalmazásszerverekben, inkább a Netscape Server alacsonyszintű API-ját használva C++-ban megírom a sajátomat. Így lehettem csak biztos benne, hogy ha valami balul sül el, akkor a hiba biztosan az én kódomban lesz, és lesz esélyem a kijavítására.

Ez a nyílt forrású és a szabad szoftverek egyik legnagyobb erénye, még ha az embernek tellik is az Illustra $125 000-os pácára: baj esetén a javításra valami esélyünk mindenképpen lesz, a munkahelyünk is megmarad, és az MTV barátságos (bár kissé hiperaktív) embereit sem dühítjük fel.

Rendszertervezéskor a használt eszközöket is el kell dönteni. Jó tervező pedig csak megbízható vagy megjavítható eszközökre támaszkodik. A „megbízható” itt nem feltétlenül egy óriási, elvben megbízható cég (mint az IBM) termékét jelenti, hanem olyat, aminek működéséhez kétség sem fér. Manapság például szerintem a legtöbb Windows-programozó megbízik a Visual C++-ban. Az MFC-be vetett bizalom már nem lesz feltétlen, de az MFC-hez van forrás, a bizalmatlanság ellenére tehát a javítható kategóriába esik, erre persze (például az aszinkron hálózati könyvtár irtóztató szellemi mélységeinek feltárásakor) bőven szükség is lehet. Végeredményben tehát az MFC-re is rábízhatjuk életpályánkat.

Szintúgy az Oracle adatbáziskezelőre, amely közismerten jól működik. A Berkeley DB sem karrierakadály, mert a forráskódjába bele lehet merülni, és a hibákat ki lehet javítani. Nem nyílt forrású és nem is közismert eszközre azonban nagyon nem érdemes alapozni. Kísérletezni esetleg lehet vele, de állást veszélyeztetni – túl kockázatos.

Mindezek számbavétele után az járt a fejemben, hogy a FogBUGZ-ot hogyan tehetném intelligens szakemberek számára is vonzóvá, megbízhatóvá. A terjesztése majdnem mellékesen forráskódban történik – manapság ugyanis így működnek az ASP-oldalak. És ez engem egyáltalán nem zavar. A hibakövető szoftverekben nincsenek furmányos, üzleti titoknak minősülő algoritmusok. Ez az egész terület elég hétköznapi. (Mi több, a szoftverek nagy többségében sincs egyetlen darab furmányos, üzleti titoknak minősülő algoritmus sem. Tény, hogy futtatható állományokat is több-kevesebb (inkább kevesebb) nehézség árán vissza lehet fejteni, de ez közel sem számít annyit, mint a szellemi tulajdonnal foglalkozó jogászok szeretnék.) Nekem egyáltalán nem számít, hogy néhányan belenéznek a kódba, vagy saját használatukra esetleg módosítják is azt.

Szállítótól vásárolt kód saját módosításait még a szállító későbbi verzióinak problémája is sújtja: a saját módosítások maguktól nem fognak átkerülni az új verzióba, a frissítés nem éppen élvezetes feladata ránk marad. De a FogBUGZ esetében ezen is tudok segíteni: a nekem beküldött hibajavításokat mind beolvasztom a következő verzióba. Ezáltal remélhetően tettekkel is azt tudjuk üzenni, hogy (a) a FogBUGZ jól működik, és (b) amikor mégsem, pedig életbevágóan fontos lenne neki, akkor a hiba saját kezűleg is javítható, nem kell kirúgatni magunkat emiatt, valamint (c) ha (helyes) hibajavítás érkezik, akkor az bekerül a hivatalos forrásfába, a következő verziót tehát már nem kell fércelgetni, és ezzel is egyszerűsödik az élet.

Már hallom is a nyílt forrású és a szabad szoftverek rajongóinak kórusát: „Te marha! Nyisd meg teljesen a forrást, és kész! A nyílt forrás mindezekre immunis!” Hát persze. Csakhogy a kis háromfős programozócégem egy hónapjának működési költsége $40 000. A programunkért tehát pénzt kérünk, méghozzá arcpirulás nélkül, mert megéri. Nem állítjuk, hogy nyílt forrásúak lennénk, de mindent megteszünk, hogy a FogBUGZ megbízható választás legyen, és ezért a nyílt forrású világ néhány vonzó tulajdonságát is minden további nélkül magunkévá tesszük.