A Törött Ablakok Elmélete

Ne élj együtt a törött ablakkal!

Andy Hunt és Dave Thomas a Pragmatikus Programozók, akik a minőségi szoftver létrehozásának elismert nemzetközi szakértői. A szoftverfejlesztés során követendő gyakorlatról szóló sikerkönyvük, A Pragmatikus Programozó: szakmunkásból mester, a fejlesztés közben felmerülő kérdések széles körét érintő jótanácsokkal van tele. Szintén ők a szerzői a Ruby Programozás: útmutató a Pragmatikus Programozónak c. könyvnek és a híres Agilis Nyilatkozat megírásában is segédkeztek.

A mesterségbeli tudás és a katedrális

Bill Venners: A PP könyv előszavában, Quarry munka-hitvallását idézitek:
Nekünk, akik a csupasz köveket faragjuk mindig látnunk kell magunk előtt a katedrálist is.

Majd, azt mondjátok: „A projekt struktúráján belül mindig van tere az egyéniségnek és a mesterségbeli tudásnak.”

DT: Egy nagyon struktúrált környezetben az emberek hajlamosak feladni a felelősséget. Azt mondják: „Ez többé nem az én dolgom. A főnököm megmondja mit tegyek. Megkaptam a tervet. Csak ezt és ezt a részt kell megcsinálnom.” Ez az analógia a kőművessel, aki a hatalmas egésznek egy nagyon kis része. A valóságban a katedrálist építő kőművesek komoly, nagytudású mesteremberek voltak. Mindig tudatában voltak annak a ténynek, hogy a munka, amit végeznek a katedrális külső képét határozza meg. Amit itt mondunk, az az, hogy még ha úgy érezzük is, hogy nincs felhatalmazásunk vagy felelősségünk jól csinálni, a valóságban mégis van. A munkánk minősége fontos. Hozzájárul a projekt átfogó hatásához vagy eredményéhez.

AH: Másrészt ez lehetővé teszi és bátorítja az egyéni ötleteket. De nem vihetjük túlzásba. Katedrálist építünk. Úgy kell kialakítani a vízköpőt, hogy a hely átfogó témájába és koherens hangulatába illeszkedjen. De az egész átfogó tervezési kötöttségein belül megmarad az egyéni ötletesség szabadsága, mellyel a legjobban járulhatunk hozzá az egészhez.

BV: Miért fontos ez?

DT: Két okból. Először is, a programozás nagyon nehéz. Elképesztően nagy elkötelezettséget igényel jól csinálni. Azért, hogy motiváld magad, hogy elkötelezett maradj, büszkének kell lenned arra, amit csinálsz. Ha ehelyett egy mechanikai szerelőszalag melletti munkásnak tekinted magad, akinek egyedüli munkája a specifikáció alapján bájtok produkálása, akkor nem lesz elég érdeklődés benned, ahhoz hogy jól végezd, amit csinálsz. Tehát a globális perspektívából nézve ez nagyon fontos. Személyes szemszögből tekintve, miért kéne olyan munkát végezned, amit nem élvezel? Fontos, hogy élvezd, ha már ennyire elkötelezed magadat egy munkával.

AH: Az egyéni művészi szabadság fontos, mert minőséget eredményez. Példaként vegyük, hogy egy vízköpőt készítesz ennek az épületnek a sarkára. Az eredeti specifikáció vagy nem mond semmit vagy csak azt, hogy olyannak kell lennie, mint ezeknek a szimpláknak. Közben rájösz: „Nézd csak! Ha a vízköpő száját így alakítom, akkor a víz itt jön le és úgy távozik. Ez jobb lenne.” Jobban tudsz reagálni a helyi feltételekre, mint a tervező, aki nem tudott ezekről, nem látta előre őket, vagy nem volt tudomása róluk. Ha a te dolgod az a vízköpő, tehetsz érte valamit és egy jobb végterméket állítasz elő.

A Törött Ablak Elmélet

BV: Mi a törött ablak elmélet?

AH: A városok leromlását tanulmányozó kutatók meg akarták érteni, hogy miért kerüli el a belváros bizonyos részeit szlömösödés, és hogy a közvetlen szomszédság – ugyanolyan demográfiai és ökonómiai adottságokkal – miért válik pokollá, ahová a rendőrök is félnek bemenni. Tudni akarták mi a különbség.

