Utálok mosogatni

Utálok mosogatni. Több nap is eltelik, mire rászánom magam végre: itt ez a rakás edény, már nem fér el a mosogatóban, el kéne kezdeni… Aztán elkezdődik a félórás, háromnegyedórás haláltusám az edényekkel. Krémes süteménytől visszamaradt, ragacsos kosz, a tepsi aljába a hétvégén odaégett kaja…

Nem elég, hogy mosogatnom kell, még le is kell vakarnom az odaszáradt maradékokat…

Pedig ha minden nap csak a vacsora utáni edényeket elmosnám, 5 perc alatt végeznék, és nem is fájna úgy. De utálok mosogatni…

Elkészült a kód

Ha elkészülök egy új kóddal, ami egy új funkciót valósít meg, elkezdem nézegetni. A kód ugyan működik, a tesztek is igazolják, de általában nem tetszik, ami elkészült, ezért elkezdek rajta változtatgatni. Átnézem a változó-, field- és metódus neveket, és elképzelem, hogy vajon milyen fogalomra asszociálnak majd mások, ha olvassák ezeket az azonosítókat. Ha úgy gondolom, nem egyértelmű az elnevezés, kedvenc IDE-mben, az IntelliJ IDEA-ban átnevezem egyiket-másikat.

Ha valami nagyon bonyolultra sikeredett, elgondolkozom, mi lehet az oka, és mit tehetnék az ügy felszámolását illetően. Sokszor jutok arra a következtetésre, hogy egy metódus vagy osztály túl sokat csinál, célszerű szétszedni őket. A hosszú metódusokból elkezdem kiszedni külön metódusba az önállóan is értékelhető, értelmezhető részeket. A metódusoknak próbálom a legmegfelelőbb nevet megtalálni. Új osztályokat hozok létre nekik szánt saját felelősséggel, ezzel is csökkentve az eredeti osztály(ok) felelősségének terhét és azok méretét.

Ha tudom, mit akarok csinálni, akkor egy modern IDE-ben mindez csak pár gombnyomás.

Nem könnyű a tiszta kód írása, és nincs is egyértelmű módszer ennek elérésére. “Biztatásképpen” álljon itt egy XIX. századi amerikai novellaíró idézete, amelyre az egyik munkatársam énblogjában bukkantam rá:

“Easy reading is damn hard writing” – Nathaniel Hawthrone

Ha sikerül helyre raknom a kódomat, akkor az nagyon jó érzéssel tölt el. Gyönyörködöm egyszerűségében.

A kiscserkész szabály (Boy Scout Rule)

A korábbi posztjaimban istenített Clean Code c. könyvben találtam ezt a nagyon jópofa párhuzamot. Az amerikai kiscserkészek egyik szabálya a következő:

A táborhelyet nagyobb rendben hagyd, mint amilyenben találtad!

Ezt a szoftverfejlesztésben is érdemes megfogadnunk. Bármikor, amikor olyan kódrészlethez érünk, amit – akár mi írtunk, akár nem – nehezen értünk, vagy úgy gondoljuk, érdemes refaktorálni, tegyük is meg!

Ezt bottal sem piszkálnám!

Sokszor találjuk magunkat ebben a szituációban. Elemzünk egy más által megírt kódot, ide-oda görgetjük a hosszú metódust, nézzük, hogy egy-egy változót hol és hogyan használnak, ugrálunk a különféle objektumok metódushívásai között. Még pislogni se merünk, nehogy elveszítsük a fókuszt.

Azonban a kódot képtelenség átlátni és követni. Sajnáltatva magunkat elengedünk jó pár anyázást kollégáink előtt, és azt a programozót hibáztatjuk, aki ezt a kódot írta. Egy újabb klasszikust idézve (WTF = What the f@ck):

Lehet, hogy már élesben is kinn van ez a förmedvény. Senki se érti, hogy lehet az, hogy ez működik. De működik, mondjuk, és tovább állunk.

A módosítások útjában legtöbbször az áll, hogy nincsenek automatizált tesztek (unit, integrációs, acceptance tesztek) a kódhoz. Hát, igen, tesztek nélkül nem fogunk tudni refaktorálni!

Majd refaktorálunk!

Most határidő van, nincs idő refaktorálni, de a deadline után lesz pár hét, akkor refaktorálhat a csapat. Most az a fontos, hogy elkészüljünk a funkciókkal.

