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

Sá sem rekur viðskiptafræðilega mikilvæga Delphi-umsókn þekkir þetta spennusvið: hún keyrir stöðugt, myndar kjarnaferla og er djúpt samþætt gagnagrunnum, viðmótum og vinnuferlum. Á sama tíma aukast vinnuálag breytinga og áhætta með hverri útgáfu, því yfir mörg ár hafa safnast fyrir málamiðlanir, sértilfelli og háðir kerfa. Hér kemur Endurskipulagning (refactoring) á Legacy-kóða í Delphi inn: ekki sem „Rewrite“-verkefni, heldur sem stýrður umbrot á keyrandi kerfi – með mælanlegum áhrifum á viðhald, útgáfuvist og rekstur.

Í framkvæmd bregst refactoring sjaldnast vegna Delphi sjálfs, heldur vegna skorts á gagnsæi: Hvað er faglega mikilvægt? Hvar liggja tæknileg lán (þ.e. uppbyggingargallar sem gera seinni breytingar dýrari)? Hvaða hlutar má snerta í viðhaldsglugga og hvaða ekki? Og hvernig er komið í veg fyrir að „hreinsun“ valdi nýjum villum eða frammistöðuvandamálum í framleiðslu? Þessi grein lýsir hagnýtum aðferðum sem taka IT-stjórn og rekstrarteymi með: frá stöðumatinu yfir arkitektúr- og gagnamál til prófana, útgáfuferlis og öryggis.

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

„Legacy“ er oft sammerkt við „gammelt“. Í fyrirtækjaumhverfi er Legacy-kóði þó fyrst og fremst kóði þar sem áhætta breytinga er mikil og hegðun er aðeins að hluta útskýrð. Það getur verið VCL-forrit (Visual Component Library, klassískt Windows-skjáviðmót), en líka þjónusta, tímastjóri eða client-server-kerfi.

Dæmigerð einkenni Legacy í Delphi-umhverfum eru:

• Sterk tenging: notendaviðmót, gagnaaðgangur og viðskipta-lógík eru blönduð saman; breytingar draga með sér aukaverkanir.
• Ígrundaðar reglur: faglógík er falin í events, global breytum eða gagnagrunns-triggerum fremur en í skýrum módelum.
• Úrelt gagnaaðgöng: t.d. BDE (Borland Database Engine) eða sérleyfisþættir; skortur á pooling-/timeout-stefnum.
• Óstöðugt villumeðhöndlun: Exceptions eru kyngdar, tilkynningar lenda ekki í miðlægu logging.
• Viðkvæmni byggingar og útgáfu: háðir þættir, slóðarvandamál, mismunandi stillingar þýðanda, handvirk eftirvinna.
• Skortur á prófunum: þekkingin er í höfðum fólks eða í „smelluferli“ reynslumikilla notenda.

Áhersla: Legacy-kóði er ekki sjálfkrafa „slæmur“. Oft er hann afrakstur tímapressa, tæknisykla og pragmatískra ákvarðana. Refactoring er þá fjárfesting í stjórnleika – úr rekstrarsjónarmiði, öryggis, samræmis og breytingahraða.

Refactoring vs. Rewrite: Hvað breytist fyrir rekstur og áhættu

Rewrite (nýsmíði) býður upp á hreinan upphafspunkt, en fylgja honum oft langar samkeyrslutímabil, nýir villuflokkar og mikil flutningsáhætta. Refactoring miðar aftur á móti að smáum og stigvaxandi umbótum með viðvarandi afhendingargetu. Fyrir IT-rekstur og fagdeildir er það oft ráðandi munurinn: kerfið helst í framleiðslu og umbætur eru afhentar í yfirstjórnanlegum pakkningum.

Hagnýt afmörkun:

• Refactoring: uppbygging er bætt, ytra atferli á að haldast óbreytt. Áhersla: viðhald, prófanleiki, stöðugleiki, afgangsframmistaða.
• Endurskipulagning/núvæðing: auk markvissra hegðunarbreytinga, t.d. nýrra viðmóta, nýs gagnagrunns, nýrra markmiða fyrir pallinn.
• Endurritun: ný grunnkóði, yfirleitt nýtt notendaviðmót/arkitektúr; krefst flutnings gagna, ferla, tenginga – oft „Big Bang“ eða löng millistigsfasa.

