Eldri kóða í Delphi endurhanna: draga úr áhættu, auka viðhaldshæfni, tryggja rekstur

Sem rekur viðskiptalega mikilvægt Delphi-forrit þekkir þetta átak: Það keyrir stöðugt, lýsir kjarnferlum og er djúpt samþætt gagnagrunnum, tengjum og vinnuferlum. Á sama tíma aukast breytingarkostnaður og áhætta með hverri útgáfu, því með árunum hafa safnast upp málamiðlanir, sértilvik og háðir. Einmitt hér tekur Legacy-Code in Delphi refactoren við: ekki sem „Rewrite“-verkefni, heldur sem stjórnandi umbætur á gangandi kerfi – með mælanlegum áhrifum á viðhald, útgáfufræðileika og rekstur.

Í framkvæmd bregst refactoring sjaldan við Delphi sjálfu heldur skorti á gagnsæi: Hvað er faglega viðkvæmt? Hvar liggja tæknilegar skuldir (þ.e. uppbyggingarvandamál sem gera seinni breytingar dýrari)? Hvaða hluta má snerta í viðhaldsglugga og hvaða ekki? Og hvernig er tryggt að „hreingerning“ skapi ekki nýjar villur eða frammistöðuvandamál í framleiðslu? Þessi grein lýsir hagnýtum aðgangi sem tekur bæði IT-stjórn og stjórnendur með: frá stöðumatinu yfir arkitektúr- og gagnamál til prófana, útgáfuferla og öryggismála.

Hvað merkir „Legacy“ í Delphi-verkefnum í raun?

„Legacy“ er oft jafnað við „gammalt“. Í fyrirtækjasamhengi er Legacy-kóði hins vegar fyrst og fremst kóði þar sem breytingaráhætta er mikil og hegðun er aðeins að hluta til skýrð. Þetta getur verið VCL-forrit (Visual Component Library, klassísk Windows-skjáborðsviðmót), en líka þjónusta, áætlunarstjóri eða client-server-kerfi.

Algengar Legacy-einkenni í Delphi-umhverfum eru:

• Þétt tenging: UI, gagnanálgun og viðskipta-rökfræði eru fléttaðar; breytingar valda aukaverkunum.
• Óskráðar reglur: Fagleg rökfræði er staðsett í atburðum, global breytum eða gagnagrunns-triggerum, ekki í skýrum einingum.
• Úreldar gagnanálganir: t.d. BDE (Borland Database Engine) eða einkaréttarbútar; skortur á pooling-/timeout-stefnum.
• Ósamræmt villumeðhöndlun: Undanþágur eru hunsaðar, tilkynningar lenda ekki í miðlægri skráningu.
• Byggingar- og útgáfaviðkvæmni: Háðir, slóðavandamál, mismunandi þýðendastillingar, handvirkar eftirfærslur.
• Skortur á prófunum: Þekking er bundin í höfðum eða í „klikkstíg“ reyndra notenda.

Mikilvægt: Legacy-kóði er ekki sjálfkrafa „slæmur“. Hann er oft niðurstaða tímapressu, tæknisjúkdóma og hagnýtra ákvarðana. Refactoring er þá fjárfesting í stjórnleika – frá sjónarhóli reksturs, öryggis, samræmis og breytingahraða.

Refactoring vs. Rewrite: Was sich für Betrieb und Risiko ändert

Endurgerð (Neuentwicklung) lofar hreinum byrjun, en hún færir oft langar samhliða fasa, nýjar villuflokkar og mikla flutningsáhættu. Refactoring hins vegar miðar að stigvaxandi umbótum með viðvarandi afhendingargetu. Fyrir IT-rekstur og fagsvið er þetta oft úrslitaaður munur: Kerfið helst í framleiðslu og umbætur eru afhentar í stjórnlegum pakka.

Hagnýt aðgreining:

• Refactoring: Uppbygging er bætt, ytra hegðun á að haldast óbreytt. Áhersla: viðhald, prófanleiki, stöðugleiki, frammistöðuauðlindir.
• Endurskipulagning/nútímavæðing: auk þess markvissar hegðunarbreytingar, t.d. ný viðmót, nýr gagnagrunnur, ný markmið fyrir vettvanginn.
• Rewrite: ný kóðagrunnur, yfirleitt nýtt UI/Architektur; krefst flutnings gagna, ferla, viðmóta – oft „Big Bang“ eða löng millifasa.