A kutatók csináltak egy tesztet. Vettek egy szép autót, mint pl. egy Jaguár és leparkoltatták New York Dél-Bronx-i részén. Egy rejtekhelyre vonultak vissza és onnan figyelték mi történik. Ott hagyták az autót vagy négy napig és semmi sem történt. Hozzá sem nyúltak. Ekkor odamentek, betörték egy kis oldalsó ablakát és újra elrejtőztek. Nem telt bele négy óra és az autót felfordították, felgyújtották, lecsupaszították – teljesen.

Tovább tanulmányozták a témát és kidolgozták a Törött Ablak Elméletet. Egy ablak betörik egy bérházban, de senki nem javítja meg. Úgy hagyják. Aztán valami más is eltörik. Lehet véletlen baleset, vagy nem, de szintén nem javítják meg. Falfirka jelenik meg. Egyre több sérülés halmozódik fel. Nagyon gyorsan exponenciálissá válik ez a folyamat. A teljes épület leromlik. A bérlők elköltöznek, a bűnözés beköltözik. A játszma elveszett. Mindennek vége.

A törött ablak elméletet metaforaként használjuk a projekten belüli technikai adósságok kezelésében.

BV: Mi az a technikai adósság?

AH: Ez egy kifejezés a Ward Wiki-ből. Minden alkalommal, mikor elhalasztasz egy javítást, egy adósságot hozol létre. Tudhatod, hogy valami rossz, de éppen akkor nincs időd megjavítani. Bumm! Megy a főkönyvbe. Adós lettél. Van valami, amit meg kell javítanod. A valódi adóssághoz hasonlóan, ez rendben van, ha kezeled. Ha van néhány ilyened – akár jónéhány is – ha ura vagy a helyzetnek, rendben van. Elkészülsz egy új verzióval időben. Aztán visszatérsz és megfoltozol néhány dolgot. De a valódi adóssághoz hasonlóan, könnyű oda eljutni, mikor nem fizeted vissza, mikor olyan sok problémád lesz, hogy sohasem térsz vissza és oldod meg őket.

DT: Az aktuális hasonlatom erre a bejövő leveleimé. Ugyanis időnként megvan az a szokásom, hogy nem válaszolom meg a leveleket egy ideig. És aztán eljutok odáig, mikor kb. 250 ilyen lesz, mikor hirtelen rájövök, sosem fogom őket megválaszolni.

BV: Hogyan hozható kapcsolatba a technikai adósság a törött ablakok elméletével?

AH: Nem akarod hagyni, hogy a technikai adósság kicsússzon a kezedből. Meg akarod állítani a kis problémákat mielőtt nagyokká válnak. Guiliani főpolgármester használta ezt a megközelítést nagyon sikeresen New York városban. Nagyon szigorúan ügyelt olyan kisebb együttélési szabályok megszegésére, mint pl. az úttesten nem megengedett helyen történő átkelés, falfirka, kéregetés – szabályszegések, melyek úgy gondolhatjuk nem számítanak, - és így sikerült nagymértékben lecsökkentenie az olyan komoly bűnesetek mértékét, mint gyilkosság, csempészet, rablás kb. 4,5 -5 év alatt.

A pszichológia területén ez lényegében működik. Ha teszel azért, hogy a kis problémákat kézben tartsd, nem növekednek és válnak naggyá. Nem okoznak további kárt. A rossz kód a saját funkciójához nem kapcsoltan jelentős mértékben járulhat további problémákhoz. A rendszer más részeiben is elkezd gondot okozni, ha nem uralod. Tehát nem akarsz törött ablakokat a projektedben.

Mihelyt valami rossz lesz – legyen az hiba a kódban, probléma a folyamatban, rossz igény, rossz dokumentáció - valami, amiről tudod, hogy nincs rendben, tényleg meg kell állnod, ott és akkor meg kell oldanod. Javítsd csak ki. És ha nem tudod éppen megtenni, keríts köré kordont. Jól jelöld meg! Legyél biztos benne, hogy mindenki tudja, nincs rendben és hogy nem szabad megbízniuk benne, a közelébe se menjenek! Ahogy valami problémás lesz és nincs kijavítva, elkezd rossz közérzetet terjeszteni a csapaton belül. „Nos, ez nem OK. Ó, hát éppen elrontottam.”