Több gond van ezzel a gondolatmenettel:

  • Nem kényszeríti ki a tiszta kódot. Ha nincs a csapatban az a belső kényszer, hogy eleve jó kódot írjon, akkor később, ha már működik a kód, miért változtatnák meg? Röviden: ha nem csinálod meg most, nem is fogod soha.
  • Sokkal költségesebb, ha utólag próbálunk refaktorálni, mintha ez a napi munka része lenne. Sokkal nehezebb utólag megint belerázódni a kódba, és kibogozni azt, mintha azon nyomban helyre raknánk. Ráadásul az egymásra épülő rothadó kódok még nehezebbé teszik az utólagos refaktorálást.
  • Ha a napi munka részeként refaktoráljuk az éppen elkészült kódot, annak olvasása, továbbfejlesztése során – már a határidő előtt is – időt spórolunk meg. Tehát ahelyett, hogy megbízhatatlan, kezelhetetlen kódot adunk át kutyafuttában, valójában hamarabb is végezhetünk.
  • Ez a fajta menedzser hozzáállás félreviszi a csapatot, és a tiszta kódra való törekvés hiányában elindulnak egy olyan lejtőn, ahonnan már nincs visszaút.

Refaktor dilemma

Az elmúlt években több projektben is szembesültem azzal, hogy döntést kell hoznunk: hagyjuk a kódot úgy ahogy van, vagy rászánunk egy-két hónapot arra, hogy rendbe tegyük?

De hogy lehet az, hogy ilyen helyzet alakult ki, ha elvileg inkrementálisan – a napi munka részeként is – refaktorálhattunk volna? Ennek nagyon egyszerű az oka.

Senki sem születik tökéletesnek. Könnyű mondani, hogy írjunk jó kódot, de valójában minden fejlesztőnek meg kell tanulnia, hogy hogyan viheti ezt véghez.

Sokszor fordul elő az is, hogy új, ismeretlen technológiákkal dolgozunk (pár év alatt újabb és újabb technológiai stack nő ki), és későn döbbenünk rá arra, hogy esetleg rossz architekturális döntéseket hoztunk a legelején. Ilyenkor döntenünk kell, mit teszünk: hagyjuk, ahogy van, vagy alapjaiban változtatunk a dolgon?

6 évvel ezelőtt, amikor egy projektben 1 éven keresztül abban a dilemmában szenvedtünk, hogy merjünk-e belefogni egy nagyobb átalakításba vagy sem, nem mertük bevállalni.

Utólag láttuk be, hogy meg kellett volna tennünk. Ehelyett folyamatosan szenvedtünk az örökölt kódbázistól, amely borzasztóan bonyolult volt, és – akkor már – kétséges technológiát is alkalmazott (Microsoft COM, COM+, DCOM).

Azóta többször is kerültünk hasonló helyzetbe, és a korábbi tapasztalat alapján mindig úgy döntöttünk, hogy meglépjük, amit meg kell lépnünk: ha szükséges, rászánjuk azt az 1-2 hónapot az átalakításra. Azóta is mindig helyesnek bizonyultak ezek az – átalakításra irányuló – döntések.

“És Ön bevállalja?”

Konklúzió

Automatizált tesztek nélkül nem fog menni, ezt érdemes szem előtt tartani.

Nagyon jó ötletet adhatnak egyes minták (ld. Clean Code c. könyv). Kollégáink összes commitját nézzük végig, javítsunk mi is a kódjukon, és adjunk visszajelzést számukra. Így mi is visszajelzést kaphatunk, és tanulhatunk.

A refaktorálás nem azt jelenti, hogy valaki hibázott, trehány kódot írt, és azt helyre kell pofozni. A refaktorálás a napi munka része. Mindenkinek be kell vallania: nem írhat elsőre tökéletes kódot, és mindig rá kell szánnia azt a kis időt, hogy helyre rakja.

Nem hibás senki, ha nem áttekinthető az elsőre megírt kódja. Akkor válik hibássá, ha úgy is hagyja. És mi is hibásak leszünk, ha tudunk róla, és nem teszünk azért, hogy jobb lehessen a kód.

Ha minden nap elmosogatunk, hamar végzünk. Ha napokig halogatjuk, sokkal fájdalmasabb. Ugyanez igaz a szoftverfejlesztésre is: ha azonnal látjuk, hogy valamin javítani lehet, javítsuk. Nem tart sokáig. Ha az egész csapat így dologozik, akkor a kód jó minőségű lesz. Ha azonban nem foglalkozunk azzal, hogy tisztán tartsuk a kódot, akkor azt később helyrerakni sokkal nehezebb és költségesebb.