Fyrir ákvarðanatöku er þetta lykilatriði: Refactoring er ekki sjálfsmarkmið, heldur verkfæri til að draga úr breytingaáhættu. Þetta skiptir beint rekstrarlegu máli þegar forritið hefur áhrif á 24/7-ferla, framleiðslunæma ferla eða viðskiptavinamiðuð portál.

Refactoring á Legacy-kóða í Delphi: upphaf með traustri stöðuuppgjöf

Fyrsta skrefið er ekki tólið, heldur sameiginleg sýn á áhættu og markmið. Án slíkrar sýnar endar refactoring fljótt sem „við ryðum aðeins hér upp“ – og það er erfitt að réttlæta slíkt í rekstri.

1) Kortleggja mikilvægi og rekstrarlega raunveruleika

Skráið hvaða hlutar eru raunverulega viðskipta-kritískir: dagleg lokun, tengingar við ERP/DMS/CRM, skráning framleiðslugagna, reikningagerð, aðgangsstýring. Bætið við rekstrarbreytum: viðhaldsglugga, rollback-möguleikum, eftirliti (Monitoring), gagnamagni, töfukröfum.

Nýtilegar leiðbeinandi spurningar:

• Hvaða virkni þarf að halda gangandi jafnvel við hlutabrest (degradationsgeta)?
• Hvar eru „single points of failure“ (t.d. miðlægur Scheduler)?
• Hvaða gögn eru reglugerðar- eða persónuverndartæknilega viðkvæm?
• Hvaða samþættingar eru líklegastar til bilunar (skráainnflutningar, TCP/IP, SOAP/REST, Messaging)?

2) Gera tæknilegar skuldir sýnilegar — ekki aðeins kóðastíll

Í Delphi-verkefnum eru tæknilegar skuldir oft arkitektónskar: globalt ástand, síhringandi einingartengsl, erfitt prófanlegir gagnasamskiptar, eða UI-atburðir sem „orkestrering“. Mælikvarðar (t.d. flækjustig, einingastærð, óháðisrit/Abhängigkeitsgraph) hjálpa, en eru aðeins verðmætar ef þeir umbreytast í raunhæfar aðgerðir.

Hagnýt uppsetning er 2×2-flokkun:

• Oft breytt & áhættusamt: hæsta forgangsverkefni fyrir Refactoring.
• Oft breytt & lítil áhætta: bæta ferla/próf, minni uppbyggingarbreytingar.
• Sjaldan breytt & áhættusamt: stöðugleika- og varnarvinna (próf, logging), ekki nauðsynlegt að „fegra“ kerfið.
• Sjaldan breytt & lítil áhætta: láta meðvitað óbreytt.

3) Telja upp háðir kerfa: gögn, Schnittstellen, Laufzeit

Fyrir stjórnendur og verkefnaábyrgðaraðila skiptir máli hvað liggur utan kóðans: gagnagrunnsbakend, ODBC/OLE DB, skráardeilir, prent- og PDF-streymar, COM/ActiveX, Office-automation, Windows-services, áætlaðir Tasks, vottorð, proxy-stillingar.

Hér myndast kostnaður vegna Refactoring oft óbeint: „litlar“ breytingar geta krafist nýrrar uppsetningarreglu, nýrra aðgangsrétta eða nýrra eldveggsreglna. Þessar aukaverkanir ætti að skjalfesta snemma á tæknilegu landakorti.

Algengar vandamálssvæði í Delphi-legacy og hvernig á að taka á þeim markvisst

Refactoring verður viðráðanlegt ef það beinist að endurteknum mynstrum. Eftirfarandi svið eru í framkvæmd oft stærstu áhættu- og kostnaðarákvarðanirnar.

Monólitískar Forms: Wenn die UI das System zusammenhält

Margir VCL-forrit hafa sögulega vaxið upp sem „formamiðaðar“: formið hleður gögn, athugar reglur, skrifar tilbaka, kveikir á skýrslum og uppfærir aðra glugga. Þetta virkar – þar til mörg teymi eða mörg ár af breytingasögu rekast á það.

Reynslubundin aðferð í rekstri er að létta UI smám saman:

