HTML

Projektmenedzsment, alkalmazásfejlesztés

Online projektmenedzsment rendszerek, webes alkalmazások fejlesztése, refactoring.

Friss topikok

Linkblog

Refaktorálás, mit, mikor?

2010.07.31. 21:57 develop

A szinte mindig szoros fejlesztési időket tekintve jogosan merül fel a kérdés, hogy a kód refaktorálása nem igényel-e plusz erőforrásokat, és nem veszélyezteti-e a projekt határidejét?

Azt gondolom, hogy rutinos fejlesztők esetében a refaktorálás nem okozhatja a fejlesztés idejének átlépését, vagyis a fejlesztés maga nem fog többe kerülni miatta.

Ugyanakkor a refactoring szemléletének, és módszereinek elsajátítása időbe telik, és gyakorlást igényel. Rutint szerezni viszont jobbára csak éles fejlesztés során tudunk.

Ha gyakorlott, refaktorálásban jártas fejlesztőkkel dolgozunk együtt, akkor az elkészült kódbázisra épülő további fejlesztések költségének csökkenése várható.

Ez mind a kód minőségének javulásában, mind pedig a hibák számának csökkenésében jelentkezik.

Ha jó a kódunk, kevesebb tesztelésre van szükség, kevesebb feladat hárul a projektet vezetőre.

Mivel így kevesebb erőforrásra van szükség egy adott projekt megvalósításához, összességében hatékonyabb működés valósítható meg.

A "felszabaduló" időben egyéb (belső) projektek is megvalósíthatóak.

Ráadásul a csökkenő költségek piacképesebb árakat is magukkal hoznak.

Új kód, régi kód

Az új fejlesztések során keletkező kódbázisnál nem kérdés: refaktorálni kell.

Régi kódra épülő fejlesztések során azt szoktam javasolni, hogy csak az érintett, régi kódbázist, és természetesen az újat refaktoráljuk.

Ne akarjuk a teljes forrást refaktorálni, mert maga a folyamat is sokáig tarthat, ráadásul a teljes alkalmazást így újra le kellene tesztelni, ami biztos nem fér bele a fejlesztési költségbe.

Régi kód esetén javaslom, hogy a refaktorálást könnyen tesztelhető, egyszerű funkcióknál kezdjük.

(Ha egy módosított kód tesztelése nehézkes - pl. más rendszerektől való függése miatt -, akkor a teljes átalakítás is sokkal több időt vesz igénybe.)

Régi, elavult kód refaktorálása

A folyamatos fejlesztésű rendszerekkel kapcsolatos refaktorálás mindenképpen behozza az árát, még ha hosszú időbe is telik a teljes rendszer átdolgozása.

Az egyes - relatíve kisebb - fejlesztéseknél biztosan nem tudjuk a teljes rendszert refaktorálni, de lépésenként, egy-egy részfunkció átdolgozásával végül az egész alkalmazást áttekinthetővé tehetünk.

Ha így járunk el, a következő fejlesztések már rugalmasabban, rövidebb idő alatt végezhetőek el.

5 komment

Címkék: refactoring

A bejegyzés trackback címe:

https://develop.blog.hu/api/trackback/id/tr772190092

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben és az adatvédelmi tájékoztatóban.

ALW 2010.08.18. 15:42:49

Kedves blogoló!

Nem tudom, hogy te hol dolgozol, vagy mit csinálsz, esetleg a Karakószörcsögi könyvtár hálózatát tervezed újra, de ezek a dolgok kurvára nem működnek ám ilyen egyszerűen a valóságban.

"Azt gondolom, hogy rutinos fejlesztők esetében a refaktorálás nem okozhatja a fejlesztés idejének átlépését, vagyis a fejlesztés maga nem fog többe kerülni miatta."

Ez gondolom nem egy életből vett példa, ugyanis ha nem csak egy könyvet olvastál volna, akkor feltűnne, hogy ha egy projektre adott idő áll rendelkezésre, akkor a refaktorálás több időt jelent és nem beletervezhető a folyamatba, hiszen csak a végén születik meg az újratervezhető kód,
tehát vagy eleve bele van kalkulálva, vagy többletmunkát jelent adott kereten belül, amit, ismerve az ilyen cégeket a fejlesztő idejének lefaragásával lehet csökkenteni...

Ha esetleg a kollégáid a könyvtárban furcsán néznek, illetve tartják a távolságod tőled, az az ilyen vadbarom gondolkodás miatt lehet.

Sok sikert és ha már úgyis a könyvtárban vagy, rendeljetek más könyveket is...

"A "felszabaduló" időben egyéb (belső) projektek is megvalósíthatóak.

Ráadásul a csökkenő költségek piacképesebb árakat is magukkal hoznak."

hát ezekre nem is lehet mit írni...

milyen felszabaduló idő???

develop 2010.08.30. 22:24:53

@ALW: Kedves ALW!

Egy webes alkalmazásokat fejlesztő cégnél dolgozom alkalmazásfejlesztési projektvezetőként, lassan 4. éve.

