Egy Oracle DB fejlesztő rémálm^H^H^Hélete

HUP cikkturkáló
It is close to 25 million lines of C code. What an unimaginable horror! You can't change a single line of code in the product without breaking 1000s of existing tests. Generations of programmers have worked on that code under difficult deadlines and filled the code with all kinds of crap.

Tovább »

( Oregon | 2024. 08. 13., k – 10:44 )

Ahogy hallom számos hazai számlázórendszer/ERP is ilyen.

Divat volt néhány évtizede. Aki akkor belefogott, nehezen szabadulna tőle. A kis és közepes vállalkozások számára eszetlenül drága volt a licensze. Cserébe semmivel sem nyújtott többet, mint bármelyik másik. Az üzleti logika számít, annak meg mindegy, hogy milyen motor van alatta.

Persze, mára kb. minden nagyobb projekt ilyen, OS-ek, kernelek, böngészők, compiler-ök (le fog esni az állatok, ha megnézitek, hogy a gcc, llvm/clang, rust, stb. hány kódsoros), glibc, mesa, LibreOffice, stb. is elég durva Linuxon (főleg a GPU driverek durvák). Épp így adatbázisok, Java, Python, nagyobb asztali környezetek (KDE, Gnome), virtualizációs megoldások, stb. se kicsik. A legdurvább, amit életemben láttam, az a SageMath, az olyan, átlag i7-en 12-24 órát fordul, de az egy olyan megaprojekt, ami sok nyelven van írva, sok modulból áll.

És nem az a baj, hogy erősebb hardver kell alá, hogy lefordítsák és jobban fusson, hanem egyszerűen ez az adattömeg és komplexitás embernek kezelhetetlen, áttekinthetetlen, könnyebben becsúsznak bugok, több bennük a kihasználható biztonsági rés, stb.. Ez megdrágítja a fejlesztési projektet is, sok ember, sok idő kell hozzá, csak nagy cégeknek van elég tőkéjük patkolni, ezzel vissza is élnek, hogy cserébe lenyomnak a felhasználók torkán mindenféle korlátozást, telemetriát, adatgyűjtést, mesterségesen avultatnak el, stb.. Lassítja a tesztelést is, kiadási ciklusokat. Megnehezíti vagy ellehetetleníti a más rendszerekre portolást.

Nem csak a fejlesztőre ró nagyobb munkát, disztróknál is fejlesztőkre, csomagfenntartókra, mert ez a munka meg is sokszorozódik, mivel gyakran jönnek a patch-ek, jobban pörgetve vannak a verziók. Csodálkozok is, hogy nem panaszkodik több fejlesztő. Egyszerűen nem fenntartható.

Én azért is futtatok főleg terminálos alkalmazásokat, meg kis ablakkezelőket. Ezek max. alig pár ezer kódsor (kernel, glibc, böngészőt kivéve), nekem is, meg bármelyik otthoni hobbistának, programozást tanuló hallgatóknak is van esélye, hogy átlássa, megértse a kódot, lefordítsa, portolja, támogassa magának. Mivel szög egyszerűek, nincs nagyon mi eltörjön rajtuk, könnyen portolhatók bármilyen rendszerre, és még muzeális régiségeken is futnak relatíve elfogadható sebességgel, még ha kicsit lomhán, akkor se olyan, hogy tökön szúrja magát az ember.

A helyzetet sokszor súlyosbítja, hogy a sok üzemeltető is barom tud lenni, mindet mániákusan konténerizálnak, ami még exponenciálisabbra növeli az egész hardverigényét.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

( persicsb | 2024. 08. 13., k – 10:47 )

Szerkesztve: 2024. 08. 13., k – 10:48

Ilyen az evolúciós kód. Már görgetik maguk előtt több évtizede. Ilyen a FreeBSD kódbázisa, a Linux kernel, a GNU projekt, a Windows meg minden hasonló kódbázis. Tele van gányolással, tele van bonyolult dolgokkal, mert sosem hagynak időt arra, hogy letisztázzák a dolgokat.

Nem véletlenül jönnek elő nem várt regressziók ilyen kódbázisok módosításakor.

