Skip to content

Értékrendszer

Értékrendszer

A Clean Code fejlesztőknek van egy értékrendszere. Ez a következő négy értékből áll:

  • Továbbfejleszthetőség
  • Helyesség
  • Gyártási hatékonyság
  • Reflektálás

Továbbfejleszthetőség

Ezt a fejezetet egy provokatívnak tűnő tétellel szeretnénk kezdeni:

Nem létezik szoftver-karbantartás!

A karbantartás egy proaktív folyamat. A gyártóberendezésekben rendszeresen cserélnek ki alkatrészeket, mielőtt azok tönkre mennének. Azért cserélik ki őket, mert a tapasztalati értékek azt mutatják, hogy a további üzemeltetés során a megbízhatóságuk a kritikus érték alá csökkenne. Ezért tehát, mielőtt a teljes berendezés leállna, a kritikus alkatrészeket előre kicserélik. Minden gépkocsi-tulajdonos tudja, hogy rendszeresen kell olajcserét végeztetnie. Nem azért, mert ebben az időpontban az olaj elhasználódott volna, és nem is azért, mert az olaj ebben az időpontban teljesen hatástalan lenne. Nem. Azért cserélik ki, mert a gyártó tapasztalati értékei azt mutatják, hogy a motort a megfelelő időben történő olajcsere kíméli, és ezért tovább működik.

Mindez a szoftvereknél nem létezik. A szoftver olyan, amilyen. Általában tartalmaz hibákat. De ezek a hibák is olyanok, amilyenek. Semmit sem lehet proaktívan tenni, hogy az ember javítsa a szoftver állapotát.

A szoftver üzemeltetésénél természetesen vannak proaktív feladatok. Így rendszeresen kellene ellenőrizni, hogy a log-fájloknak van-e elég helye a merevlemezen, hogy az adatbázis nem csordul-e túl, illetve nem tölti-e meg egyre jobban a memóriát. De magát a szoftvert nem lehet proaktívan karbantartani. Mindennemű változtatás vagy bővítés azért történik, hogy egy hibát megszüntessünk, vagy új, illetve megváltozott követelményeket megvalósítsunk.

A lehetséges változtatásokhoz a szoftvernek olyan belső struktúrára van szüksége, amely ezeknek a változtatásoknak kedvez. Ezt nevezzük továbbfejleszthetőségnek. A szoftvereket általában hosszabb ideig használják. Ez alatt az idő alatt megváltoznak a keretfeltételek, új feature-ökkel kell bővíteni. Ideális esetben a feature-ök implementálása egy adott értékbe kerül, amely független attól, hogy mikor valósítják meg a feature-t.

A gyakorlatban azonban egy feature ára emelkedik, minél később kell megvalósítani azt. Az elején a feature-ök olcsók, a végén már egyáltalán nem lehetséges feature-ök beépítése, mert már senki sem rendelkezik a szükséges áttekintéssel. A szoftvert eldobják és újat fejlesztenek. Amíg erre a pontra érünk, a költségek exponenciálisan emelkednek. Az exponenciális növekedésben a következő két dolog igazán durva: 1.) Az elején az ember alig ismeri fel, hogy a költségek növekednek. A növekedés mérsékelt. 2.) Amikor az ember felismeri, hogy a költségek növekednek, akkor már késő. Az emelkedés ilyenkor már olyan gyorsan halad, hogy lehetetlenné válik ellene kormányozni.

Minél egyszerűbben lehet a szoftvert a megváltozott keretfeltételekhez igazítani, annál magasabb a továbbfejleszthetősége. De a továbbfejleszthetőséget nem utólag kapja meg az ember. Azt az elejétől figyelembe kell venni. A szoftvert erre kell kihegyezni.

Egy példa: Az osztályoknak pontosan egy felelősségük kell legyen. Ha egy osztály több mint egy dologért felelős, akkor már nehéz azt megérteni, áttekinteni. Ez akadályozza a változtatásokat, mert azoknak az a feltétele, hogy az ember megértse a forráskódot, amelyet meg akar változtatni. Továbbá megemelkedik az osztályok közötti csatolás (coupling). Hirtelen minden összefügg mindennel. Ezt csak úgy lehet megakadályozni, ha a funkcionális egységeknek világosan meghatározott felelőssége van, és az ember a csatolást (coupling) figyelemmel kíséri. Ha az ember egy szoftverben egy csomó osztályt gyűjtött össze, melyek mindegyike több dologért felelős, akkor ezt az állapotot utólag nagyon nehéz megszüntetni. A csatolás (coupling) olyan erős, hogy nehezünkre esik egyes funkcionális elemeket onnan kioldani. Amennyiben ebben a bozótban új feature-öket kell megvalósítani, akkor ez nagyon költséges lesz. Amennyiben nem kezdjük el a bozótot időben ritkítani, akkor a szituáció minden esettel egyre súlyosabbá válik. Egy bizonyos ponttól kezdve aztán szinte lehetetlenné válik feature-ök hozzáadása. Ez a szoftverfejlesztés magolvadása.

Úgy gondoljuk, hogy nem kell idáig eljutni. Amennyiben az ember a továbbfejleszthetőséget az elejétől szem előtt tartja, akkor a szoftvert hosszú időn keresztül lehet még tovább fejleszteni. A feature-ök költségei az idők folyamán ugyan lassan emelkedhetnek. De semmiképpen sem exponenciálisan!

Helyesség