A fejlesztés ideje alatt törekedni kell a veszteségek minimalizálására, vagyis a felesleges plusz idők elkerülésére.

Emiatt pontosan az ügyfél igényeit kell kielégítenünk (ne fejlesszünk többet, mint amit kifizet), ne legyen szükség utólagos módosításra, és csökkentsük a hibajavítások számát.

Ezeket korrekt specifikációval, megbeszélésekkel, rutinos fejlesztőkkel, és a kód megfelelő minőségével tudjuk elérni.

Ez utóbbit pedig refaktorálással igyekszünk biztosítani.

Tapasztalatom szerint egy megfelelően refaktorált kódot rugalmasabban, gyorsabban lehet az újabb igényekre szabni, könnyebb új funkciókkal kiegészíteni.

Emiatt kevesebb időt igényel az elkészítése is.

(A fejlesztési folyamatok optimalizálásával is tudunk faragni az időkön.)

Abban igazad van, hogy a refaktorálást nem lehet "beletervezni" a projektbe.

Veled ellentétben viszont úgy gondolom, hogy nem is kell!

(Persze ez csak akkor biztosítható, ha a kód már az elkészültekor "refaktorált".)

Van egy másik dolog is, amivel nem értek Veled egyet.

Szerintem hibásan gondolod, hogy a projekt végén kellene refaktorálni.

Véleményem szerint refaktorálni a (rész)feladat elkészülte és a tesztelésre való átadása előtt kell, vagyis jóval a projekt lezárása előtt.

Így az egymásra épülő funkciók elkészítése során is lehetőséged van időt megtakarítani.

(Ráadásul, így könnyebben tudsz reagálni az esetlegesen megváltozott ügyfél-igényekre.)

Felszabaduló idő alatt pedig olyan idő értek, amit a veszteségek felszámolásával "spóroltál" meg a fejlesztésen.

Ilyen lehet a projekten lévő fel nem használt tartalék, a garanciális időre kalkulált idő (persze, ha nem emészted fel a hibák javításával), illetve a fent is említettek.

ytg 2010.11.13. 20:22:31

Azt hiszem sikerült beleesned a divatszavak hibájába. (Ékes angol nyelven ugye buzzword, gyk.) A megoldás talán az lenne, hogy próbáljunk meg helyette magyar megfelelőt használni, és máris több értelmet nyer a "refaktorálás" ha pl. "átalakításnak" hívjuk. Így sokkal szembetűnőbb a logikai bukfenc a mondatban:
Az új fejlesztések során keletkező kódbázisnál nem kérdés: át kell alakítani.
Mert hát lássuk be, az új kódot nem kell átalakítani. Az új kódot jól kell megírni. Ha az új kód rossz, akkor annak vagy az lehet az oka, hogy aki írta nem tudja jól megírni (és ebben az esetben fogalma sem lesz róla, hogy milyenre kellene alakítania a kódot, esetleg még azt is gondolhatja, hogy az ő kódja tökéletes) vagy aki írta meg tudja jól írni, csak direkt nem akarja (ekkor viszont a projekt szabotálásáért érdemes volna kirúgni).

ytg 2010.11.13. 20:23:48

Azt hiszem sikerült beleesned a divatszavak hibájába. (Ékes angol nyelven ugye buzzword, gyk.) A megoldás talán az lenne, hogy próbáljunk meg helyette magyar megfelelőt használni, és máris több értelmet nyer a "refaktorálás" ha pl. "átalakításnak" hívjuk. Így sokkal szembetűnőbb a logikai bukfenc a mondatban:
Az új fejlesztések során keletkező kódbázisnál nem kérdés: át kell alakítani.
Mert hát lássuk be, az új kódot nem kell átalakítani. Az új kódot jól kell megírni. Ha az új kód rossz, akkor annak vagy az lehet az oka, hogy aki írta nem tudja jól megírni (és ebben az esetben fogalma sem lesz róla, hogy milyenre kellene alakítania a kódot, esetleg még azt is gondolhatja, hogy az ő kódja tökéletes) vagy aki írta meg tudja jól írni, csak direkt nem akarja (ekkor viszont a projekt szabotálásáért érdemes volna kirúgni).

develop 2011.01.25. 21:41:44

@ytg: A magyar megfelelő használatával kapcsolatban igazad van.

Mint ahogy a kód elkészítésével kapcsolatosan is.

Szerencsére szabotázzsal még nem találkoztam, új, rossz kóddal viszont már igen.

Közrejátszhat - amit írtál is -, hogy a fejlesztő nem tudja jól megírni, illetve nem látja, hogy ha jól írja meg, mennyi előnye származik belőle. (Nem csak neki, hanem a kollégának, aki utána nyúl esetleg hozzá.)

Ha nem ismeri az előnyöket, nem is lesz igénye rá, hogy jobb kódot írjon.

Én most is azt mondom, hogy meg kell előzni a "bajt", és fel kell készíteni a kollégákat, hogy jó és rugalmas kód kerüljön ki a kezük közül. (Ne utólag kelljen faragni.)
süti beállítások módosítása