Törődj vele, hogy mások is így tegyenek

DT: A lényeg az, hogy mutasd, odafigyelsz. Vegyünk például olyan kódot, amit a csapat használ, de elsődlegesen az enyém. Vannak benne részek, melyek nyilvánvalóan rosszak, de nem úgy látszik, hogy foglalkoznék velük. Úgy hagyom őket. Bárki, aki e modult látja azt mondhatja: „Nos, Dave nem törődik evvel. Ez az övé. Miért kéne, hogy engem zavarjon?” Tulajdonképpen, ha a modulomban írsz valami mást, ami rossz, azt mondhatod: „Dave nem törődik vele, nekem miért is kéne?” Ez a fajta lepusztulás megtörténik a kódrészletekkel és a bérházakkal egyaránt.

Másrészt, tegyük fel, hogy észreveszek egy határesetet a kódomban, ami nem működik. Tudom, hogy hiba, de nem kritikus az alkalmazás mindennapjaiban és most nincs időm kijavítani. Legalább egy megjegyzést odarakhatok. Vagy, ami még jobb, egy assertion-t, így ha bármikor erre az ágra téved a végrehajtás, valami történni fog, ami mutatja, hogy kézben tartom a helyzetet. Evvel mindenekelőtt könnyebbé tettem a probléma azonosítását. De azt is mutatom másoknak, hogy mennyire törődök vele, így ők is javíthatják a hibákat, ha találkoznak velük.

AH: Ha bekerülsz egy projektbe, ami csak döcög, - mindenhol hibák, a fordítás nem egészen működik – nem fogsz nagy késztetést érezni, hogy a legjobbat nyújtsd. De, ha egy olyan projekt része leszel, ahol minden takaros, akarsz az első olyan lenni, aki hibás kódot ír?

BV: A könyvetekben leírtok egy történetet egy tapéta tűzről.

AH: Az egy igaz történet. Egy korábbi könyvelőm Connecticut-ban egy nagyon előkelő, gazdag városrészben lakott, egy szuper lakosztályban. Volt egy tapéta darab az egyik falán, mely kicsit túl közel volt a tűzhöz és egy nap lángra kapott. A tűzoltók kijöttek. A tűz lobogott. A ház kigyulladáshoz közeli helyzetben volt. De a tűzoltók nem törtek ajtóstul a házba. Kinyitották a bejárati ajtót és leterítettek egy kis szőnyeget. És az koszos-mocskos csövet azon csúsztatva eloltották a tüzet. Aztán összetekerték a szőnyeget és elköszöntek.

Még a támadó lángok mellett is, a tűzoltók figyeltek arra, hogy szőnyeget terítsenek le és azon húzzák csöveiket! Különleges figyelemmel voltak arra, hogy ne koszolják össze a srác drága lakását. Krízis helyzet volt, de nem pánikoltak. A tisztaság és rendezettség bizonyos szintjét megtartva oldották meg a problémát. Ezt a fajta hozzáállást akarja elérni az ember egy projekten, mert válsághelyzetek mindig adódnak. A dolgok lángba borulnak és megsemmisülnek. Nem akarsz őrülten fel-alá futkosni és még több bajt okozni, amit aztán szintén ki kell majd javítani. Terítsd le a szőnyeget! Csináld jól!

Forrás

Hozzászólások

ez nagyon teCCett!
valamelyik konyvukbol van, vagy ez egy kulon cikk?

A "minőségi szoftver létrehozásának elismert szakértői". Tök jó. Különösen a szőnyeges példa annak fényében, hogy utána meg a Ruby-ról írnak könyvet. WTF?? Minek a szőnyeg, ha a trágyadombon kell úgyis átvezetni a csövet?