Share
This entry was posted in Programozás and tagged , . Bookmark the permalink. Follow any comments here with the RSS feed for this post. Trackbacks are closed, but you can post a comment.

Comments

  • Hesz Roland

    Jul 30th, 2010

    De hát erre nincs idő!!

    Persze lenne, mert egy jó pár dolgot később hamarabb, könyebben lehetne fejleszteni, meg a bugfix sem venne el annyi időt, meg…
    Na de az jövő szerda után van, az meg kiesik a látókörből :)

    Amúgy Code Review-t is ritkán látni. Ennek előnye, hogy ha egy kolléga elmegy, akkor később rá lehet kenni minden hibát. Ha van Code Review – ami amúgy is csak időpazarlás -, akkor meg nehezebb.

    Egyszer szeretnék látni egy csapatot, ami így dolgozik.

  • Marhefka István

    Jul 30th, 2010

    Roland: Idő mindig van… :) (Egy jó BA sokat segít ebben.)

    A Code Review nálunk a fejlesztési folyamat része. Egy időben Kanbant alkalmaztunk, és ott kitűzött cél volt, hogy hetente új release-t adunk. Ilyenkor kikényszerítettük a folyamatban, hogy ha módosítás történt, akkor a tesztelésen túl a fejlesztők is átnézték egymás commitjait. Jó pár hibát ki lehet így küszöbölni.

    Ezen felül nálunk alap, hogy a fejlesztők átnézik, hogy a többiek mit commitáltak, és nem csak mindenki a saját kódjával foglalkozik.

  • Hesz Roland

    Jul 30th, 2010

    Idő mindig van.. Ezt menedzsment ritkán hiszi el :)
    Projektmenedzserek pláne. Szóval az első mondat kicsit színpadias volt :)

  • Marhefka István

    Jul 31st, 2010

    Roland: De csak az ilyen színpadias mondatokkal lehet változásokat elérni :)

    Ha durván akarok fogalmazni, akkor azt mondanám, hogy nem nagyon tud érdekelni, hogy a menedzsment mit gondol. Nem értenek a szoftverfejlesztéshez, nem értenek az üzleti problémához, egyáltalán milyen alapon hozzák meg a döntéseket?

    A Clean Code fenntartása alapvető szakmai feladatunk, ebbe a menedzsmentnek semmilyen beleszólása nincs. Mi vagyunk a kóderek, mi tudjuk, hogyan kell megírni a kódot, nem?

    Soha nem tudom elfogadni azt, ha az összecsapott kódra azt mondja valaki, hogy azért sikerült így, mert nem volt rá idő, hogy refaktoráljon. Ez nem professzionális. Ahhoz, hogy a munkánkban fenntarthassunk egyfajta minőséget, arra időt kell szánni. Amikor azt mondom, mindig van idő, arra gondolok, hogy mindig kell tudni időt szakítani a minőségre.

    Ha valaki megérti, rájön arra, hogy ezzel a nem is olyan sok extra időráfordítással végeredményben időt spórol meg.

  • Hesz Roland

    Jul 31st, 2010

    “Roland: De csak az ilyen színpadias mondatokkal lehet változásokat elérni ”

    Félreérthető voltam.
    Itt a saját “De hát erre nincs idő!” mondatomra gondoltam :)

    Amúgy egyetértek, én még az idők hajnalán fejlesztőként Watts S. Humphrey “A Disciplined Software Engineering” könyve alapján dolgoztam. Meg Martin Fowler, meg Craig Larman, meg Eric Evans könyvei alapján, és minőség és idő tekintetében a sok “pluszmunka” mind rövidebbé tette a fejlesztést. És pontosabban becsülhetővé – másik nagy probléma ugye az estimate készítése.

    De rá kellett jönnöm, hogy sokszor nem a menedzsereken múlik, hanem a vezető fejlesztőn, meg a többi fejlesztőn.
    Mert ha 10 évig működött amit csináltak, akkor azt minek megpiszkálni? :)

  • Marhefka István

    Jul 31st, 2010

    Roland: Akkor egyetértünk :) Nagyon sok múlik a fejlesztőkön. És ezért próbálom ezzel a bloggal is felhívni erre a figyelmet.

  • “Ezen felül nálunk alap, hogy a fejlesztők átnézik, hogy a többiek mit commitáltak, és nem csak mindenki a saját kódjával foglalkozik.”

    Na igen, de ezt is lehet rosszul csinalni. Van egy kollegam, dolgozik egy nagy cegnel, es egy csomo ujitas/fejlesztes/javitas csak azert nem tud bekerulni a kodfaba, mert van egy olyan szabaly, hogy amit nem fogadott el ket ember gerrit-ben, az skip. Es olyan szintu valtoztatasokrol beszelunk, minthogy teszemfel a JUnit-bol kijott a 4.10 es minden pom.xml -ben le lett cserelve a verzioszam. Ha azt mondjuk, hogy a CI szerver bolintson ra, akkor igen, oke. De hogy egy ilyen szintu commitot ket embernek kelljen jovahagynia… szerintem nonszensz. Nagy ceg, sok fejlesztovel, de ezt szerintem akkor is teljesen felesleges. Nem hatekony.

  • Marhefka István

    Mar 21st, 2012

    hron84: Igen, nálunk kis csapat volt (4-5 fejlesztő), és a kultúra is olyan volt, hogy érdekelt mindenkit, hogy mit csinált a másik.

    Egyetértek Veled abban, hogy nem szabad hagyni, hogy emberek szűk keresztmetszetek legyenek egy ilyen folyamatban. Automatizálni kell mindent. Statikus kódelemző eszközök, azokhoz bevezett automatikus szabályok, automatizált tesztek kellenek.

    Szerintem motivációs szempontból sem annyira jó, ha a fejlesztők között vannak kitüntetettek, akik jóváhagyják mások munkáját.

    Én szerencsésebbnek tartom azt a modellt, hogy több kis csapat van, mindegyik csapathoz dedikált projekt tartozik, amiért az a csapat felel. A csapatnak (katonai kifejezéssel) képessége, hogy a projektet szállítani tudja, tehát (Scrummal élve) keresztfunkcionálisak. Ezek a projektek nem hierarchiába vannak szervezve, hanem egymás mellett léteznek.

    Véleményem szerint ugyanaz a nagyobb projekt ilyen módon szervezve sokkal kevesebb emberből megvalósítható, mert az egyes csapatokon belül a motiváció és összetartás sokkal erősebb, mintha az lenne, hogy egy nagy “masszában” a mindenféle szinteken a problémákat menedzserek probálnák kezelni.

    De egy ilyet megvalósítani szerintem sokkal nehezebb, mert felülről kell egy megfelelő rálátás a csapatoknak a kialakításához, a nagy projekt megfelelő szétvágásához, és ehhez igencsak kevesen értenek. A csapatoknak motiváltaknak kell lenniük a saját fejlődésükben, ehhez motiváló munkakörülményeket is kell teremteni. Erre kevés menedzsment képes, és ez már a tulajdonosokon is múlik, hogy a cég milyen vízióval rendelkezik. Csak a pénzt hajhássza, vagy esetleg értéket is akar teremteni az emberek számára.

    Ha nem tudják megvalósítani, akkor kialakul a droid modell, amiről Te írtál.

    Nagy, nyílt forráskódú fejlesztéseknél is ugyanez a helyzet.

  • Igen, alapvetoen itt is egy nagy nyilt forrasu rendszer fejlesztserol van szo.

    Meg ha nem is kituntetett fejlesztok hagyjak jova, hanem csak a manyeyeball elvet akarjak ilyen modon kikenyszeriteni, szerintem akkor is karos. Mindenkinel idot es energiat von el a fontosabb dolgokra koncentralastol. En azt gondolom, hogy senki sem azert lesz fejleszto, hogy a nap nagy reszeben kodokat vagy bugokat nezegessen at. Ez egyfelol idegorlo, masfelol egyaltalan nem hatekony.

    En azt gondolom, hogy mindenki legyen igenyes a sajat munkajara. Buildeljen, teszteljen, ha kell futtassa a code quality ellenorzeseket is, tegyen meg mindent azert, hogy kifogastalan legyen a kodja, es ha vegzett, akkor gondolkozzon el a commiton. Nem veletlen, hogy en a sajat projektemben tul azon, hogy letesztelem a kodjaimat, egy pre-commit hook meg egyszer lefuttatja a _megfelelo_ teszteket, hogy biztos jo kod menjen be a faba. Sokszor egy utolag megtett “kis” modositas torte volna el az egesz kodot (pl valahol lehagytam egy zaro zarojelet, a javitasban pedig veletlenul kettot tettem, es nem vettem eszre, mert volt ott mar harom).