A szoftvernek funkcionálisan helyesnek kell lennie. Egy könyvelőprogramnak a tételeket helyesen kell elkönyvelnie, egy táblázatkezelőnek helyesen kell számolnia. És a nem funkcionális követelményeket is ki kell elégíteni. A programnak kíméletesen kell bánnia az olyan forrásokkal, mint a memória, a processzoridő, a lemezhely stb., a válaszidőknek egy meghatározott tartományban kell maradniuk. A készített szoftver csak akkor helyes, ha mindezek a követelmények ki vannak elégítve.

Azt, hogy a helyességre szükség van, senki sem fogja vitatni. De a kérdés az, hogy mit lehet tenni ennek érdekében valójában. A meglátásunk szerint nem elegendő az, hogy a szoftvert az elkészítését követően végigvigyük a tesztelőkön, akiknek a feladata a hibák fellelése. Úgy gondoljuk, hogy a helyességet már a fejlesztés folyamán figyelembe kell venni. Már a fejlesztőknek törődniük kell a helyesség kérdésével. És ahhoz, hogy ezt meg tudják tenni, tisztában kell lenniük azzal, hogy mik a követelmények. Már e területen is gyakran hiányosságok vannak. A fejlesztőnek megmondják, hogy egy feature-t kell implementálnia, anélkül, hogy a feature átvételi kritériumaival tisztában volna. De itt nem arról van szó, hogy Fekete Pétert játszunk és a fejlesztési osztályon kívül keressük a felelőst. Végeredményben a fejlesztők feladata az, hogy a homályos követelményeket tisztázzák, ahelyett, hogy a kristálygömbbe bámulnának.

A gépkocsigyártással összehasonlítva a szoftverfejlesztésben a helyesség témakörének rosszul áll a szénája. Egy autó sok alkatrészből áll, melyeknek a helyességét egyenként bizonyítani és ellenőrizni lehet. Gondoljon csak bele, hogy milyen lenne az, ha a hibakereséshez a egy mérőberendezéssel a kezében az autó motorháztetején kellene ülnie, és ott követnie, hogy mi játszódik le a motorban. 200 km/h sebességgel a (német) autópályán. Csodálkozna? A debugger-t gyakran pontosan így használják. Ezt elhibázottnak tartjuk.

Gyártási hatékonyság

A végén természetesen a fejlesztési idő és a szoftver ára játszanak komoly szerepet. És ezek magasabbak, ha a szoftver gyártása nem hatékonyan történik. Ez a kézi munkafolyamatoknál kezdődik, amelyeket nem automatizálnak, és a magas hibarátánál végződik, amely sokszori utólagos javítgatást eredményez. Ennek következtében a gyártási hatékonyság azt jelenti, hogy a szoftvert éveken, illetve évtizedeken keresztül tovább lehet fejleszteni, ahelyett, hogy valamikor újra kelljen kezdeni elölről. Egyidejűleg a magas gyártási hatékonyság a hibákra való hajlamot is csökkenti.

A gyártási hatékonyság, mint érték azért is fontos, hogy a további értékeket mértéktartó arányba helyezhessük. Végeredményben az is hibázik, aki a helyesség érdekében végtelen mennyiségű ráfordítást alkalmaz.

Reflektálás

Visszatekintés nélkül nem lehetséges további fejlesztés. Csak az tudja megállapítani, hogy a választott út egyszerű vagy fáradtságos volt-e, aki reflektál arra, hogyan oldotta meg a feladatot. A tanulás a reflektálásra alapszik.

Egy olyan fiatal tudományban, mint az informatikában, fontos, hogy az új felismeréseket figyelembe vegyék. Ehhez reflektálásra van szükség minden szinten. Kezdve az implementálásra történő reflektálással a páros programozás (pair programing) vagy a code review során, a team mindennapi reflektálásával, a minden iteráció utáni reflektáláson át, egészen odáig, ahogy a teljes szakma reflektál a saját tevékenységünkre Reflektálás nélkül nincsen haladás.

Elvek és praktikák

Az értékrendszer vezeti a Clean Code fejlesztőket a napi munkájuk során. Nem tartalmaz problémamegoldásokat, hanem keretfeltételeket szab meg a problémamegoldáshoz. A négy érték a konkrét napi átültetéshez azonban túlságosan elvont. Ezért összeszedtük az építőelemeket, melyek egyenként legalább egy értéket fejlesztenek. Ezeket a konkrét építőelemeket két csoportra osztjuk: Elvek és praktikák.

Elvek

A Clean Code fejlesztők elvei az alapvető törvényszerűségek a szoftverek strukturálásánál. Vagy merőleges más keretfeltételekre vagy föléjük rendelt. A kódnak mindig összhangban kellene lennie minél több elvvel. Természetesen nem rendelkeznek a természeti törvények „hatalmá”-val, melyeknek senki nem mehet szembe. De szoftverfejlesztés tekintetében azokkal egyenértékűek abban, hogy mennyire alapvetőek. Ahol egy elvet nem tartunk be, ott nem lép fel mindenképpen egy negatív hatás, de közép- és hosszú távon ezek a szabályszegések nem maradnak fájdalommentesek. A kód megértésének nehézségeiben vagy abban jelenik meg, hogy a változtatásokat csak nagy ráfordítással lehet megvalósítani. Ultimatív akkor lesz, amikor a szoftver továbbfejleszthetetlenné válik. Hogy egy elvet betartottak-e, azt a kódból mindig meg lehet állapítani.

Praktikák

A praktikák olyan technikák és eljárások, amelyek mindig bevetésre kerülnek. Azt írják le, hogy mit tesznek a Clean Code fejlesztők a gyakorlatban. A praktikák mottója: „Tedd mindig így. Minden nap, mindenkor.” Kézzel fogható cselekvési útmutatók, melyek néha eszközök használatára szorulnak. Hogy egy praktikát betartottak-e, azt a kódból nem lehet mindig megállapítani.