Tényleg szépeket ír, de jobban örülnék, ha szőnyeg fektetés helyett csak simán el lenne oltva a tűz. Meg ne a vízköpő száját alakítsa valaki akkor, ha az épület maga még sehogy nem áll, és előre láthatólag nem is fog. Ez a könyv biblia lesz azoknak, akik ha elkezdenek írni pl. egy fotó kezelő alkalmazást Linuxra, ha kód még nincs is de már 1000 thread van a coding style-ról meg a lokalizációról. Vagy ha van kód, de mondjuk random destroy-olja az archivált adatok 10% -át hetente, akkor továbblépnek a kérdésen és újraírják az about box-ot. Mondván, ha felhalmozzuk a "technikai adósságot", akkor sose lesz megcsinálva a többi se. Jeeeesus!!!

ugy latom semmiben nem ertunk egyet :D
a rubyt nezegettem mar, az "ujhullamos" nyelvek kozul az egyik legszimpatikusabb (osszehasonlitva pl. a pythonnal meg egyeb szornyusegekkel)

amennyire en latom, itt egyaltalan nem arrol van szo, hogy 2 evig ne is kodoljunk, csak tervezgessunk meg beszeljunk rola, hanem arrol, hogy a sajat kis "adagjaert" mindenki felelos, es a leheto legjobban probalja meg csinalni
persze ez onmagaban nem uj elv (igy kene mindig mukodnie)

arrol meg megint sehol nincs szo, hogyha critical bugok vannak benne, akkor leszarjuk, inkabb about boxot irogatunk... sot! inkabb epp az a lenyeg, hogy ha talalunk egy fontos bugot, akkor azt fixaljuk minel elobb, es akkor lepjunk tovabb, ha az mar rendesen mukodik

Pont errol van szo. Nem az about boxot kell ujrairni, hanem a hibas kodot. Nyilvan, ha az about boxban van a hiba, akkor azt, de altalaban nem az szokott lenni.

Nem tudom, en egy feature hianyat valahogy jobban el tudom viselni, mintha random fagy meg crashel a progi. A segfaultot meg ruhellem. Igen, inkabb legyen egy stabil, jol mukodo kod, mely alapot ad a tovabbi fejleszteseknek, mint legyen egy folyamatosan instabil kod, de azert lapatoljuk bele a feature-ket mert az kell a nepnek. Aztan mar senki nem fog emlekezni ra, mi miatt is nem ment tisztessegessen ez vagy az az API.

A Ruby-t pedig nem neveznem tragyadombnak. Nem azt mondom, hogy a C api resze egy csodaszep valami, de sokkal kezelhetobb mint mas nyelveke, nincs tulbonyolitva. Maga a nyelv is nagyon sokszor inkabb segiti, mint hatraltatja a munkat. Nyilvan vannak megszoritasok, melyekkel egyutt kell elni, de minden nyelvnel van ilyen, ezen nincs mit csodalkozni.
--


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

ruby != ruby on rails

Szerintem mindketto szar, de ezen nem fogunk osszeveszni. Mindenki abban kodol, amiben akar. A vizet azert nem kell felkapni. Az jutott eszembe, hogyan ertelmezi a legtobb ember az extreme programming-et. (=jaj de jo, mar tervezni es dokumentalni se kell). Ebbol is csak annyit fognak levenni.

Mármint a belépőszint van alacsonyabban, komoly és egyedi dolgot megvalósítani már épp annyira problémás lehet, mint más frameworkben.

De a belépőszint pl. a festészetben is alacsony, csak veszel vásznat festéket meg ecsetet! Következik-e ebből, hogy kevesebb lesz a tehetséges festő mint régen?

Ebbe jobban belegondolva. Szerinted a mai programozó generáció jó része tizen- huszon-évvel ezelőtt, hogy kezdte?

Szerintem otthoni 8 bites gépen, BASIC-ben. Alacsony belépési szint volt, pár sorban ki lehetett rajzolni valami képet, kiadni valami hangot, vagy szöveges játékokat írogatni...

Akit megragadott ez a világ, az néhány év múlva lecserélte BASIC-et C-re vagy akármire, ami éppen a korszellem alapján jött, és (jó)pár múlva komoly programozó lett.

És most mi ez a vonzó belépési szint: a web. Azt kell vonzóvá és egyszerűbbé tenni az érdeklődőknek. De szerintem egyelőre olyan messze van ez az átlag halandótól, hogy az már fáj... Én mindenesetre örülök, ha valaki kicsit komolyabban is érdeklődik a programozás iránt így is, hogy világosan látszik éveket kell tanulni hozzá. (Basices időkben ez nem volt olyan feltűnő...:)