Külön nehezítés, hogy az Oracle egy jó darabig minden ügyfélre rászabta a motort és teletolta mindenféle kapcsolóval és opcióval, hogy bizonyos workload hatékonyabban ki legyen szolgálva és ez okozza alapvetően azt, hogy nehéz módosítáni. Ugyanez igaz mondjuk az Atlassian termékek esetén is, ahol eleinte minden nagyobb ügyfelet külön-külön leszoptak, aztán most ott vannak, hogy a kódbázis nagyobb része if-else-if.

https://iotguru.cloud

Így van. Én ezért is vagyok híve, hogy egy idő után írják újra a kódbázist, esély arra, hogy letisztuljon, meg hogy múltbéli hibákból és nehézségekből tanulva át tudják szervezni a kódot. Nem jó ezeket a végtelenségig maguk előtt görgetni, így keletkeznek a kezelhetetlen mamutkódok.

Egy másik véglet, meg amit sok szervezet, bank csinált, hogy rajta ragadtak régi Cobolban írt mainframe kódokon (ATM-eken XP-n, OS/2-őn), azok nem olyan nagyok, de azok is szétgányoltak, meg már nincs ember, aki ért hozzá. Felelőtlen halogatás, nem upgrade-eltek, eltöketlenkedték, onnan meg kicsúszott a kezükből.

A másik, amit utálok, hogy kapkodnak a fejlesztők, nagyon szoros kiadási ütemtervek vannak, nagyon gyakori, hogy már a kiadás után egy nappal ömlenek a visszajelzések a bugtracker-re, és lehet is kitolni rá a patch-t, ráadásul, ha nincs szerencséjük, és azt is lekapkodják, a patch-t is lehet patch-elni külön. Agilis fejlesztés, gratulálni tudok hozzá. Ebből is akkora káosz és cirkusz van, hogy sokszor már csak rolling disztrók bírják lekövetni, ilyen kiadás alapúak meg se próbálják.

Illetve, sok fejlesztő cégnél modern trend, hogy lespórolják a rendes tesztelést is, azonnal kitolják a késznek vélt binárist végfelhasználókhoz, azonnali éles üzemben, hogy szopjanak vele ők, ingyen teszteljenek. Nem jó ez senkinek, az ilyen gyakorlatot be kéne tiltani.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Kód-újraírás ezerrel?!...

Amikor még a processzorokról is sorra-rendre kiderül, hogy évek, évtizedek óta tele vannak hibákkal?!...

Előbb talán a hardverelemeket kellene valóban megbízhatóra készíteni (előre mérnökök, hajrá!), s csak azután létrehehozni -- végre -- használható programozási módszertanokat és eszközöket, amelyekkel bizonyíthatóan helyes programokat lehet készíteni és menedzselni, de még hosszabb időtávlatban is.

Megjegyzés: Azért érdemes lenne tisztázni az újraírás előtt azt is, hogy pontosan mikor is lesz olyan állapotú a kód, hogy _mindenképpen_ újra kell írni, és hogy ez milyen költésggel (erőforrással) is járna...

"Share what you know. Learn what you don't."

Pedig ezt írtad.

Ha nem lehet addig szoftver fejleszteni, amíg nincs 100%-os processzor, akkor nincs más, mint visszatérni a papír alapú eljárásokra.

A mérnökség soha nem a tökéletességről szól, mint a tudomány, hanem a célszerűségről (az üzletnek egy 90%-os megoldás bőven megfelelhet, ellenben egy matematikai bizonyítás csak 100% esetén fogadható el).

( kruska v | 2024. 08. 13., k – 11:00 )

Pedig az még nagyjából egy termék maradt mindig. 

A SAP HANA DB kódjában vannak részek korábbi adatbázisokból: ASE, TREX, MaxDB, sőt még ADABAS is.

( bognarattila | 2024. 08. 13., k – 11:23 )

Ez az árakra is ad (rész)magyarázatot.

( Fisher v | 2024. 08. 13., k – 11:29 )

Ahelyett hogy örülne, hogy nem megy ki az élesbe a kódja úgy, hogy nem zúz le mindent is :)

Szóval valahogy így lehet szarból várat építeni. IMHO.

( gabrielakos v | 2024. 08. 13., k – 11:51 )

Óriási dolog a milliónyi teszteset. Csak így bírhatta ki ilyen sokáig. 

Az persze egy mocskos jó kérdés hogy a milliónyi tesztesetnek mekkora része felesleges/káros már.

