Az utóbbi időben volt szerencsém elolvasni néhány érdekes írást programozástechnikáról. Ez nem arról szól, hogy a Java/C#/C++/Lisp nyelven jó programokat írni (noha az is hasznos olvasnivaló lehet), hanem inkább afféle ötleteket mutat, amik a programozási munka menedzsmentjéhez tartoznak.
Igen, erről nem véletlen, hogy egyeseknek a PT jut eszébe, de szerintem annál jóval gyakorlatiasabb dologról van szó. 🙂 Persze ezt az én erőteljesen elfogult véleményem mondatja csak velem, nyilván másnak ugyanolyan használhatatlan dologról van szó.
Nem tudom, mennyire ismert a „törött ablakok elmélete” (Broken Window Theory), ezért megpróbálom röviden összefoglalni. A fő gondolata, hogy ha egy civilizált környéken betörik egy ablak (lehet autóé, házé), és senki nem foglalkozik vele – itt most nem arra gondolok, hogy aki betörte, annak bűntudata lesz tőle, de azt beleértem, hogy a javítás idejére bedeszkázzák, – akkor ez közepesen hosszú távon (akár néhány hónap alatt) az egész környéken a környék leromlásához, illetve a(z akár súlyosabb) bűnesetek számának növekedéséhez vezethet.
Ez a hatás nagyjából úgy keletkezhet, hogy az emberek azt látják, hogy más nem foglalkozik a problémákkal, ezért nem érzi úgy, hogy neki is tennie kell valamit. Ha valaki kételkedik az állítás igazságában, gondoljon bele, hogy hol szedne fel nagyobb eséllyel véletlenül elejtett papírzsebkendőt: a Nyugatinál a metróaluljáróban vagy egy öt csillagos hotelben a francia Riviérán.
Hogy ez hol jön a programozáshoz? Az elv ott is alkalmazható: ha nem foglalkozol a kis hibákkal, akkor aki később kapcsolódik, azt fogja látni, hogy az elődje sem gondoskodott róla, hogy elkerülje ezeket, ő sem fog vele foglalkozni (annyira). Aki dolgozott már ilyen kóddal, az tudja, miről beszélek. 🙂
Mik ezek a kis hibák? Warningok, hiányzó dokumentáció, nem kifinomult hibakezelés, gányolás… Lehetne még sorolni. És ezeket többnyire csak akkor lehet megfelelően kezelni, ha mindenki az első pillanattól fogva odafigyel ezekre, különben annyira elszaporodnak, hogy a kezelésük szinte reménytelen (próbált már valaki 1000-es nagyságrendben warningokat javítgatni?).
Jó, mi a teendő olyankor, amikor közeleg a határidőt, és még rengeteg mindent implementálni kell? Nos, ekkor jön a Brute Force Development: kódolunk, gányolunk, és reménykedünk, hogy működni fog. Gondolhatnánk, hogy ez rossz, de a gyakorlatban elkerülhetetlen. Ez nagyon gyakran „törött ablakokhoz” vezethet (nem, most kivételesen nem arról beszélek, hogy a legálisan beszerzett Windows-unk crackeltté válik 🙂 ).
Természetesen ez rossz, de mivel elkerülhetetlen, ezért kénytelenek vagyunk kezelni. Erre a kezelésre ad egy módszert a technológiai tartozás (Technical Debth) fogalma.
Ez a valós életbeli adósságok fogalmához kapcsolódik: felveszünk hitelt, hogy valami lehetőséget időben kihasználjunk (nem kell 20 évet várnunk egy lakásra, és közben albérletben élni, hanem most beköltözünk), de ez nincs ingyen (20 évig fizetjük a részletet). Akkor ne vegyünk fel hiteleket? De, ha van valami helyzet, amit így értelmesen kihasználhatunk, hosszabb távon pénzt spórolhatunk meg, akkor fel lehet venni, de ésszel. Nagyon oda kell figyelni a hitelek visszafizetésére (lásd még: válság 🙂 ).
A programozásban ehhez hasonlóan, ideiglenesen nem a legjobb, legügyesebb, legszebb megoldást választjuk, hanem rosszabb megoldást választunk, tákolunk, gányolunk. És mondjuk magunknak dokumentáljuk, hogy mik ezek a részek, és ezzel foglalkozni kell. Mi lehet ennek az értelme? Határidő, esetleg azt mondani, hogy ha működik, akkor kiadjuk, és utána belül foltozzuk a következő verzió fejlesztésének első lépéseként.
De természetesen itt is figyelni kell, ugyanis ha túl sok efféle dolgot hagyunk benne a rendszerben, akkor később ennek az lehet a következménye, hogy ahhoz, hogy új funkciót adjunk hozzá, nagyságrendekkel több munkát kell befektetni, mint az ideális lenne.
Saját tapasztalataim alapján is igazolni tudom ezt az elvet: az elmúlt héten a saját kódomat próbáltam nagyságrendekkel javítani, hogy új funkciókat adjak hozzá. Ok, vettem a fáradtságot, hogy +20% munkával javítsam azt, amit a TDK előtt BFD-vel befejeztem (visszafizettem a technológiai tartozás egy részét), annak érdekében, hogy a rendszer jobban használható legyen.
Remélem, hasznos/érdekes, amit most felvetettem, ha másnak van véleménye, kiegészítése, nagyon szívesen veszem bármilyen formában, más tapasztalataiból tanulni igenis jó dolog. 🙂
Soha nem néztem még ilyen szemszögből ezt a dolgot, bár volt szerencsém tapasztalni. Majdnem egy évig dolgoztam egy olyan programon, amit az utóbbi 10 év alatt egymást váltó fejlesztők sokasága toldozgatott-foltozgatott. A projekt alapjában is hiányolta a tervezés legapróbb nyomait is, és a munkát folytatók megoldásai is amatőr kontárkodásnak tűnik. Ma sem értem hogy sikerült néhány hibát kijavítanom. Nincs rosszabb annál mikor neked kell megfizetned azt a tartozást, amit az elődöd halmozott fel azzal, hogy betört néhány ablakot.
A helyzet ennél rosszabb. Lehet, hogy én nem voltam elég egyértelmű a leírásnál, de nem csak azzal volt a gond, hogy az előd betört néhány ablakot.
Sőt. Az, hogy egy ablak betörik, nem gond, azt be lehet foltozni, esetleg odatenni egy nagy warningot, hogy figyelj, ha ezen a környéken valami gond van, akkor nézd meg ezt a metódust, mert csak gányoltunk – lásd még Java TODO, FIXME, XXX kommentjeit: jelentésük rendre az, hogy valamit még meg kell valósítani, valamit ki kell javítani, vagy nem biztos, hogy működik. Ha leírod, hogy mi a gond, és utána nem foglalkozol vele, akkor csak tartozást kell megfizetni.
Ha sok ilyet nem javítasz ki, akkor kell egy idő után sok tartozást megfizetni, de ezzel még lehet valamit kezelni.
Ha viszont semmi ilyesmi nem történik (értsd: nincs jele, hogy a házon több milliós terhelés van 🙂 ), akkor a kód egyszerűen csak rossz, és aki folytatja, nem érzi úgy, hogy neki oda kell tennie magát, hogy jobb kódot írjon, és a kódbázis minősége ekkor kezd el meredeken lefelé menni.
Az egyedüli módja, hogy a kód minőségét hosszú távon jónak tartsuk, hogy az első pillanattól kezdve mindenki odafigyel a részletekre, és nem hagyjuk, hogy a tartozás nagyon felgyűljön.
Na, befejezem, mert mindjárt még egy ilyen szösszenetnél tartok.