• Use-Case-nálægar þjónustur innleiða: faglegar aðgerðir sem skýrt nafngreindar aðferðir í stað atburðarkeðja.
• Kapsla gagnaaðgang: fyrirspurnir og transaktionir ekki í UI-atburðum, heldur í Data-Access-lögum.
• DTOs/Modelle (einföld gagnahlutir) nota, til að aðskilja formástand og gagnagrunnsástand.

Markmiðið er ekki „hreinleiki mynsturs“, heldur betri prófanleiki og færri aukaverkanir: Breyting á staðfestingu eða útreikningi má ekki ógna öllu klikkflæði notendaviðmótsins.

Nútímavæða gagnaaðgang: BDE leysa af hólmi, FireDAC samfellt nota

Ef enn er verið að nota BDE eða ósamræmd gagnaíhlut í rekstri, er refactoring oft samhliða nútímavæðingu rekstraráhættu. BDE er ekki aðeins gamalt, heldur oft erfitt í rekstri: driflar, stillingar, 32-bita háð og skortur á nútímalegum öryggismechanisma.

BDE-útskipt með innfæddu tengi (Delphis nútímaleg gagnaaðgangsbókasafn) er í mörgum tilvikum skynsamlegur staðall ef unnið er af festu: samræmdir tengiparametrar, skýr transaktionsmörk, tímamörk (timeouts), poolun og hreint undantekningarmeðhöndlun. Dæmigerðar refactoring-aðgerðir á þessu sviði:

• Samræma tengjastjórnun: miðlæg Factory/Provider í stað „hvert form hefur sína tengingu“.
• Gera transaktionsskref skýr: Begin/Commit/Rollback sem hluti af Use-Case, ekki falin í UI.
• Parametriserte Queries nota samkvæmlega til að minnka SQL-Injection-áhættu og vandamál með sértákn.
• Skilgreina tímamörk og endurtilraunir, svo bið eða stopp í neti leiði ekki til „frosinna“ viðmóta.

Fyrir IT-rekstur er mikilvægt að nýjar tengingastefnur séu samræmdar við gagnagrunnsrekstur (t.d. hámarksfjöldi tenginga, pool-stærðir, deadlock-meðhöndlun, viðhaldsgluggar fyrir skema-breytingar).

Unit-Abhängigkeiten und „globale Zustände“ sem helsta orsök aukaverkana

Delphi-Units með stórum interface-köflum, mörgum Uses-færslum og globalum singletons eru dæmigerðir hvatar aukaverkana. Lítil breyting í einni Unit getur kallað á endurbyggingarkasköður eða brotið falda upphafsrunu.

Pragmatísk skref sem hafa reynst í legacy-verkefnum:

• Ákvarða stefnu á háðum: t.d. UI → Application Services → Domain/Logik → Data Access → Infrastruktur.
• Samræma upphafssetningu: skýr ræsirað í stað Unit-initialization sem falin stýring.
• Minimera globalar breytur: halda ástandi í hlutum, skýra líftíma og eignarhald.

Þetta eykur stöðugleika: ef ræsingin er determinísk eru bilanir eftir uppfærslur eða stillingabreytingar mun betur undir stjórn.

Þráðarvinnsla og samstilling: stöðugleiki framar „frammistöðubestun“

Margir legacy-forrit þróast með tímanum í samhliða keyrslu: bakgrunnsinnflutningur, polling, samskipti við tæki, samhliða vinnsla. Án skýrra reglna myndast deadlocks, viðmótsvandamál eða race conditions (aðgangsátök vegna samhliða framkvæmdar).

Fyrir rekstur og stuðning er þetta vandamál, því það veldur oft „óendurgeranlegum“ villum. Endurskipulagning ætti að miða við staðla í þessu samhengi:

• Skýr ábyrgð fyrir Threads/Tasks og skilgreindur lokunarferill (til að uppfærslur/niðurfellingar festist ekki).
• Logging pro Worker með korrelasjónar‑ID til að rekja ferla.
• Lágmarka samstillingu og innkapsla aðgang að UI stranglega (UI‑Thread‑Regel).

Ef þið viljið kafa dýpra er gagnlegt að setja inn innri tengil á grein um traust mynstur með TThread og Synchronize, því málið er við Legacy‑Refactoring oft flöskuhálsinn fyrir stöðugleika.