Gábriel Ákos

( joco01 v | 2024. 08. 13., k – 12:04 )

Nálunk viszonylag sok erőforrás megy el refaktorálásra és minőségi kód írására. Na ezért éri meg. Összességében kevesebb idő lefejleszteni dolgokat, és a fejlesztők sem őrülnek bele.

Mondjuk a cikk hozhatna példákat, hogy kik maradtak sikeresek miközben toltak egy rewrite from scratchet.

A Joel cikk sem arról szól, hogy ne adaptálódj, hanem arról, hogy ne dobd ki a régi termékedet, hogy akkor te most majd nulláról újraírod, mert mennyivel használhatóbb lesz úgy. 

Csak annyi a különbség, h. te egy ismeretlen névtelen senki vagy (boccs), ezt az arrogáns marhát meg ~30 éve követi vakon többezer hiring manager (legalábbis usa-szerte) az ilyen tippjeiért:

https://www.joelonsoftware.com/2006/10/25/the-guerrilla-guide-to-interv…

in the middle, you have a large number of “maybes” who seem like they might just be able to contribute something. The trick is telling the difference between the superstars and the maybes, because the secret is that you don’t want to hire any of the maybes. Ever.

Az a tudósember, akit a medium.com-ról idéztél, az valóban úgy hivatkozik önmagára, mint 'manager'-re. Azt tudni kell, hogy a manager az, aki konkrétan nem szakértő semmiben, de van érzéke ahhoz, hogy kövesse a divatot, és magabiztosan használja az aktuális buzzword-öket.

Vegyük úgy, hogy nempejoratív értelemben vett manager. ;)

Neki tényleg egy hibakövető cége van, a piacról él. Írásai szezációsak/avagy az emberek mindenhol is sztereotip baromságokat művelnek. Volt olyan írása, amikor azt hittem, hogy ott ült velüink az 50 fős projektértekezelten. Szinte szó szerint leírta mi történt. :-D

Ugyanez áll a stringekről írt fejtegetésére. Érdekes módon rengeteg striggel dolgozam, de soha nem használtam a string.h-t. Szóval ő olyan manager, aki tényleg ott van a szakmában. Csak le is írta.

Vagy vegyük az én példámat, amikor az ifjú titánnal (tudása legaláb százszoros hozzám képest) bájtszintű protokollt valósítottunk meg.

- Tudod mi az a hexdump?

- Hát, ööö, hallottam már a kifejezést.

Itt kicsit összekapkodtam magam, elnézést. Szóval:

Joel Spolsky programozó. Amit ír, az nem azért rokonszenves más programozóknak, mert jól hájpolja magát, hanem mert hasonlít ahhoz, amit minden más programozó is tapasztal.

Daniel Schwartzer manager. Amit ír, az nyilván rokonszenves más managereknek.

Szerk: ebből talán az is kövezkezik, hogy egy manager hiába futja át Spolsky irásait, nem lesz olyan élménye tőle, mint egy programozónak.

(Off: ez talán hasonlít ahhoz, amikor az indigógyermekek panaszkodnak, hogy Linus T. miért nevezi a szart szarnak, ahelyett hogy támogató szeretettel fordulna azok felé, akik a szar hadvert és szoftver előállították.)

"Joel Spolsky programozó". ÉS manáger is - a szó pozitív értelmébe - hiszen cége is van, szügyfelei is vannak és mindezt programozói tudással sikeresen irányítja!

Annakk idején, amikor a főnökom fölfelé bukott, így panaszkodott: Amíg alacsont szinten voltam, addig a felülről kapott urasításokat igyekeztem optimalizálni, hogy a feladat is elkészüljőn és a munkaerő is jól érezze magát. Egy szinttel feljebb már nincs utasítás meg hogyan, csak a százalékot közlik, hogy mennyire kell teljesíteni. A hogyant oldd meg!

Itt válik el a manager és az actor szerepkőre.

mint például

In the age of Cloud Computing and Open Source Software, and especially with the rise of Serverless Technology, when we look at our legacy code, we find that most of it is simply irrelevant. The problems it tackles and the solutions — all of it. It doesn’t need to be rewritten, it needs to go.

?