Leave a Comment


  • RSS JTechLog – Viczián István java blogja


    Warning: A non-numeric value encountered in /chroot/home/infokuka/infokukac.com/html/wp-includes/SimplePie/Parse/Date.php on line 693

    Warning: A non-numeric value encountered in /chroot/home/infokuka/infokukac.com/html/wp-includes/SimplePie/Parse/Date.php on line 693

    Warning: A non-numeric value encountered in /chroot/home/infokuka/infokukac.com/html/wp-includes/SimplePie/Parse/Date.php on line 693

    Warning: A non-numeric value encountered in /chroot/home/infokuka/infokukac.com/html/wp-includes/SimplePie/Parse/Date.php on line 693

    Warning: A non-numeric value encountered in /chroot/home/infokuka/infokukac.com/html/wp-includes/SimplePie/Parse/Date.php on line 693

    Warning: A non-numeric value encountered in /chroot/home/infokuka/infokukac.com/html/wp-includes/SimplePie/Parse/Date.php on line 693

    Warning: A non-numeric value encountered in /chroot/home/infokuka/infokukac.com/html/wp-includes/SimplePie/Parse/Date.php on line 693

    Warning: A non-numeric value encountered in /chroot/home/infokuka/infokukac.com/html/wp-includes/SimplePie/Parse/Date.php on line 693

    Warning: A non-numeric value encountered in /chroot/home/infokuka/infokukac.com/html/wp-includes/SimplePie/Parse/Date.php on line 693

    Warning: A non-numeric value encountered in /chroot/home/infokuka/infokukac.com/html/wp-includes/SimplePie/Parse/Date.php on line 693

    Warning: A non-numeric value encountered in /chroot/home/infokuka/infokukac.com/html/wp-includes/SimplePie/Parse/Date.php on line 693

    Warning: A non-numeric value encountered in /chroot/home/infokuka/infokukac.com/html/wp-includes/SimplePie/Parse/Date.php on line 693

    Warning: A non-numeric value encountered in /chroot/home/infokuka/infokukac.com/html/wp-includes/SimplePie/Parse/Date.php on line 693

    Warning: A non-numeric value encountered in /chroot/home/infokuka/infokukac.com/html/wp-includes/SimplePie/Parse/Date.php on line 693

    Warning: A non-numeric value encountered in /chroot/home/infokuka/infokukac.com/html/wp-includes/SimplePie/Parse/Date.php on line 693

    Warning: A non-numeric value encountered in /chroot/home/infokuka/infokukac.com/html/wp-includes/SimplePie/Parse/Date.php on line 693

    Warning: A non-numeric value encountered in /chroot/home/infokuka/infokukac.com/html/wp-includes/SimplePie/Parse/Date.php on line 693

    Warning: A non-numeric value encountered in /chroot/home/infokuka/infokukac.com/html/wp-includes/SimplePie/Parse/Date.php on line 693

    Warning: A non-numeric value encountered in /chroot/home/infokuka/infokukac.com/html/wp-includes/SimplePie/Parse/Date.php on line 693

    Warning: A non-numeric value encountered in /chroot/home/infokuka/infokukac.com/html/wp-includes/SimplePie/Parse/Date.php on line 693

    Warning: A non-numeric value encountered in /chroot/home/infokuka/infokukac.com/html/wp-includes/SimplePie/Parse/Date.php on line 693

    Warning: A non-numeric value encountered in /chroot/home/infokuka/infokukac.com/html/wp-includes/SimplePie/Parse/Date.php on line 693

    Warning: A non-numeric value encountered in /chroot/home/infokuka/infokukac.com/html/wp-includes/SimplePie/Parse/Date.php on line 693

    Warning: A non-numeric value encountered in /chroot/home/infokuka/infokukac.com/html/wp-includes/SimplePie/Parse/Date.php on line 693

    Warning: A non-numeric value encountered in /chroot/home/infokuka/infokukac.com/html/wp-includes/SimplePie/Parse/Date.php on line 693
  • RSS Tajti Ákos C és Java blogja

  • RSS QualityOnTime

  • RSS Adaptive PM

  • RSS Menedzsmentor blog

  • Shelfari: Book reviews on your book blog