Arkitektúrmarkmið: Lagaskipting sem verkfæri, ekki dogma

Fyrir margar Delphi‑núverandi lausnir er hagkvæmt markmið að hafa skýra lagskipan (oft talin „3‑laga“): framsetning (UI), viðskipta‑/forritalógík (Use Cases/Services) og aðgangur að gögnum (Repositories/DAO). Mikilvægt er rekstrarsjónarhornið: lagaskipting auðveldar prófanir, uppfærslur og síðar aðskilnað tengja.

Konkréttir kostir fyrir fyrirtæki:

• Bæta við tengi (t.d. REST‑API), án þess að UI‑lógík þurfi að afritast.
• Hlutaendurnýjun: gagnagrunnsskipt eða BDE-Ablosung mit nativer Anbindung‑umbreyting getur verið bundin í einu lagi.
• Viðhald: Villur er auðveldara að afmarka, því ábyrgðarsvið í kóðanum eru skýrari.

Raunsætt markmið tekur mið af því að Legacy‑kerfi verða sjaldan „hrein“. Ákvarðandi er að stefnan sé rétt og að nýjar breytingar mýki ekki upp bygginguna aftur.

Prófunarstefna fyrir Delphi‑endurskipulagningu: Hvernig frysta hegðun áður en breytingar eru gerðar

Endurskipulagning án prófanna er í viðskiptalega mikilvægum kerfum áhætta. Að sama skapi er full sjálfvirkni prófana oft ekki raunhæf til skamms tíma. Meginhugmyndin er því: prófa markvisst þar sem áhætta og breytingapressan eru mest.

Golden Master og regressíontest: Hagnýtt fyrir Legacy

„Golden Master“ er viðmiðun fyrir núverandi hegðun: inntök og vænt úttök eru skráðar til að greina frávik eftir breytingar. Þetta hentar vel fyrir skýrslur, útreikninga, útflutninga, import‑pipelinur eða svör við tengjum.

Mikilvægt fyrir rekstur: Golden‑Master‑próf draga úr áhættu að aukaverkanir komi aðeins í ljós eftir innleiðingu – og þau styðja hraðar ákvarðanir um Hotfix þar sem frávik eru beinlínis mælanleg.

Integrationstestar um gagnagrunn og tengi

Margir villur eiga sér ekki stað í hreinni faglógík, heldur við kerfismörk: viðskipti/Transaktionen, kóðun (t.d. Unicode), tímastimplar, tugabrotsmerki, réttindi, netverkstruflanir. Integrationstestar ættu því að ná yfir að minnsta kosti eftirfarandi atriði:

• Hegðun við viðskipti við villur (Rollback, hlutuppfærslur, læsingar).
• Kóðun (Encoding) við inn-/útflutning (CSV, XML, JSON), sérstaklega varðandi sérstök tákn.
• Frammistöðulíkön fyrir dæmigerðar gagnamagnsstærðir, til að greina smám saman versnandi frammistöðu.

Handvirk prófanatilvik haldast áfram – en skipulögð

Þar sem sjálfvirkni (enn) vantar, hjálpa uppbyggileg handvirk prófanaplan sem eru tengd útgáfum. Frá rekstrarsjónarhóli er mikilvægt að prófanatilvik innihaldi líka rekstraratriði: uppsetningar‑/uppfærsluferil, réttindi, stillingar, Logging/Monitoring, prentara/PDF og netverksslóðir.

Gögn og flutningur: Endurskipulagning ákvarðast oft af gagnaskema

Í Delphi-kerfum hafa gagnagrunnsstrúktúrar vaxið upp yfir mörg ár. Refactoring rekst oft á „sögulegar“ töflur, tvöfalt föld eða fagið yfirhlaðin dálka. Meginatriðið: breytingar á skema hafa áhrif á rekstur, öryggisafrit/endurreisn, eftirmyndun, skýrslugerð og viðmót.

Gera skemabreytingar áætlanlegar

Áreiðanlegt er að nota aðferð með skýrt útgáfustýrðum gagnagrunnsmigrationum: hver breyting á skema er skjalfest sem endurframkvæmanlegt skref, með innifalinni afturkallastefnu. Jafnvel þótt migrationar séu í upphafi framkvæmdar handvirkt, er aga nauðsynlegur: engin „við breytum þetta fljótt í framleiðslu“.