Fyrir ákvarðendur er þetta lykilatriði: Refactoring er ekki sjálfsmarkmið, heldur verkfæri til að draga úr áhættu vegna breytinga. Þetta er beint við rekstrartengdar ákvarðanir þegar forritið hefur áhrif á 24/7-ferla, framleiðslunálæga vinnuferla eða viðskiptavinamiðuð gáttkerfi.

Legacy-kóða í Delphi endurbæta: Byrja með áreiðanlegri stöðuskoðun

Fyrsta skrefið er ekki tól, heldur sameiginleg sýn á áhættu og markmið. Án þessarar sýnar lendir endurhönnun fljótt í „við röðum aðeins upp hér“ – og það er erfitt að réttlæta slíkt í rekstri.

1) Meta mikilvægi og rekstrarlega raunveruleika

Skráið hvaða hlutar eru í raun viðskipta-kritískir: daglokun, tengingar við ERP/DMS/CRM, söfnun framleiðslugagna, reikningsgerð, aðgangsstýring. Bætið við rekstrarbreytum: viðhaldsgluggar, möguleikar á rollback, eftirlit, gagnamagni, latenskröfur.

Hagnýtar leiðarspurningar:

• Hvaða aðgerðir þurfa að halda áfram við hlutaða bilun (degradationshæfni)?
• Hvar eru „Single Points of Failure“ (t.d. miðlægur Scheduler)?
• Hvaða gögn eru viðkvæm úr stjórnsýslu- eða persónuverndarsjónarmiði?
• Hvaða samþættingar eru næmastar fyrir truflunum (skráarinnflutningar, TCP/IP, SOAP/REST, messaging)?

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

Í Delphi-verkefnum eru tæknilegar skuldir oft arkitektónískar: alþjóðlegir/stöðugildi, hringtengdar einingartengingar, erfitt að prófa gagnaaðgengi, eða UI-atburðir sem „orkestrering“. Mælikvarðar (t.d. flækjustig, einingastærð, háðsnet) hjálpa, en eru aðeins verðmætir ef þeir þýðast í aðgerðir.

Hagnýt 2×2-greining er:

• Oft breytt og áhættusamt: æðsti forgangur fyrir endurhönnun.
• Oft breytt og lág áhætta: bæta ferla og prófanir, minni uppbyggingarbreytingar.
• Sjaldan breytt og áhættusamt: stöðugleikaaðgerðir/varnir (prófanir, skráning), ekki endilega „gera fallegt“.
• Sjaldan breytt og lág áhætta: láta meðvitað óbreytt.

3) Telja upp háðir þættir: gögn, tengingar, keyrsluumhverfi

Fyrir stjórnendur og verkefnisábyrgðaraðila skiptir mestu máli hvað hengir utan kóðans: gagnagrunnsbakendar, ODBC/OLE DB, skráardeildir, útskriftar- og PDF-flæði, COM/ActiveX, Office-sjálfvirkni, Windows-þjónustur, áætlaðir Tasks, vottorð, proxy-stillingar.

Hér myndast kostnaður við endurhönnun oft óbeint: „lítil“ breyting getur krafist nýrrar installer-rökfræði, nýrra aðgangsréttinda eða nýrra eldveggsreglna. Þessar aukaverkanir ætti að skjalfesta snemma í tæknilegu landakorti.

Algengar vandamálasvæði í Delphi-legacy og hvernig á að takast á við þau markvisst

Endurhönnun verður viðráðanleg þegar hún beinist að endurteknu mynstri. Eftirfarandi svið eru í framkvæmd oft stærstu áhættu- og kostnaðavaldarnir.

Monólítískar Forms: Þegar notendaviðmótið heldur kerfinu saman

Mörg VCL-forrit hafa sögulega vaxið upp sem „Form-driven“: eyðublaðið hleður gögn, athugar reglur, skrifar aftur, kallar fram skýrslur og uppfærir önnur viðmót. Þetta virkar — þar til mörg teymi eða margra ára breytingasaga skarast á því.