Maskepp latom. Nap mint nap talalkozom emberekkel, akik _nem latjak ugy_, hogy eveket kellene tanulni ahhoz, hogy akar webet programozz (vagy akarmit csinalj). Egy bizonyos szintig ugyanis tokeletesen el lehet jutni copypaste+howto komboval ugy, hogy fingod sincs, hogy mit csinalsz.

Tizen-huszonevvel ezelott az elso par sor megirasa utan senkinek nem voltak illuzioi ezzel kapcsolatban. A mai "koder Pistike" akkori megfeleloje, a Clipperes Geza mogott valamivel tobb tudas volt.

"Egy bizonyos szintig ugyanis tokeletesen el lehet jutni copypaste+howto komboval ugy, hogy fingod sincs, hogy mit csinalsz."

Amíg nem érti addig úgysem tud egyedit alkotni, amikor meg már kezdi érteni is amit csinál, akkor meg már elindult az úton és csak pár kitartó év kérdése az egész... :)

Szerintem az a baj, hogy elhappolja a megrendelőket. Vagy pedig az, hogy rosszabb lesz a szakma megítélése, és egyáltalán az egész légkör, amiből az következik, hogy azoknak, akik sokat tanultak, csökken az értékük a világ és maguk előtt, ami szar érzés. Ez főleg attól függ, az ember mennyire befolyásolható, vagyis nem Kóder Pistike igazán az oka.

:)

Főleg azért, mert a sok-sok tanulás után gyakorlatban is alkalmaznia kéne a tudását, hátgörnyesztően sokat kódolni, innovatívnak lenni, rugalmasnak és flexibilisnek...
Ráadásul a világ olyan szemét, hogy nem a tudás alapján fizetik az embert.
Borzalom...
--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

miaz h nem a tudas alapjan fizetnek? :-) ezt azert gondold ujra...

egy koderpistike sosem lesz senior valahol, vagy architect. SOHA. mert ott mar gondolkodni is kell, es ha megkerdezik toled, hogy miert jobbak a restful webservicek mint a soaposak, akkor nem tudod kikopzini sehonnan :) (najo, kitudod biztos, de normalisan ervelni nem hiszem..., foleg egy allasinterjun)

Lehet, hogy egyszerűnek hat a ruby, de aki nem ismeri az OOP-t, meg az MVC lelkivilágát, annak elég erősen átláthatatlan, és nem tudja kihasználni a legfontsabb előnyét, az eleganciáját. Azon kívül a ror-hoz nincs közel sem annyi leírás, pláne nem terem minden bokorban ingyenes hosting. A rails egyik előnye, hogy ki lehet használni vele azt, hogy a ruby általános célú nyelv (a php-s cronozgatós-szenvedései helyett tudsz daemonokat csinálni), de ehhez megint nem ingyenes hosting kell (vagy ssh és sok-sok kreativitás :)).

Megnézném én azt, hogy a PHP pistike mikor fog funkcionális teszteket írni :)

"Ubuntu" is an African word meaning "I can't figure out how to configure Slackware"

Azt hittem, h warez windowsról lesz szó :D
________________________________________________
Attól, hogy más hülye, te még lehetnél normális.

Köszi a fordítást, én értem a lényegét.

"Zebedeus jön majd a szolgájával, és azt fogják majd rebesgetni, hogy
eltûntek a dolgok. És hatalmas zûrzavar lesz, hogy hol vannak valójában a
dolgok. És senki nem fogja tudni, hová lettek azok a kis bigyók, meg az a
furcsa kis izé raf-raffiakötõállvány, amihez hozzá voltak erõsítve. És
akkor majd a Barát elveszíti a barátja kalapácsát, és a Fiatal nem fogja
tudni, hogy hol vannak... már azok a dolgok, amiket apáik birtokoltak,
mert apáik csak este rakták oda, este nyolc körül"

Erről az autós történetről eszembe jut egy réges régi vicc...