De én tényleg tök szívesen olvasnék arról egy sikersztorit, hogy az Oracle hogy írta nulláról újra a mysql-t, hogy sikeres legyen a cloud computing korában. Vagy a Google hogy dobta ki a régi e-mail kliensét, hogy majd a Google Wave győzzön. Tényleg, bármit.

Fowler-nek vannak ezzel kapcsolatban (szerintem jó) írásai. Ott van például a "strangler fig" stratégia, ami ránézésre működőképesnek tűnik.

Egy baja van: végig kell csinálni. Ha nem csinálod végig, úgy néz ki mintha kudarcot vallottál volna.

Szerintem általában a projektek nem technológiai okok miatt szoktak kudarcba fulladni.

Sokkal gyakoribb a kulturális, menedzsment stratégiai, menedzsment taktikai hiba mint valódi ok, a technológiai problémák inkább csak tünetek.

Gábriel Ákos

Erdekes, mert mindket vegletre boven lattam peldat:

  • project/product/marketing emberek, akik egy hasznalhato fejlesztovel sincsenek joban, arra sincs alkalmas tech emberuk, hogy segitsen szurni, hogy mi megvalosithato, mi nem
  • jo engineering csapat, akik allandoan varnak, mire a project/product/marketing vegre kitalalja, mit akar - es az engineerek vannak kesz mindig villamgyorsan

Ez a ket veglet valahogy joval gyakoribb, mint a koztes szituaciok, amikor ezek egyforman hatekonyak es hatekonyan egyutt is tudnak dolgozni, egymasra tudnak szamitani.

Mondjuk valóban elbeszélgethetünk arról is, hogy hová fejlődött már a számítástudomány, én két csúcsot emelnék ki: az egyik a leftpad-incidens (gyk: a fél világ összedőlt egy 11 soros javascript kiesése miatt), a másik a blockchain: egy remek megoldás, amihez még nincsen probléma.

Felsorolt par dolgot, ami tenyleg nem ok az ujrairasra.

Egyik ismerosom sokat bujta az allashirdeteseket kb. 1 eve, mert munkat keresett - tobbek kozt a nemet nyelvut is (junior szintut). Megakadt a szeme egy nyelven, amirol meg nem hallott, rogton megkerdezett rola, hogy erdemes lenne-e neki megtanulni: Algol 60. Latott Cobol hirdeteseket is. Orom lehet ilyen szarokat takolni - meg embert talalni hozza. Szinten jo buli lehet egy 50 eves szart takolni, es ugy versenyezni a Fintech startupokkal. Persze tudom, vannak AIX-es perverzek, akik meg elvezik is az ilyet. :)

Uncle Bob olyan torteneteket szokott hozni, amikor az egyre kuszabb kod miatt egyre lassabban megy a fejlesztes. Ezert jott a Clean Code, ami ha nem is tokeletes, legalabb ravilagit a problemara, es ad par tampontot, hogy szerinte hogy kellene csinalni. Egy regi kod ezeket biztosan nem teljesiti, inkabb az a kerdes, hogy lehet-e modularizalni, es modulonkent javitani a kodminoseget, vagy celszerubb ujrakezdeni. A kodba beepitett workaroundok sem feltetlenul kellenek mar. Volt mar, hogy hasznaltam egy libet, valami nem ugy mukodott benne, ahogy vartam. A project kezdetekor (par honappal korabban) huztam be, megneztem, hogy van-e ujabb verzio, es szerencsere pont javitotta ezt a nemvart mukodest (nem feltetlenul szamitott bugnak, de orultem, hogy nem kell kerulgetnem). Evek-evtizedek mulva siman lehet, hogy nincs szukseg arra a workaroundra, mert az eredeti projectben javitottak (vagy kihalt a hardware).