Í rekstri hefur reynst árangursríkt að létta notendaviðmótið stig af stigi:

• Use-Case-nálægar þjónustur innleiða: faglegar aðgerðir sem skýrt nefndar aðferðir í stað atburðakeðja.
• Fanga gagnaaðgang: fyrirspurnir/viðskipti ekki í UI-atburðum, heldur í gagnaaðgangslögum.
• DTOs/Modelle (einfaldir gagnahlutir) nota til að aðskilja ástand formsins og ástand gagnagrunns.

Markmiðið er ekki „Pattern-Reinheit“, heldur betri prófanleiki og færri aukaverkanir: breyting á staðfestingu eða útreikningi má ekki ógna allri smellastöðvum í viðmótinu.

Datenzugriff modernisieren: BDE ablösen, FireDAC konsistent einsetzen

Ef BDE eða óeininglegar gagnahlutar eru enn notaðir, þá er endurskipulagning oft jafnframt nútímavæðing rekstrarlegs áhættu. BDE er ekki bara gamalt, heldur oft erfitt í rekstri: drifarar, uppsetning, 32‑bita háðar og skortur á nútíma öryggisleiðum.

BDE-Ablosung mit nativer Anbindung (Delphis moderne Datenzugriffsbibliothek) er í mörgum tilvikum skynsamlegur staðall þegar unnið er af festu: samræmd tengiparametrar, skýr transaktionsmörk, tímamörk, Pooling og hreint Exception-Handling. Dæmigerðar endurskipulagningar í þessu samhengi eru til dæmis:

• Samræma tengjastjórnun: miðlæg Factory/Provider í stað „hvert form á sína Connection“.
• Gera viðskipti skýr: Begin/Commit/Rollback sem hluti af Use-Case, ekki falin í UI.
• Nota parameteraðar Queries af festu til að minnka SQL‑Injection‑áhættu og vandamál með sérstafi.
• Skilgreina Timeouts og Retries, svo að tafir í neti leiði ekki til „frystra“ viðmóta.

Fyrir rekstur IT er mikilvægt að nýjar tengingastefnur séu samræmdar gagnagrunnsrekstri (t.d. hámarksfjöldi tenginga, púlastærðir, Deadlock‑Handling, viðhaldsgluggar fyrir skema‑breytingar).

Unit-Abhängigkeiten und „globale Zustände“ als Hauptursache für Seiteneffekte

Delphi‑Units með stórum interface‑kölum, mörgum Uses‑færslum og globalum Singletons eru dæmigerð hvatning fyrir aukaverkanir. Lítil breyting í einni Unit getur dregið eftir sig endurbyggingar‑foss eða brotið falnar upphafsröðunarreglur.

Hagnýtar aðgerðir sem reynast í Legacy‑verkefnum:

• Skilgreina stefnu háðna: t.d. UI → Application Services → Domain/Logik → Data Access → Infrastruktur.
• Samræma upphaf: skýr ræsiröð í stað Unit‑Initialization sem falinn stýringarmáti.
• Minnka globalar breytur: halda ástandi í hlutum, skýra líftíma og ownership.

Þetta bætir stöðugleika: þegar ræsingu er hægt að spá fyrir um (deterministisch), eru bilanir eftir uppfærslur eða stillingabreytingar mun auðveldari í meðhöndlun.

Threading und Synchronisation: Stabilität vor „Performance-Optimierung“

Margir legacy‑forrit þróast með samhliða keyrslu yfir tíma: bakgrunnsinnflutningar, polling, samskipti við tæki, samhliða úrvinnsla. Án skýrra reglna myndast deadlocks, hangur í UI eða race conditions (aðgangsátök vegna samtímis keyrslu).

Fyrir rekstur og stuðning er þetta vandamál, því það veldur oft „óendurteknum“ villum. Refactoring ætti hér að miða að stöðlum:

• Skýr ábyrgð fyrir þræðum/verkum og skilgreind lokun (til að uppfærslur eða lokun festist ekki).
• Logging fyrir hvern worker með korrelasjóns‑ID, til að rekja ferla.
• Lágmarka samstillingu og strangt aðskilja aðgang að UI (UI‑Thread‑regla).