Tudósok azt vizsgálják, hogy a bolha hallása és a lábai között van-e összefüggés. A bolhát beidomítják, hogy ha azt mondják "Hopp", akkor a bolha ugorjon. Miután sikerült a bolhát erre megtanítani, kezdetét veszi a nagy kisérlet: levágják a bolha egyik lábát, majd azt mondják "Hopp" - és a bolha ugrik. Levágják a bolha második lábát is, a bolha még mindíg ugrik ha azt hallja: "Hopp". Így haladnak szépen sorban, mígnem eljutnak a bolha utolsó lábához. Miután azt is levágták, a bolha már nem ugrik, hiába is mondják neki hogy "Hopp". Így tehát a tudos emberek megállapították: a bolha megsüketül, ha levágják mind a hat lábát...

A bajom meg csak annyi ezzel az autós történettel, hogy nincs olyan hogy Bronxban elbújni. Az őslakosok ismerik a terepet, jobban mint a tenyerüket. Beparkoltak oda egy csoda járgánnyal? Szép! De amíg azt is tudja az őslakos, hogy onnan 50 méterre figyelik az autót, addig bolond lesz hozzá nyúlni, mert nem tudja, mi szakad a nyakába. Naná hogy négy napig ott van őrizetlenül és mégis semmi nem történik. Próbálnának csak oda állni úgy, hogy tényleg ott hagyják, leskelődő állás nélkül! A hátsó ablak betörése az elmélet szerint az "első kis hiba volt", ami "nem került javításra". A valóságban jelzés az őslakosoknak, hogy arra kíváncsiak a bujkálók, hogy hogy is szedik szét a járgányt. Nos, megtették, röpke 4 óra alatt... Ennyi. Csak nem a "nem javított kis hiba" miatt, hanem a jelzés miatt...
De a többi stimmel... :-)

Ezzel együtt azzal a résszel maximálisan egyet tudok érteni, hogy az ember legyen igényes a munkájára és ha meg lehet csinálni jobban, akkor csinálja meg jobban, ha bele lehet tenni hely specifikus dolgokat, akkor szépítse ezzel a kódját - és ha idő szűke vagy bármi egyéb miatt kókányolni kényszerül, akkor azt mindenképpen jelezze a kódban és lehetőleg ne feledkezzen meg róla, hanem mihelyst lehet, térjen vissza hozzá és csinálja meg igényesen.

Mindenkinek szíve joga, hogy miként (ne) értse az ebben leírtakat. Azért szántam időt, energiát a fordításra, mert úgy látom, hogy jobbá válni bármiben elszántság kell, törekvés és tudatosság. Én másik szakmából érkeztem, de állítom, hogy sokkal többet tanultam meg magamtól, mint sok szakmabeli. Mivel kevés mesterember van, azok sem körülöttem, az ilyen írások segítenek. Ezt akartam megosztani másokkal. Ha csak néhány embernek volt hasznos, már megérte. Tképpen a többieknek is jó, mert dühönghetnek egy jóízűt és ennek kapcsán elkezdhetnek beszélni egészen másról is :-)

Az írás szép. De vannak más megfontolások is. Pl. látok programozókat úgy dolgozni, hogy kapnak naponta egy munkalapot az aznapi kódolni valókról, lekódolják, hazamennek, elfelejtik.

Multicégeknél érzékelhető törekvés, hogy meg akarják akadályozni, hogy az "olcsó munkaerő" túlságosan bedolgozza magát egy témába, ezáltal értékessé váljon, ami a munkaadó szempontjából azt jelentené, hogy az alkalmazott kulcspozícióba kerül, nélkülözhetetlenné, a munkaadó meg kiszolgáltatottá válik. Ennek magakadályozására szolgál pl. az alkalmazottak örökös cserélgetése.

Feltételezem, van ennek is valami elmélete. Mármint, hogy hogyan kell úgy megszervezni és működtetni egy rendszert, hogy egyik alkatrész kiesése se legyen kritikus.

--
CCC3

Nem kétlem, h van ilyen. Azt gyanítom, h az ilyen esetekben a kódminőség ugyanúgy erodeálódik egy idő után és majd később jön el az "igazság pillanata". Már ha van bárki is a cégnél, akit ez érdekel vagy éppen észre veszi. Ha kicsit csökken a profit, lehet h többet kérnek a következő megbízás alkalmával, vagy a szolgáltatás/termék árát növelik.

Időnként visszatérek erre a blogbejegyzésre, és elolvasom. Egyszerűen szenzációs.