Amikor felvettek az NNG-hez, 2012 marciusa kornyeken volt egy bug az akkori kinai (korai 4-es) Androidos eszkozokben. Androidon a GPS adat ketfele interface-en keresztul hozzaferheto: vagy Location objecteket ad, a koordinatakkal, pontossaggal, es effelekkel, vagy a masikon keresztul a nyers NMEA stream jon. Elobbibol a pontossag adat hianyzott, az iGO emiatt nem volt hajlando hasznalni a GPS jelet. Irtam egy workaroundot ra, ha volt, az NMEA streambol szamolt pontossagot, ha nem, kamuzott valamit a rendszer tobbi resze fele (olyankor nem volt jobb megoldas). Azota biztos vagyok benne, hogy nincs forgalomban olyan kutyu, amin erre szukseg lenne (eleg hamar javitottak a 4-esben is, ugyfeleknek is jelentettek a hibat, valoszinuleg nagy reszuk ki sem adott rossz koddal kutyut). Az sem valoszinu, hogy ujra aktivizalodna a hiba. Szoval egy esetleges ujrairasnal/javitasnal ki lehet dobni azt a kodot a fenebe. (egyebkent ha rakeresel az accuracy_workaround=1-re a neten, sok sys.txt-ben megtalalod, olyan rendszeren is, ami be sem olvassa ezt a beallitast - pl. WinCe6)

Persze van olyan is, amikor hagyja a vezetes a teljes ujrairast, de elavult szemlelet menten. A tulaj/fonok regen ertett hozza, csak aztan elment mellette a szakma. Meg benne volt a 80-as evekbol, hogy a fuggvenyhivas overhead-del jar (fordito a kicsiket kioptimalizalja, de ha nem, akkor is minimalis az a plusz kod), szoval csak ugy volt hajlando belemenni, ha keves, hosszu fuggvenyt irnak (az eredeti otlete talan az volt, hogy ne legyenek egyaltalan, de arra meg a fejlesztok nem voltak hajlandoak). Az eredmeny igy egy ugyanolyan kuszasag lett, csak uj bugokkal.

Persze ez attol is fugg, mi az uzleti modell, es mi a software. Ha teljesen kontrollalt a kornyezet (pl. a ceg szolgaltatast ertekesit, sajat eszkozokkel), szinte az osszes workaroundot meg lehet uszni.

A regi uzleti igenyeket sem kell teljesiteni, az ezzel kapcsolatos kodot is ki lehet dobni.

A strange game. The only winning move is not to play. How about a nice game of chess?

"Szinten jo buli lehet egy 50 eves szart takolni, es ugy versenyezni a Fintech startupokkal. Persze tudom, vannak AIX-es perverzek, akik meg elvezik is az ilyet. :)"

Az még bőven a mainframe kategóriás vasakból maradt kód lehet - anno nézegettem, meg tanulgattam a Cobol-t (is). Elvileg a mai, de még a 10-20 évvel ezelőtti szoftverek számára is egyszerű feladatokra használatos kódok tömkelegéről van szó - amiknél sokszor nem csak az a lényeg, hogy mit csinál, hanem az, hogy mit is csinál még... (Side effect) És nem, nem néhány száz soros toolok, hanem spagettikód, a legdurvább fajtából, ezer sorokban mérve.
Egy ilyen kódtömeg részekre bontása sem egyszerű (hogy "elemenként" portolják valami más nyelvre/környezetbe), miközben üzleti hasznot gyakorlatilag nem hoz a refaktorálás/újraírás, nagyon sok helyen emiatt (is) "nem piszkál, jó az úgy" irányvonalat képviselik...

Ja igen. Csak neha az ilyen spagetti miatt veszitenek pereket meg jon a bunti a felugyelettol.

Persze bizonyos esetekben olcsobb kifizetni, mint javitani - plane ujrairni.

Egyik ismerosom apja vett fel egy hitelt, amihez alairt egy nyilatkozatot, hogy ha nem fizetne, akkor hivogathatjak meg a munkahelyen is kereshetik. Aztan nem fizette, elhunyt, az ismerosom orokolte a hitelt. O viszont nem irt ala ilyen nyilatkozatot, ugyhogy amikor a bank beprobalkozott a munkahelyen, nagyon nagy szerencseje volt, hogy meguszta parszazezres karteritessel. A gond az volt, hogy betettek ugyanabba a "baszogathato" csoportba, pedig nem lett volna szabad.

A strange game. The only winning move is not to play. How about a nice game of chess?

ugyhogy amikor a bank beprobalkozott a munkahelyen, nagyon nagy szerencseje volt, hogy meguszta parszazezres karteritessel.

Mármint a banknak volt szerencséje h. az ismerősöd beperelte őket zaklatásért, és a banknak csak párszázezer forintjába került ez a baki.

Félreérthetően hivatkoztál a 2 szereplőre.