Ef þið viljið kafa dýpra, er æskilegt að setja inn innri hlekk á grein um traust mynstur með TThread og Synchronize, því þetta er gjarnan þröngt skorð í stöðugleika við Legacy‑Refactoring.

Markmið í arkitektúr: Lagaskipting sem verkfæri, ekki dogma

Raunsætt markmið fyrir margar Delphi-eftirstöðvarlausnir er skýr lagskipan (oft skilin sem „3‑lög“): framsetning (UI), forritalógík (Use Cases/Services) og gagnaaðgangur (Repositories/DAO). Mikilvægt er rekstrarsjónarhornið: lagaskipting auðveldar prófanir, uppfærslur og síðar útklippingu viðmóta.

Konkréttir ávinningar fyrir fyrirtæki:

• Bæta við viðmót (t.d. REST-API), án þess að UI‑lógík þurfi að afritast.
• Hlutabundin nýmundun: Gagnagrunnsskipt eða BDE-Ablosung mit nativer Anbindung-umbreytingar má einangra í einu lagi.
• Viðhald: Villur er auðveldara að einangra því ábyrgðarsvið í kóðanum eru skýrari.

Raunsætt markmið gerir ráð fyrir að Legacy‑kerfi verði sjaldan „hrein“. Ákveðið er að áttin sé rétt og að nýjar breytingar mýki ekki upp bygginguna aftur.

Prófunarstefna fyrir Delphi‑Refactoring: Hvernig frysta á hegðun áður en endurbyggt er

Refactoring án prófana er áhætta í viðskiptagagnrýnum kerfum. Samt er full sjálfvirkni prófana oft ekki raunhæf til skamms tíma. Aðalhugmyndin er því: prófa markvisst þar sem áhætta og breytingaþrýstingur er mikill.

Golden Master og Regression: Praktisch für Legacy

„Golden Master“ er viðmið fyrir núverandi hegðun: inntak og vænt útgögn eru skráð til að uppgötva frávik eftir breytingar. Þetta hentar fyrir skýrslur, útreikninga, útflutning, innflutnings‑pípur eða viðmóts­svar.

Mikilvægt fyrir rekstur: Golden‑Master‑próf minnka áhættu þess að hliðaráhrif sjást fyrst eftir dreifingu – og styðja við hraðar hotfix‑ákvarðanir, því frávik verða mælanleg.

Samþættingarpróf um gagnagrunn og viðmót

Margir villur eiga sér ekki rót í hreinri faglógík heldur á kerfismörkum: viðskiptatransakciónir, kóðun (t.d. Unicode), tímastimplar, tugamerki, réttindastillingar og nettruflanir. Samþættingarpróf ættu því að ná yfir að minnsta kosti eftirfarandi atriði:

• Hegðun viðskipta við villur (Rollback, hlutuppfærslur, læsingar).
• Kóðun við inn-/útflutning (CSV, XML, JSON), sérstaklega sértákn.
• Frammistöðulíkan fyrir dæmigerða gagnafjölda til að greina hæg‑vaxandi versnunar.

Handprófanir haldast – en skipulagðar

Þar sem sjálfvirkni vantar (enn), hjálpa skipulagðir handprófunarplön sem tengd eru við útgáfur. Frá stjórnunar-/rekstrarsjónarhóli skiptir það máli að prófanir innihaldi einnig rekstraratriði: uppsetningar-/uppfærslugöng, réttindi, stillingar, logging/eftirlit, prentarar/PDF og netleiðir.

Gögn og flutningur: Refactoring er oft metið út frá gagnaskema

Í Delphi-kerfum hafa gagnagrunnsstrúktúrar vaxið upp yfir ár. Endurskipulagning (refactoring) rekst oft á „sögulegar“ töflur, tvöfalda reiti eða faglega ofhlaðna dálka. Lykilatriðið: skemabreytingar hafa áhrif á rekstur, Backup/Restore, afritun, skýrslugerð og viðmót.

Gera skemabreytingar áætlanalegar

