Nem egyszer állítottam azt utóbbi X évben, hogy egy bizonyos szoftvert egyszerűbb lenne újraírni, mint debugerrel piszkálgatni nagyon sokáig, hamarabb lenne belőle simán futó rendszer. Biztosan nem volt mindig igazam, de ilyesmi nagyon nagyon ritkán történik, így ez ilyen "mi lenne akkor" maradt jobbára. A parát megértem:
- Mi a garancia arra, hogy az újraírt rendszer jobb lesz? Nem csak valami trendibb izét akarnak a fejlesztők? Pl valami NoSQL-t az Oracle rojszrojsz-adatbázis helyére. (btw éppen mongo-t tanulok)
- Az újraírás idejét miből gazdálkodja ki a fejlesztő cég? (inkáb kiscégeknél)
- Illetve az eddig beleölt időt és pénzt hogyan írjuk le? (tipikisan nagy cégeknél)
Ennek ellenére biztos vagyok benne, hogy
- A legtöbb informatikai project építget olyan komplexitásokat, ami nem kell egy megrendelőnek sem.
Ide tartoznak azok a feature-k, amiket senki se használ és az olyan kódszervezési megoldások, amik a design patterns könyvben UML diagrammon jól néztek ki de az editorban már kicsit átláthatatlanok. - A szükségtelen bonyolítások jelentős részétől általában gyakorlatilag nincs lehetőség megszabadulni, a fejlesztést pedig rémesen lelassítják.
- Ebből következőleg egy from scratch project gyorsabban képes fejlődni, ha tanult az elődje hibáiból és nem próbál meg újabb trendi ingyombingyomokból építkezni.
Jó megoldás nincs. Vagy megszabadulsz a technológiai adósságodtól, vagy az egész project alatt fizetheted a költségeit. Egyszerűen kiszámolható. Napi 8 óra munkám 8 kiló banánba kerül, de ebból a nyolc órából 2-t rebuild-redeploy, akkor napi 2 kiló banánért a cég nem értéket kap, hanem a technológiai adósság fizetésére fordít.
Ha így nézzük a jrebel a legtöbb JEE projectben a legfontosabb program a javac után. Azért lehet élni nélküle is, otthon elő nem veszem...
Ötlet megoldásra:
Egy tipushiba, amit megfigyeltem, az az volt hogy amit a beszállító hozott, azt elfogadták amennyiben a funkcionális követelményeknek megfelelt. Így aztán pl groovy-ban írt csoda is érkezett, amikor a srácok többsége még életében nem látott groovy-t. A beszállító elfutott a pénzével, az üzemeltetés meg járkálhatott körbe, hogy "helló, valaki hallott már groovy programnyelvről?" Aztán újraírták más nyelven, de abba se vonták bele cég szoftverfejlesztőit tudtommal. Vajon ismétli magát a történelem? Vagy csak bizonyos problémák időnként jelentkeznek ha egyfajta hibát nem tudunk megérteni? :-)
Egészen pontosan egyszer történt velem az, hogy a management beleegyezett egy újraírásba, de elöbb ki kellett javítanom az előző rendszer kritikus hibáit, hogy legalább az újraírás alatt legyen valami. Ezt mondjuk gondoltam előre, de ez a hibajavítás úgy fél évet vett igénybe, az újraírt verziót is ugyanennyi idő alatt fejlesztettük le, a 6 hónapnyi áthidalt időben viszont senki sem merte használni a régi alkalmazást. Szóval a javítgatással nem nyertünk semmit.
Ha így nézzük a jrebel a legtöbb JEE projectben a legfontosabb program a javac után. Azért lehet élni nélküle is, otthon elő nem veszem...
Ötlet megoldásra:
- Ismertesd meg a főnököd a tech debt fogalmával. Nem kell szégyellni, mindenkinek van!
- Tartsátok rajta a szemeteket, tudjátok hogy mi mennyi időbe (tehát mennyi pénzbe) kerül A sonar szerintem klassz kis játék ehhez is, csak persze be kell paraméterezni...
Egy tipushiba, amit megfigyeltem, az az volt hogy amit a beszállító hozott, azt elfogadták amennyiben a funkcionális követelményeknek megfelelt. Így aztán pl groovy-ban írt csoda is érkezett, amikor a srácok többsége még életében nem látott groovy-t. A beszállító elfutott a pénzével, az üzemeltetés meg járkálhatott körbe, hogy "helló, valaki hallott már groovy programnyelvről?" Aztán újraírták más nyelven, de abba se vonták bele cég szoftverfejlesztőit tudtommal. Vajon ismétli magát a történelem? Vagy csak bizonyos problémák időnként jelentkeznek ha egyfajta hibát nem tudunk megérteni? :-)
Egészen pontosan egyszer történt velem az, hogy a management beleegyezett egy újraírásba, de elöbb ki kellett javítanom az előző rendszer kritikus hibáit, hogy legalább az újraírás alatt legyen valami. Ezt mondjuk gondoltam előre, de ez a hibajavítás úgy fél évet vett igénybe, az újraírt verziót is ugyanennyi idő alatt fejlesztettük le, a 6 hónapnyi áthidalt időben viszont senki sem merte használni a régi alkalmazást. Szóval a javítgatással nem nyertünk semmit.