Fyrir útgáfaöryggi ættuð þið að skilgreina:

• Niðurtímaþörf: Er netflutningur mögulegur eða þarf viðhaldsglugga?
• Afturkallastefna: Gögnsamrýmanleiki við afturkall, afrit fyrir migration, endurræsiplan.
• Samhæfingarfasi: Forritið getur tímabundið starfað með gamla og nýja skemað (t.d. viðbótardálkar, Views).

Ekki vanmeta gagnagæði og hreinsun

Endurskipulagning afhjúpar oft gagnavandamál sem áður hafa „fylgt með“: ógild gildi, ósamræmi, vantar ytri lykla. Hér er mikilvægt að taka faglega ákvörðun um hvað telst rétt. Tæknilega ætti kerfið í framhaldinu að staðfesta gögn skýrara og skrá villa á áreiðanlegan hátt fremur en að leiðrétta þær hljóðlega.

Bæta við viðmótum án þess að gera arfleifðarkerfið óstöðugt

Margir fyrirtæki framkvæma Refactoring á Delphi-eignum vegna þess að nýjar kröfur krefjast samþættinga: portalar, BI, farsímaferlar, tengingar við samstarfsaðila. Algengasta mistökin er að knýja viðmót beint úr UI-rökfræði eða „einhvers staðar úr kóðanum“. Betra er að leggja viðmót á samræmda þjónustulagslínu sem skapast við Refactoring.

Þegar REST-API (Representational State Transfer, algeng vef-API yfir HTTP/JSON) er bætt við, eru eftirfarandi þættir úr rekstrar- og öryggissjónarmiði sérstaklega mikilvægir:

• AuthN/AuthZ: Aðgreina auðkenningu og heimild; t.d. tokens, SAML 2.0 í samhengi fyrirtækja-SSO, skýr hlutverkalíkön.
• Rate limits og timeouts: til að koma í veg fyrir að utanaðkomandi köll hindri bakendann.
• Útgáfustjórnun: Skilgreina API-útgáfur til að brjóta ekki viðskiptavini við hverja breytingu.
• Observability: strúktúrerð skráning, korrelasjónar-IDs, mælikvarðar (villaþættir, biðtími).

Innri tengill á ítarlegri grein um uppsetningu REST-API fyrir eldri hugbúnað fellur hér vel að efninu, því viðmót í móderniseringsverkefnum eru sjaldan „viðbót“ heldur sjálfstætt rekstrarvara.

Öryggi og samræmi: Refactoring sem tækifæri til að loka öryggisgötum

Arfleifð þýðir oft að öryggisforsendur eru eldri en núverandi ógnarlíkan. Við Refactoring ættuð þið að a.m.k. kanna hvort kerfið þurfi uppfærslu á eftirfarandi sviðum:

• Auðkenni og leyndarmál: engin lykilorð í INI-skrám eða í kóða; örugg geymsla og regluleg endurnýjun.
• Dulkóðun í flutningi: TLS fyrir viðmót, skipulögð vottorðastjórnun.
• Least Privilege: gagnagrunnsnotendur og skráarheimildir sem minnstar; aðskilin hlutverk fyrir lestur/ritun/stjórnun.

Fyrir IT-stjórnendur er þetta lykilviðskiptaávinningur: Refactoring dregur ekki aðeins úr viðhaldskostnaði heldur getur einnig lækkað öryggis- og endurskoðunaráhættu ef framkvæmd er kerfisbundin.

Release- und Betriebsprozess: Ohne saubere Pipeline wird Refactoring teuer

Mörg Delphi-legacy-verkefni þjást minna af kóðanum en af ferlinum: samsetningar (Builds) eru ólíkar eftir vinnustöðum, útgáfur eru handvirkar og villur er ekki hægt að rekja nákvæmlega. Refactoring ætti því alltaf líka að styrkja afhendingarferlið.

Endurframleiðanleiki samsetninga og stillingastjórnun

Frá sjónarhóli stjórnunar og endurskoðana er mikilvægt að útgáfa sé endurframleidd: sömu uppsprettur, sömu útgáfur af compilerum og bókasöfnum, sömu háðir. Þetta felur í sér skýrt aðskilin stillingarákvæði fyrir þróun, prófanir og framleiðslu (t.d. gagnagrunnsendapunktar, logging-stig, feature-flaggar).