Áreiðanlegur aðferð er að nota skýrt útgáfustýrðar gagnagrunnsmigrationir: hver breyting á skema er skrásett sem endurgeranlegur skref, þ.m.t. aðgerð til að rulla aftur (Rollback-Strategie). Jafnvel þegar migrationir eru upphaflega framkvæmdar handvirkt, skiptir aga höfuðmáli: engin „við breytum hratt í framleiðslu“.

Fyrir útgáfuvissu ættuð þið að skilgreina:

• Þörf á niðurtíma: er hægt að gera uppfærslu á netinu eða þarf viðhaldsglugga?
• Afturkallaáætlun: gagnasamhæfi við rollback, varabackup áður en migration fer af stað, endurræsiplan.
• Samhæfnisfasi: forritið getur starfað tímabundið með gamla og nýja skemað (t.d. aukadálkar, views).

Ekki vanmeta gagnagæði og hreinsun

Endurskipulagning afhjúpar oft gagnavandamál sem áður hafa „fylgt með“ kerfinu: ógild gildi, ósamræmi, vantar foreign keys. Hér er mikilvægt að taka faglega ákvörðun um hvað er rétt. Tæknilega ætti forritið að framkvæma strangari staðfestingar í framtíðinni og skrá villaáætlanir á skiljanlegan hátt í stað þess að leiðrétta þegjandi.

Bæta við viðmótum án þess að óstabílísera erfðakerfið

Mörg fyrirtæki endurskipuleggja Delphi-eignir vegna nýrra kröfu um samþættingar: gáttir, BI, farsímaferlar, tengingar við samstarfsaðila. Algengasti mistök er að reka viðmótssnið eða „n-hvers staðar úr kóðanum“ beint sem gagnaveitu. Betra er að leggja viðmót á samrædda þjónustulagslögun sem myndast þegar refactoring fer fram.

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

• AuthN/AuthZ: aðskiljið auðkenningu og heimildastýringar á hreinan hátt; t.d. tokens, SAML 2.0 í samhengi fyrirtækja-SSO, skýr hlutverkalíkan.
• Takmörkun á fyrirspurnum og tímamörk: til að koma í veg fyrir að ytri kalla blokki backend.
• Útgáfustýring: skilgreinið API-útgáfur til að brjóta ekki klientforrit við hverja breytingu.
• Observability: strúktúreruð logs, korrelasjónar-ID, mælikvarðar (villuhlutföll, seinkun).

Internur hlekkur á ítarlegan grein um að bæta REST-API við rekstrarbúnað getur passað mjög vel hér, því viðmót eru í moderniseringarverkefnum sjaldan „aukahlutur“, heldur eigin rekstrarvara.

Öryggi og compliance: nýtt tækifæri til að loka öryggisgötum

Legacy þýðir oft: öryggisforsendur eru eldri en núverandi ógnarstaða. Við refactoring ættuð þið að a.m.k. athuga hvort kerfið þarf að uppfæra eftirfarandi atriði:

• Credentials und Secrets: engin lykilorð í INI-skrám eða í kóða; örugg geymsla og regluleg endurnýjun.
• Flutningsdulkóðun: TLS fyrir viðmót, fagleg skírteinisstjórnun.
• Least Privilege: gagnagrunnsnotendur og skráaréttindi eins takmörkuð og mögulegt er; aðskilin hlutverk fyrir les, skrif og stjórn.

Fyrir IT-stjórn er þetta megin viðskiptalegt gildi: Refactoring dregur ekki aðeins úr viðhaldskostnaði heldur getur lækkað öryggis- og endurskoðunarhættu ef það er framkvæmt kerfisbundið.

Útgáfu- og rekstrarferli: án hreinnar Pipeline verður Refactoring dýrt

Margir Delphi-arfurverkefni þjást síður af kóðanum en af ferlinum: Builds eru mismunandi milli vinnustöðva, útgáfur eru handvirkar og villur er ekki hægt að rekja skýrt til baka. Þess vegna ætti Refactoring einnig að styrkja afhendingarferlið.

Endurframleiðanleiki builda og stillingastjórnun

Frá sjónarhóli stjórnsýslu og úttektar er mikilvægt að útgáfa sé endurframleiðanleg: sömu uppsprettur, sömu Compiler-/Library-útgáfur, sömu háðir. Til þess þarf skýrt aðskildar stillingar fyrir þróun, prófanir og framleiðslu (t.d. gagnagrunnsenda, Logging-Level, Feature-Flags).