2 per volt, az elsoben kiderult, hogy a felmondas pillanataban nem volt tartozas - szabalytalanul szamitottak fel par dolgot.

A masodik szemelyisegi jogi per volt, ott az ismerosom perelte a bankot, mert a megkeresessel kellemetlen helyzetbe hoztak a korabbi munkahelyen. Ennek lett a vege a karterites. Nagyon nem akarok belemenni a reszletekbe a megkerdezese nelkul.

A strange game. The only winning move is not to play. How about a nice game of chess?

Természetesen nincs igaza, csak kinyilatkoztat. Ez egy elterjedt nézet, hogy sokan nem szeretnek újraírni, pedig néha muszáj.

Indokolgatnak ellene, hogy vagy túl nagy munka, vagy túl veszélyes. Én meg azt mondom, hogy ha valamelyik is fennáll, akkor vagy a fejlesztők alkalmatlanok, vagy a szoftver egy akkora szar, hogy nem újra kell akkor írni, hanem bedarálni, és sóval behinteni a helyét.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Egyrészt ez, másrészt meg a mostani emberek kevésbé kvalifikáltak, mint a korábbiak.

Ez persze nem hangzik jól, hiszen van agilitás, meg standup-meeting, meg színezős-aláhúzós IDE... Ettől még a mai átlag fejlesztőnek a PATH egy misztikum, egy ötsoros script-et nem tud önállóan megalkotni, az SQL-ről meg kb. annyit tud, hogy "No".

( gelei v | 2024. 08. 14., sze – 10:51 )

Csak atporgettem a topikot, ugyhogy lehet, hogy elsiklottam felette, de az "ujra kell irni a nullarol" ervek kozott nem latok olyan kerdeseket felteve, hogy mondjuk mennyibe kerulne ujrairni, vagy hogy mennyit sporolnanak az ujrairassal.

Nem érdekel mennyibe kerül, mert itt nem a költségek számítanak, hanem a fenntarthatóság, karbantarthatóság. Egész más szempontok. Bár ha költség oldaláról feszegetjük, ott is van egy olyan erős gyanúm, hogy az újraírás nem, vagy nem lényegesen lesz drágább, mint egy áttekinthetetlenre hízott/kuszálódott mamutkódot patkolni egyre kínkeservesebb, lassabb munkával. Nyilván nem azt mondom, hogy minden szoftvert írjanak újra ész nélkül, 2 hetente, pótcselekvésből. Itt azokról van szó, amik több évtizedes kódok, és emiatt máris kezelhetetlenre híznak, fejlesztők panaszkodnak, hogy ez gondot okoz nekik, vagy a bugok szaporodtak el rajta az utóbbi időben, amit nem tudnak fixálni. Ilyen esetekben komolyan megfontolandó.

Persze, lehet spúrnak, lustának lenni, vagy csak makacsságból nem újraírni, de sok esetben ráfizetés, későbbi ellehetetlenülés, aránytalan sok kínlódás lehet az ára.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Tokmindegy, hogy ragozod, a sor vegen van egy befekteto, aki tartja a markat. "Egész más szempontok", ugyan mar.

az újraírás nem, vagy nem lényegesen lesz drágább, mint egy áttekinthetetlenre hízott/kuszálódott mamutkódot patkolni egyre kínkeservesebb, lassabb munkával

Egyreszt folyamatosan fizetsz vs most rakd le az asztalra a penzt, nem mindegy. Masreszt amig te ujrairod epp a kodot, addig nincs uj fejlesztes, kinkeservesen se, ergo nincs mit eladni, ergo kibasznak a munkahelyedrol, es nincs mibol etetni a csaladodat.

Most egy cég termékéről beszélünk, ahol pénzért dolgoznak a fejlesztők. Újraírással két terméket kellene kezelni, legalább kétszerezni az erőforrásokat (ha az újra nincs legalább annyi erőforrás, mint a régire, akkor esélyes, hogy soha nem tudja kiváltani a továbbra is fejlesztendő terméket; másik opció lassítani az aktuális terméket, de annak az anyagi vonzata sem negligálható). Ez kőkemény.

A cikkben szerintem rengeteg igazság van, értelmezéshez 2000-es kontextusba is kell helyezni. Pl. más egy architektúra váltás 2000-ben és más egy architektúra váltás 2000-2020-as viszonylatban. Kevés a teljesen általános igazság, fekete-fehér helyzet, az átgondolkodás sosem árt.