Loggun, eftirlit og þjónustuhæfni

„Það gerðist eitthvað“ dugar ekki í rekstri. Refactoring er gott tækifæri til að innleiða samræmda loggun: uppbyggðar loggfærslur, ótvíræð villukóðar, samhengi (notandi, mandant, beiðni, viðmót) og skýr aðgreining milli tæknilegra villa og faglegra staðfestinga.

Fyrir ferla sem ganga nánast 24/7 eru auk þess gagnleg:

• Heilsufarsskoðanir (Health Checks) (t.d. gagnagrunnstenging, biðröðarteppa, minni- og auðlindanotkun),
• Viðvörun eftir alvarleikaflokki,
• Runbooks fyrir endurræsingar og algengar truflanir.

Hagnýt áætlun fyrir Refactoring í 6 skrefum

Til að Refactoring festni ekki í daglegum rekstri gagnast skýr áætlun sem er samrýmanleg útgáfusyklum. Hér er reynslubundið ferli:

1. Búa til áhættu- og breytingakort (módúlar, viðmót, gögn, rekstur).
2. Spanna verndarnet: loggstaðall, fyrstu regression-/Golden-Master-prófanir fyrir krítískar leiðir.
3. Setja arkitektúrulegar aðskilnaðarlínur: þjónustulag og gagnaaðgangsinnslagg sem „nýja venjan“ fyrir breytingar.
4. Endurgera hotspota: þau módúl sem oft eru breytt og valda bilunum (nýta villutölfræði og breytingarsögu).
5. Samlaga gagnaaðgang: FireDAC/transaksjónir/tímamörk samræma, mæla frammistöðu, skoða deadlocks.
6. Opna nútímavæðingarleiðir: viðmót (REST), pallmál (Unicode/64‑biti), stigvaxin UI‑nútímavæðing þar sem við á.

Kjarninn er röðin: fyrst gagnsæi og varnir, síðan uppbyggingarbreytingar og loks stærri umbreytingar. Svo helst lausnin afhendingarfær og rekstrarstöðug.

Hvenær Refactoring dugar ekki: merki um að stærri nútímavæðing sé nauðsynleg

Það eru aðstæður þar sem hreint Refactoring leysir ekki flöskuhálsinn. Algeng merki:

• Tæknilegar blindgötur: gagnagrunnsdriverar sem eru ekki lengur studdir, íhlutir sem ekki er hægt að patcha, harðar 32‑bít háðir.
• Arkitektúrinn hentar ekki lengur: t.d. þarf forritið að keyra sem þjónustulandslag en allt er miðað við UI.
• Skalun og aðgengileiki: kröfur um mandant-færni, háan aðgengileika eða fjartengingu er aðeins hægt að uppfylla með byggingalegum breytingum.
• Öryggiskröfur: auðkenning/SSO, audit, dulkóðun er ekki hægt að bæta við án umfangsmikilla umbreytinga.

Jafnvel þá er Refactoring oft skynsamlegur hluti: það skapar skipulag til að aðskilja tilteknar einingar í stað þess að skipta út öllu kerfinu í einu.

Niðurstaða: Refactoring sem tæknileg ábyrgð í rekstri

Að refactora Legacy-Code í Delphi er fyrst og fremst spurning um forgangsröðun, áhættustjórnun og tengsl við rekstur. Ef þið byrjið með trausta stöðumat, tryggið hotspots, samræmið gagnaaðgengi og aðgreiningarlínur arkitektúrsins og beinið prófunum og logging markvisst á gagnaríkar leiðir, breytist „hreinsun“ í stýranlegt endurnýjunarverkefni. Niðurstaðan er ekki aðeins læsilegri kóði, heldur kerfi sem er áreiðanlegra í rekstri, öruggara að breyta og einfaldara að samþætta.

Ef þið viljið stöðuga uppbyggingu eða nútímavæðingu á ykkar Delphi-lausn, ræðum við gjarnan saman upphafsstöðu, áhættu og raunhæfan Refactoring-vegvísir:

Í faglegu samhengi gegna einnig Delphi nútímavæðing og Delphi Refactoring mikilvægu hlutverki þegar samþættingar, gagnastraumar og frekari þróun þurfa að vinna náið saman.

Ræddu verkefni eða nútímavæðingarverkefni með Net-Base.