Skráning, eftirlit og þjónustuhæfni

„Eitthvað gerðist“ dugar ekki í rekstri. Refactoring er gott tækifæri til að innleiða samræmt logging: uppbyggðar loggfærslur, ótvíræðir villukóðar, samhengi (notandi, leigjandi, pöntun, viðmót) og skýr aðgreining á milli tæknilegra villa og faglegra staðfestinga.

Fyrir 24/7-nálæga ferla eru enn fremur gagnlegar:

• Health Checks (t.d. gagnagrunnstenging, biðröðarteppa, minniálag),
• Viðvörun eftir alvarleika,
• Runbooks fyrir endurræsingu og algengar truflanir.

Hagnýt Refactoring-áætlun í 6 skrefum

Til að Refactoring týnist ekki í daglegu starfi er gagnlegt að hafa skýra áætlun sem samrýmist útgáfuhringjum. Ein sönnuð aðferð:

1. Búa til áhættu- og breytingakort (módúl, viðmót, gögn, rekstur).
2. Setja upp öryggisnet: staðall fyrir logging, fyrstu Regression- og Golden-Master-prófanir fyrir gagnrýna flæði.
3. Draga upp arkitektúr aðskilnismörk: þjónustulag og innkapslun gagnaaðgangs sem „nýja venjan“ fyrir breytingar.
4. Endurbyggja helstu bilunarpunkta: þau módule sem oftast eru breytt og valda bilunum (nota villutölfræði og breytingarsögu).
5. Sameina gagnaaðgang: FireDAC/Transaktionen/Timeouts samræma, mæla frammistöðu, athuga Deadlocks.
6. Opna nútímavæðingarleiðir: viðmót (REST), pallarmál (Unicode/64‑bitar), stigvaxandi UI-nútímavæðing þar sem það er skynsamlegt.

Kjarninn er röðin: fyrst gagnsæi og varnir, síðan uppbyggingarbreytingar og loks stærri endurgerðir. Þannig helst lausnin afhendingarhæf og stöðug í rekstri.

Hvenær Refactoring dugar ekki: merki um umfangmeiri nútímavæðingu

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

• Tæknileg blindgöt: gagnagrunnadriflar sem ekki eru lengur studdir, íhlutir sem ekki er hægt að laga með patchi, harðar 32‑bita háðir.
• Arkitektúr passar ekki lengur: t.d. þarf forritið að vera rekið sem þjónustulandslag en allt er UI-miðað.
• Skalanleiki og tiltækni: kröfur um margleigusni, háa tiltækni eða fjaraðgang má aðeins uppfylla með kerfislegum breytingum.
• Öryggiskröfur: auðkenning/SSO, endurskoðun, dulkóðun er ekki hægt að bæta við án umfangsmikilla umbóta.

Jafnvel þá er Refactoring oft skynsamlegur þáttur: Það skapar skipulag sem gerir kleift að aðskilja einstaka hluta frekar en að skipta út öllu kerfinu í einu.

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

Að refactora Legacy-kóða í Delphi er fyrst og fremst spurning um forgangsröðun, áhættustjórnun og tengsl við rekstur. Ef þið byrjið með áreiðanlegt stöðumat, tryggið helstu vandamálasvæði, samræmið aðgang að gögnum og skil milli arkitektúrlaga og beinið prófunum og logging sérstaklega að gagnrýnum leiðum, breytist „hreinsun“ í stjórnanlegt nútímavæðingarverkefni. Niðurstaðan er ekki aðeins læsilegri kóði, heldur kerfi sem er áreiðanlegra í rekstri, öruggara í breytingum og einfaldara í samþættingu.

Ef þið viljið kerfisbundið styrkja eða nútímavæða ykkar Delphi-núverandi lausn, ræðum við gjarnan upphafsstöðu, áhættu og raunhæfan Refactoring-stíg:

Í faglega umhverfinu gegna einnig Delphi Nútímavæðing og Delphi Refactoring mikilvægu hlutverki, þegar samþættingar, gagnaflæði og áframhaldandi þróun þurfa að spila vel saman.

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