Én újraírás ellenes vagyok. Refaktor lépésről lépésre, tégláról téglára. :) Ugyanis ekkor kb minden lépés haszonnal jár, míg az újraírás egy hatalmas bukás lehet nagy valószínűséggel. A refaktorálás fluktuációbarát megoldás.

Az újraírással általában az a baj, hogy nagyon sok nem (jól) dokumentált funkciót tud felhalmozni egy szoftver, nem is a komponenseken belül, hanem az azok közötti interakciókban. És ezeket sokszor elfelejtik az újraírás során, ezért oda jutnak, hogy lesz egy új, tiszta kódbázis, csak éppen nem működik. És mire ugyanúgy működő állapotba kerül, ugyanúgy gány lesz.

Természetesen az új rendszer bevezetését követő évben sokkal több lesz a szupport-igény, hiszen az új termék tele van mindenféle hibával, viszont az erőforrásigénye is sokszoros, különösen, hogy a DB-lekérdezések optimalizálását meg elmulasztották megcsinálni (ezt eredetileg az alvállalkozó alvállakozója vállalta, de az kiszállt a történetből, mert nem fizették ki)).

( NevemTeve | 2024. 08. 14., sze – 19:28 )

Beleolvasva az eredeti cikkbe, úgy vélem érteni, hogy a fő panasz az, hogy nehéz egy programot megértés nélkül módosítani.

Hát, kollégák, ezzel szembe kell nézni, ez egy ilyen ipar.

Az oké, hogy a filmeken a fejlesztés abból áll, hogy ikonokat huzigálunk a képernyőn, csak hát ez nem a valóság.

Egy jó specifikációval a kézben bármikor könnyen újra lehet írni egy szoftvert. Teljesen mindegy, hogy C-ben, PHP-ban, Cobolban vagy Rustban. Csak ugye sokan szeretik lefelejteni a specifikációt és a dokumentációt.
5-10 év múlva, amikor az eredeti fejlesztők/tesztelők/PM-k/PO-k már elhagyták a céget, akkor meg jön a pislogás.

Az implementáció a fejlesztő egy probléma megértésének és erre adott megoldásának a lenyomata. A programból nem derül ki hogy mi is az a probléma amit meg akartak oldani (funkcionális/logikai architektúra), miért úgy oldották meg (funkcionális allokáció) és hogy mik voltak a trade-off-ok. 

Mi pl. tipikusan nem speckó alapján írunk újra, mert speckó csak új fejlesztésnél készül, amit később felülír a való élet. Szóval ha modulok/microservice-ek újraírásáról van szó, akkor adott egy interfész (pl. egy gRPC service proto), és vannak tesztek. Simán újra lehet írni bármit, amíg e két dolog nem változik. Ha az interfészt vagy a teszteket módosítani kell, az már a második kategória.

A második kategória a nagyobb újraírás, amikor a kliensek számára is érezhető változás lesz. Ekkor meg tök mindegy, hogy mi volt régen a speckó, mert teljesen új speckóval indul egy új projekt, a friss kliens oldali, üzleti, felhasználói igények szerint. Ez néha már nem is egy szoftver módosítása, hanem egy új szoftver írása és a régi lecserélése.

Azért ismerjük el, hogy a példában szereplő Oracle RDBMS-beli hibajavításnál ezt kicsit nehéz egzaktul megfogalmazni, pl:

- Mit csinál a program?
Nagy sok mindent, de van olyan kontextus PL/SQL-ben, amikor egy 5-karakteres varchar nem tud belemenni egy 5-karakteres char-ba, csak ha to_char-ral "konvertáljuk"  [nem, nincs ékezetes betű a mesében, csak 7-bites ASCII]

- Mit kellene csinálnia a programnak?
Ugyanazt, mint eddig, kivéve, hogy a fenti hiba javuljon ki.

És aztán, ha minden fasza, és a teljes újraírás során létrejött magnus opusban kijavult az említett hiba, akkor egy órán belül jön a ticket, hogy azonnal lapátoljátok vissza bele ezt a hibát, mert egy csomó fontos kuncsaft a saját kódjában már épít erre a hibára, ezt nem lett volna szabad megbolygatni! :-)