Miks koodinavigatsioon ei tööta, kui teil on rohkem kui üks programmeerimiskeel?

Koodi navigeerimine toimib hästi, kui arendaja püsib ühe keele piires ühes koodibaasis. Vajuta F12, hüppa definitsiooni juurde. Paremklõpsa meetodil, leia kõik viited. Need interaktsioonid tunduvad kohesed, sest IDE-l on koodist täielik ja sidus mudel: see teab iga sümbolit, iga tüüpi, iga impordiahelat. Hetkel, kui see piir laieneb ja hõlmab teist keelt, see mudel puruneb. IDE tunneb küll oma keelt, aga mitte teist keelt. Arendaja näeb kutset, järgneb sellele oma praeguse faili servani ja põrkab siis vastu seina: kutsutav funktsioon asub teises keeles, võib-olla teises repositooriumis, mida reguleerivad erinevad konventsioonid, millest tööriist aru ei saa. Sellest hetkest alates muutub navigeerimine käsitsi teostatavaks. Arendaja vahetab tööriistu, otsib teksti järgi ja loodab, et tulemus on see, mida ta otsis.

Tõeliselt polüglottsetes keskkondades töötavate meeskondade jaoks pole see juhuslik ebamugavus. See on iga olulise ülesande vaiketingimus. Ettevõtte süsteemid hõlmavad rutiinselt COBOLi ja Java, JCLi ja SQLi, Pythoni ja C++ või mis tahes arvu kombinatsioone, mis peegeldavad aastakümneid kestnud tehnoloogilisi otsuseid üksteise peal. Iga keelepiir selles pinus on koht, kus automaatne navigeerimine peatub ja algab käsitsi rekonstrueerimine. Hõõrdumine süveneb iga arendaja, iga ülesande ja iga meeskonna vahel, kuni kulud muutuvad struktuurseks: aeglasem sisseelamine, riskantsemad muudatused, pikemad intsidentide uurimised ja kasvav sõltuvus vähestest inimestest, kellel on peas keeleteadmised. Nagu COBOLi staatilise analüüsi lahenduste kontekstis uuritud , ei ole keelepiiride ülene arutlemine lihtsalt tööriistade probleem. See on suurte ja heterogeensete süsteemide ohutu käitamise põhimõtteline takistus.

Selle probleemi lahendamise esimene samm on mõista, miks see juhtub ja kui palju see praktikas maksab. See artikkel jälgib probleemi tehnilistest juurtest kuni operatiivsete tagajärgedeni, uurib, miks tavaliselt kasutatavad tööriistad keelepiiride ületamisel ebaõnnestuvad, ja selgitab, mida tõeline keelteülene navigeerimine ettevõtte tasandil toimimiseks nõuab.

Mida koodinavigatsioon tegelikult toimimiseks vajab

Koodi navigeerimine ei ole otsinguoperatsioon. See on lahendusoperatsioon. Kui arendaja küsib: „Kus see funktsioon on defineeritud?“, siis IDE ei otsi failidest sobivat teksti. See lahendab identifikaatori koodibaasi struktureeritud mudeli abil: see on iga ulatusse kuuluva klassi, meetodi, muutuja ja tüübi parsitud esitus koos nendevaheliste seostega. See mudel luuakse indekseerimise ajal, seda hoitakse pidevalt failide muutudes ja sellele esitatakse päring koheselt, kui navigeerimistoiming käivitatakse. Mudeli täpsus ja täielikkus määravad iga arendaja poolt saadud navigeerimistulemuse täpsuse ja täielikkuse.

See otsingu ja lahenduse eristamine on oluline, kuna see määratleb keelteülese navigeerimise nõuded. Tekstiotsing saab otsida mis tahes failidest olenemata keelest, kuna see ei loe koodi koodina. Navigeerimisvahend ei saa keelepiiride üleselt toimida, kui see pole loonud mudelit, mis hõlmab mõlemat keelt, mitte lihtsalt ühe keele mudelit, mis suudab leida stringe ka teise keele failidest. Sellise ühtse mudeli loomine on tehniliselt keerukas viisil, mida ühekeelne navigeerimine ei ole, ja raskusaste suureneb koos kaasatud erinevate keelte arvuga. Nagu andmete ja juhtimisvoogude analüüsi üksikasjalikus uuringus uuriti , nõuab kood, mis toimib õigesti eri täitmisradadel, kogu tee struktuurilist mõistmist, mitte ainult segmente, mis kuuluvad ükskõik millise tööriista ulatusse.

Kolm spetsiifilist võimekust, mida koodi navigeerimine vajab ja mis kõik keelepiiridel erineval moel ebaõnnestuvad, on sümbolite eraldusvõime, väljakutsegraafikute konstrueerimine ja sõltuvuste jälgimine. Enne kui kaalume, kuidas need praktikas koos toimivad, väärib igaüks neist eraldi uurimist.

Sümboli eraldusvõime ja miks see keelepiiridel katkeb

Sümboli lahendamine on lähtekoodi identifikaatori ja selle definitsiooni vahelise vastendamise protsess. Ühe keele keskkonnas on see protsess hästi mõistetav: kompilaator või interpreter juba teostab seda ja IDE-d kopeerivad selle lahendamise loogika, kasutades samu grammatika- ja tüübisüsteemi reegleid. Lahendus on täpne, kuna reeglid on ühe keele piires üheselt mõistetavad.

Keelepiiril nõuab lahendamine sillamudelit, mis suudab esitada mõlema keele sümboleid ühtses struktuuris ja jälgida seost keele A identifikaatorist vastava definitsioonini keeles B. Sellist silda standardsetes IDE-des ega keeleserverites ei eksisteeri, kuna keeleserveri protokoll loodi eeldusel, et iga keeleserver haldab ühte keelt. Kui Java meetod kutsub COBOL-programmi läbi määratletud liidese, saab Java keeleserver meetodi kutsest aru, kuid ei suuda COBOL-i sihtmärki lahendada. Arendaja näeb kutset, teab, et see kuhugi viib, ja ei saa seda jälgida ilma tööriistast täielikult lahkumata.

Vaatleme tüüpilist näidet. Java teenus kutsub COBOL-programmi nimepidi esile vahevara kihi kaudu:

Java

// Java service calling a COBOL program via a legacy middleware adapter
LegacyAdapter.invoke("CUSTINQ", customerRequest);

Java IDE lahendab LegacyAdapter.invoke ilma raskusteta. See teab meetodi signatuuri ja saab navigeerida selle implementatsioonini. Aga "CUSTINQ" on Java tasemel stringiliteraal. IDE-l puudub COBOL-programminimede kontseptsioon ega arusaam sellest, et CUSTINQ viitab konkreetsele kompileeritud programmiüksusele, millel on oma andmemääratlused ja lõigustruktuur. Navigeerimine peatub stringil. Arendaja peab käsitsi leidma COBOL-i lähtekoodi, avama selle teises redaktoris ja hakkama lugema ilma igasuguse struktuurilise kontekstita selle kohta, kuidas programm on seotud kutsuva Java-koodiga.

Kutsegraafi konstrueerimine heterogeensetes koodibaasides

Kõnegraaf on andmestruktuur, mis esindab, millised funktsioonid kutsuvad välja milliseid teisi funktsioone kogu koodibaasis. IDE-d kasutavad kõnegraafe selliste funktsioonide rakendamiseks nagu „leida kõik kutsujad” ja „kõnehierarhia”, mis näitavad arendajale iga teed, mis viib antud funktsioonini, ja iga funktsiooni, mida antud funktsioon kutsub esile. Ühekeelses keskkonnas on kõnegraafiku koostamine koodibaasi indekseerimise loomulik kõrvalsaadus.

Mitmekeelses keskkonnas peab kõnegraaf olema täielik, et see ületaks keelepiire. Kõnegraaf, mis lõpeb igas punktis, kus teostus ületab teise keele, ei ole süsteemi kõnegraaf; see on osagraafide kogum, üks iga keele kohta, millel on iga keelepiiri juures lahtiühendatud servad. Arendaja jaoks, kes jälgib teostusrada läbi süsteemi, mis segab keeli, tähendab see, et jälgimine lõpeb iga kord, kui tee ületab keelepiiri, mis nõuab käsitsi jätkamist järgmises keeles.

Probleem on terav suurarvutikeskkondades, kus üks äritehing võib hõlmata JCL-i, kes korraldab täitmisjärjestust, COBOL-programme, mis täidavad põhilist äriloogikat, ning SQL-päringuid, mis loevad ja kirjutavad andmeid. Nagu JCL-i ja COBOL-i vastavuse analüüsis üksikasjalikult kirjeldatud , on need kolm kihti sügavalt seotud: JCL määratleb, mis ja millises järjekorras töötab, COBOL määratleb, mida programmid teevad, ja SQL määratleb, millistele andmetele nad juurde pääsevad. Kutsegraaf, mis hõlmab ainult COBOLi, ainult JCL-i või ainult SQL-i, kirjeldab süsteemi fragmenti, mitte süsteemi ennast. Millegi olulise jälgimiseks on vaja, et kõik kolm kihti oleksid ühendatud ühte mudelisse.

Sõltuvuste jälgimine, kui keeled jagavad andmeid

Mitmekeelse süsteemi komponentide vahelised sõltuvused vahendatakse sageli jagatud andmete kaudu: andmebaasi tabel, mille COBOL kirjutab ja Java loeb, fail, mille pakktöötlus loob ja API tarbib, või sõnumijärjekord, mille Pythoni tootja kirjutab ja Go tarbija loeb. Need andmevahendatud sõltuvused on reaalsed ja olulised. Tabeli skeemi, failivormingu või sõnumistruktuuri muutmine mõjutab nii tootjat kui ka tarbijat, kuid need ei kajastu ühegi keele sõltuvusmudelis.

Sõltuvuste jälgimine mitmekeelses keskkonnas nõuab seega mitte ainult koodidevaheliste kõnede, vaid ka andmete ja koodide vaheliste seoste mõistmist: millised programmid loevad või kirjutavad konkreetset tabeli veergu, millised teenused sõltuvad konkreetsest failivormingust, milliseid tarbijaid sõnumiskeemi muudatus mõjutab. Selline jälgimine jääb täielikult välja standardse IDE navigeerimise ulatusest ja nõuab tööriista, mis modelleerib kogu süsteemi, sealhulgas andmekihti, selle asemel, et käsitleda iga keele koodi eraldi.

Spetsiifilised viisid, kuidas navigeerimine tavalistes mitmekeelsetes pinudes ebaõnnestub

Koodi navigeerimise tõrked eri keeltes ei ole abstraktsed. Need ilmnevad konkreetsetes ja etteaimatavates olukordades, mis ettevõtte arenduskeskkondades rutiinselt tekivad. Nende konkreetne uurimine teeb selgeks, miks üldised otsingutööriistad ei saa asendada tõelist keelteülest navigeerimist.

COBOL ja Java: kõige levinumad ettevõtte piirid

COBOL-i ja Java vaheline keelepiir on suurtes ettevõtetes, eriti finantsteenuste, kindlustuse ja valitsuse valdkonnas, kõige levinum keelepiir. Aastakümneid kestnud investeeringud COBOL-i eksisteerivad koos Java moderniseerimispüüdlustega hübriidarhitektuuris, kus COBOL tegeleb partiitöötlusega ning Java tehingute töötlemise ja API-dega. Need kaks keelt suhtlevad määratletud liideste kaudu: CICS-tehingud, sõnumijärjekorrad, jagatud andmebaasid ja failipõhised edastused.

Selle piiri ületamine praktikas paljastab probleemi sügavuse. Java arendaja, kes uurib ootamatut käitumist tehingus, peab järgima teostusrada COBOL-i paketiprogrammi, mis töötles alusandmeid. Java IDE näitab, kus liidest kutsutakse. See ei saa näidata, mida COBOL-programm sisendiga teeb, milliseid andmeid see loeb, milliseid arvutusi see teeb või mida see tagasi kirjutab. Arendaja vajab jätkamiseks COBOL-i oskusteavet ja COBOL-i tööriistu, millest kumbki ei pruugi Java-orienteeritud meeskonnas kergesti kättesaadav olla. Tulemuseks on kas aeglane käsitsi uurimine või eskaleerimine kellelegi, kellel on vajalikud teadmised, mis mõlemad kujutavad endast navigeerimisvigu, mis maksavad aega ja pikendavad intsidendi kestust.

COBOL-i poolel tekib samaväärne tõrge siis, kui COBOL-i arendaja peab aru saama, millised Java-teenused tarbivad COBOL-i programmi loodud andmeid. Standardsetel COBOL-i tööriistadel puudub Java-koodi mudel. Arendaja näeb COBOL-i programmi väljundit, sealhulgas andmebaasi kirjutamist või faili uuendamist, kuid ei saa seda väljundit edasi jälgida, et tuvastada, millised Java-teenused seda loevad. Igasugune väljundvormingu muutmine nõuab käsitsi koordineerimist Java-meeskondadega, kuna puudub tööriist, mis suudaks tarbijaid automaatselt loetleda. COBOL-i moderniseerimine sõltub kriitiliselt just selle lünga lahendamisest: kuni kogu sõltuvusahel on mõlemas keeles nähtav, pole ohutu moderniseerimine võimalik.

JCL ja COBOL: nähtavuseta orkestreerimine

JCL on suurarvutite partiitöötluse orkestreerimiskiht. See kontrollib, millised programmid, millises järjekorras, milliste parameetritega ning milliste failide ja andmekogumite suhtes töötavad. JCL-i ja selle poolt käivitatavate COBOL-programmide vaheline seos on põhimõtteline struktuuriline sõltuvus: JCL-i muutmisel muutub ka COBOL-programmide käitumine. COBOL-programmi eeldatava sisendvormingu muutmisel võivad samuti vaja minna muuta seda toitvaid JCL-andmekogumeid.

Standardsed COBOLi analüüsitööriistad ei parsi JCL-i. Standardsed JCL-i analüüsitööriistad ei parsi COBOLi. Seos JCL-i etapi vahel, mis käivitab PGM=CUSTINQ ja COBOL-programm nimega CUSTINQ eksisteerib töötavas süsteemis, aga mitte ühegi üksiku tööriista mudelis. Arendaja, kes kasutab kumbagi tööriista eraldi, ei näe tervikpilti. Nad teavad nimepidi, mida JCL-samm kutsub esile, aga mitte seda, mida programm teeb. Või nad teavad, mida COBOL-programm teeb, aga mitte seda, kuidas seda kutsutakse, milliste parameetritega või millises töövoo järjestuses.

See lünk tekitab tootmissüsteemidele spetsiifilisi riske. Arendaja, kes muudab COBOL-programmi töömälu definitsioone, võib tahtmatult muuta seda, kuidas programm käsitleb konkreetsest JCL-etapist edastatud andmeid, ilma et ükski tööriist hoiataks, et muudatus mõjutab JCL-i määratletud täitmiskonteksti. Arendaja, kes ümber korraldab JCL-protseduuri, võib muuta programmide käivitamise järjestust, ilma et ükski tööriist näitaks, millised COBOL-programmid korrektseks toimimiseks sellest järjestusest sõltuvad. Nagu JCL-i staatilise analüüsi lahenduste uurimisel üksikasjalikult kirjeldatud , nõuab programmidevaheliste sõltuvuste ja andmestike kasutamise nähtavus JCL-keskkondades spetsiaalset analüüsi, mida standardsed tööriistad lihtsalt ei paku.

Nii näeb sama sõltuvus välja iga keele vaatenurgast standardsete tööriistadega võrreldes ühtse mudeliga:

Mida arendaja näeb	Ainult JCL-vaade	Ainult COBOL-vaade	Ühtne keelteülene vaade
Programmi käivitamine	PGM=CUSTINQ (ainult nimi)	Pole näha	CUSTINQ-i kutsuvad välja 3 JCL-protseduuri, millel on kindlad PARM-väärtused
Sisendandmestikud	DD nimed loetletud	Pole näha	Loeb CUSTFILE'i (määratletud CUSTMAST.JCL 2. etapis)
Väljundandmestikud	DD nimed loetletud	Pole näha	Kirjutab CUSTRPT-i (tarbib RPTPRT-töö)
Äriloogika	Pole näha	MENETLUSTE JAOTIS nähtav	Täielik voog JCL-i käivitamisest läbi COBOL-loogika väljundini
Muutuste mõju	Tundmatu	Tundmatu	4 JCL protseduuri, 2 COBOL-programmi, 1 andmebaasi tabel

Kaasaegsed keelepaketid: Python, Go ja C# teenustes

Hajussüsteemides, mis on ehitatud tänapäevastest keeltest, on navigeerimisprobleem teistsugune. COBOL-Java keelelünga asemel on väljakutseks teenuste piir koos polüglottide pinuga. Pythoni andmetöötlusteenus toidab Go API-t, mis omakorda toidab C# esiotsa. Iga teenus on ehitatud oma tööriistade, IDE konfiguratsiooni ja sõltuvusmudeliga. Teenustevahelised ühendused eksisteerivad API kihil, kuid standardsetel navigeerimistööriistadel puudub teenustevaheliste API suhete mudel.

Arendaja, kes muudab Pythoni teenuses vastuse struktuuri, peab teadma, millistest väljadest Go API sõltub ja milliseid välju C# esiots lõpuks kuvab. Ilma keelte- ja teenusteülese navigeerimiseta peavad nad iga allavoolu teenuse koodi käsitsi kontrollima, otsima viiteid asjakohastele väljanimedele ja lootma, et nimetamiskonventsioonid on piisavalt järjepidevad, et otsing oleks usaldusväärne. Nagu Go staatilise analüüsi tööriistade kontekstis arutleti , on isegi ühe Go teenuse piires kutsehierarhiate mõistmine ja moodulite vaheliste sõltuvuste jälgimine mitte triviaalne probleem. Selle probleemi laiendamine samaaegselt üle teenuste ja keelte piiride on suurusjärgu võrra keerulisem.

Sama muster kehtib ka C# süsteemide kohta , mis kutsuvad välja Javas kirjutatud jagatud teenuseid, või Pythoni torujuhtmete kohta , mis kirjutavad .NET-rakenduste poolt kasutatavatesse andmebaasidesse. Igal juhul pakuvad iga keele standardsed tööriistad täpset navigeerimist selles keeles ega anna midagi kasulikku piiril, kus teostus ületab teise keele või teenuse.

SQL ja rakenduskood: nähtamatu andmekiht

SQL on olemas peaaegu igas ettevõtte süsteemis, kuid ometi on see keelteülese navigeerimise kõige järjepidevamalt tähelepanuta jäetud komponent. Rakenduskood kirjutab SQL-päringuid, mis viitavad tabelinimedele, veerunimedele, liitumistingimustele ja salvestatud protseduuridele. Andmebaasi skeem määratleb need tabelid ja veerud. Rakenduskoodi ja andmebaasi skeemi vaheline seos on sõltuvus, mille skeemi muutmise korral katkemine põhjustab käitusaja tõrkeid. Kuid standardsed IDE-d käsitlevad SQL-stringe stringidena, mitte navigeeritava struktuuriga koodina.

Arendaja, kes muudab skeemis veeru nime, peab leidma kõik viited sellele veerule igas rakenduses, igas keeles ja igas päringus. Veeru nime tekstiotsing on ebausaldusväärne: lühikesed veerunimed põrkuvad muutujate nimede, logiteadete ja kommentaaridega. Sümboliteadlik otsing nõuab tööriista, mis modelleerib nii SQL-skeemi kui ka sellele viitavat rakenduse koodi ning mõistab, et "customer_id" Java päringustringis on viide andmebaasi veerule customer_idja suudab loetleda kõik sellised viited eri keeltes. Ilma selle mudelita on skeemimuudatused käsitsi tehtavad ja statistiliselt mittetäielikud.

Miks IDE laiendused ja keeleserverid seda lahendada ei suuda

IDE laiendused ja keeleserverid on loodud pakkuma keelespetsiifilist intelligentsust. Need parsivad koodi vastavalt kindlale grammatikale, loovad keelespetsiifilise sümboliindeksi ja esitavad päringuid keeleserveri protokolli kaudu, mis määratleb standardliidese keelefunktsioonidele, sealhulgas definitsioonile minekule, viidete leidmisele ja kursoriga dokumenteerimisele. Protokoll on transpordikihis keelest sõltumatu, kuid sisult keelespetsiifiline: iga keeleserver annab tulemusi ainult oma keele jaoks.

Kahe keeleserveri ühendamine sama IDE piires ei lahenda keeltevahelist navigeerimist. Igal serveril on oma indeks. Kui arendaja taotleb sümboli kohta „leida kõik viited”, läheb päring praeguse faili keele keeleserverile. See server tagastab viited, millest ta teab ja mis piirduvad indekseeritud failidega. See server ei esita päringut teisele keeleserverile ja isegi kui teeks seda, poleks ühist sümbolimudelit, mille kaudu keeltevahelisi seoseid väljendada.

See on LSP arhitektuuri struktuuriline piirang, mitte konfiguratsiooniprobleem. Sellest saab osaliselt mööda hiilida spetsiifilistel ja kitsastel juhtudel, näiteks keeleserveri puhul, mis parsib ka Pythoni f-stringides olevat SQL-i, kuid seda ei saa üldistada suvalistele keeltevahelistele sõltuvustele ilma täpselt sellist ühtset mitmekeelset mudelit ehitamata, mis ulatub kaugemale sellest, mida ükski keeleserver pakkuma on loodud. Staatilise analüüsi ees seisvad väljakutsed metaprogrammeerimisel ühe keele piires illustreerivad probleemi sügavust: kui dünaamiliselt genereeritud koodi üle arutlemine ühes keeles nõuab spetsiaalseid tehnikaid, siis mitme keele, millel on erinevad grammatikad ja käitusaja mudelid, puhul nõuab arutlemine täiesti erinevat arhitektuurilist lähenemist.

Milliseid keeleservereid hästi pakutakse (ja kus nad peatuvad)

Keeleserverid paistavad silma ülesannetega, milleks nad on loodud: reaalajas diagnostika, intelligentne tekstide täiendamine, ühe keele sümbolite lahendamine ja redaktorisisene refaktoreerimine piiratud ulatuses. Need võimalused on väärtuslikud ja neid ei tohiks alahinnata. Probleem ei ole selles, et keeleserverid on ebapiisavad tööriistad; asi on selles, et need on ühe keele tööriistad, mida rakendatakse mitme keele probleemide lahendamiseks, ja see mittevastavus põhjustab ennustatavaid ja kulukaid tõrkeid just nendes punktides, kus täpsus on kõige olulisem.

Allolev tabel seob konkreetsed navigeerimisülesanded keeleserverite pakutavate funktsioonidega ja lünkade algusega:

Navigeerimisülesanne	LSP ühe keele piires	LSP üle keelepiiri
Mine definitsiooni juurde	Täpne, kohene	Ebaõnnestub: peatub kõnekohas
Leia kõik viited	Täitke indekseeritud failides	Mittetäielik: puuduvad viited teistes keeltes
Kõnede hierarhia	Täpne ühekeelsete helistajate puhul	Kärbitud: piirikõnede tegijad puuduvad
Nimeta sümbol ümber	Turvaline ühes keeles	Ohtlik: ümbernimetused ei vasta keeleülestele kasutusviisidele
Mõju analüüs	Praegusele keelele rakendatud	Pime teiste keelte tarbijate suhtes

Grep ja tekstiotsing: miks need ei ole vastuvõetav asendaja

Kui keeleserverid piiripealselt üles ütlevad, haaravad arendajad tekstiotsingu järele. grep, IDE-taseme otsing ja platvormiotsing (nt GitHub Code Search) leiavad kõik failidest stringe keelt arvestamata. Neil puudub "sümboli" või "viite" mõiste, ainult stringi esinemised. Lühidalt öeldes tähendab see tohutuid tulemuste komplekte, mis vajavad käsitsi filtreerimist. Identifikaatorite puhul, mis eksisteerivad mitmes keeles ja millel on erinev tähendus, ühendavad tulemused erinevad koodielemendid, millel on juhtumisi sama nimi.

Mürast ohtlikum on puudulikkus. Tekstiotsing ei leia viiteid kohtades, kus nimetamiskonventsioonid erinevad keelte lõikes, kus identifikaator luuakse dünaamiliselt, kus seost vahendab konfiguratsioon või nimeregister või kus seost väljendatakse andmete, mitte otsese koodiviite kaudu. Need lüngad ei ole otsingutulemustes nähtavad: arendaja näeb, mida otsing leidis, kuid tal pole mingit võimalust teada, mis vahele jäi, ja ta teeb otsuseid mittetäieliku pildi põhjal, mis näib olevat täielik. Staatilise koodianalüüsi laiemas kontekstis hooldatavuse seisukohast uurituna ei ole suutmatus täpselt arutleda selle üle, mida kood teeb ja millega see ühendub, väike ebamugavus, mis on tehnilise võla kuhjumise, hoolduse käigus tekkivate defektide ja muudatuste ohutu tegemise kasvavate kulude algpõhjus.

Keelepiiridel akumuleeruvad tegevuskulud

Ülalkirjeldatud navigatsioonivead ei avaldu ühekordsete probleemidena. Need kuhjuvad iga ülesande, iga arendaja ja iga mitmekeelses keskkonnas tegutseva meeskonna lõikes. Kulude mõistmiseks on vaja uurida korduvaid olukordi, kus navigatsioon ebaõnnestub, ja arvutada kogumõju.

Polüglottide meeskondadesse sisseelamine võtab oluliselt kauem aega

Arendaja, kes liitub meeskonnaga, mis töötab ühes keeles ja ühtse koodibaasiga, võib suhteliselt kiiresti produktiivseks saada. IDE tegeleb navigeerimisega, kood on oma struktuuri kaudu ise dokumenteeriv ja arendaja loodud mentaalne mudel peegeldab tegelikku süsteemi. Arendaja, kes liitub meeskonnaga, mis töötab mitmes keeles, seisab silmitsi põhimõtteliselt teistsuguse olukorraga. Tööriistad ei navigeeri piirides, seega tuleb mentaalne mudel luua käsitsi dokumenteerimise, paarisprogrammeerimise ja katse-eksituse meetodil.

See käsitsi mudeli loomine võtab nädalaid, mitte päevi. Arendaja peab õppima selgeks mitte ainult oma põhikeele koodi, vaid ka piisavalt naaberkeelte kohta, et mõista, mida need nimetavad, mis neid nimetab ja millised andmed piiride vahel liiguvad. Suurtes organisatsioonides, kus on suur töötajate voolavus või sagedased meeskonnavahetused, on see pikk sisseelamisaeg pigem korduv kulu kui ühekordne investeering. Iga inimene, kes liitub polüglottide meeskonnaga, maksab keeltevahelise mentaalse mudeli nullist rekonstrueerimise täiskulud, sest tööriistad ei paku midagi, mis seda edasi viiks.

Tootmisintsidendid kestavad kauem, kui jäljed ületavad keelepiire

Kui tootmisintsident nõuab keelepiire ületava teostustee jälgimist, on iga piiriületus käsitsi tehtav samm. Valvekorras arendaja, kes töötab niigi ajalise surve all, peab vahetama tööriistu, otsima teksti järgi teise keele koodibaasis ja ühendama tulemused käsitsi loodava jäljega. Kolme või nelja keelekihiga süsteemis võib täielik algpõhjuse uurimine nõuda nelja või viit sellist piiriületust, millest igaüks lisab uurimisele minuteid, mida mõõdetakse aja järgi, mil see mõjutab kasutajaid.

Mitmekeelse teenuse pakkuja organisatsiooni kumulatiivne mõju on süstemaatiliselt pikenenud keskmine lahendusaeg iga keelepiiri ületava intsidendi puhul. See ei ole üksikute arendajate ebaõnnestumine; see on struktuuriline tagajärg tööriistadele, mis ei modelleeri süsteemi tegelikke seoseid. Organisatsioonid, mis on investeerinud keelteülesesse nähtavusse, teatavad järjepidevalt kiiremast intsidentide lahendamisest kui ühest otsesemast ja mõõdetavamast eelisest just seetõttu, et see investeering kõrvaldab käsitsi piiride ületamise etapid, mis pikendavad uurimisaega.

Riskantsed muudatused muutuvad veelgi riskantsemaks ilma keeleülese mõju nähtavuseta

Iga mitmekeelse süsteemi jagatud koodi muudatus kannab endas määratlemata riski, kuni on teada kõik tarbijad kõigis keeltes. Ilma keelteülese navigeerimiseta ei ole see risk enne muudatuse tegemist kindlaks määratud. See avastatakse hiljem, kui testimisel või, mis veelgi hullem, tootmises ilmnevad vigased tarbijad. See pole haruldane rikkerežiim. See on standardne tulemus jagatud andmestruktuuride, liideste või utiliitide haldamisel süsteemis, kus järgnevad tarbijad räägivad erinevaid keeli.

Konservatiivne vastus sellele ebakindlusele on liigne ettevaatlikkus: suuremad testimistööd, pikemad ülevaatustsüklid, rohkem koordineerimiskoosolekuid ja sagedasemad muudatuste külmutamised kriitiliste perioodide ajal. Kõik need on reaalsed kulud, mis kuhjuvad mitmekeelses süsteemis igas muudatuste tsüklis. Need esindavad aega ja vaeva, mis kulub keeltevahelise navigatsiooni puudumise kompenseerimisele, mitte väärtuse loomisele. Vananenud moderniseerimise maastikku kujundavad olulisel määral need akumuleerunud kulud: organisatsioonid haaravad moderniseerimisest, kuna olemasolevate süsteemide hooldamine on muutunud ülemäära kalliks ja keeltevahelise navigatsiooni tõrked on nende hoolduskulude peamine põhjus.

Mida keelteülene navigeerimine tegelikult nõuab

Koodi navigeerimise lahendamine mitmes keeles nõuab ühtse mudeli loomist, mida keeleserverid eraldi pakkuda ei suuda. See mudel peab vastama mitmele nõudele, mis on kasuliku keeltevahelise navigeerimise vajalikud tingimused, mitte valikulised täiustused.

Üks jagatud sümbolindeks, mis hõlmab kõiki keeli. Iga nimetatud element igas keeles, sealhulgas funktsioonid, klassid, väljad, protseduurid, tabelid ja andmemääratlused, peab olema esitatud ühes indeksis, millel on ühine identiteedimudeli. Sümboli identiteet ei saa olla keelepõhine, kui selle suhtes tuleb lahendada keeltevahelisi viiteid.

Keeleteadlikud parsijad iga süsteemi keele jaoks. Iga keelt tuleb parsida selle enda grammatika abil, mitte üldise parseri või mustrite sobitamise abil. Iga parseri struktuuriline väljund peab vastama jagatud identiteedimudelile, et keeltevahelisi seoseid saaks väljendada õigesti tuvastatud sümbolite vaheliste seostena.

Keeltevaheliste liideste selgesõnaline modelleerimine. Mehhanismid, mille kaudu erinevad keeled omavahel suhtlevad, sealhulgas programmi kutsumine nime järgi, andmebaasi tabelid, failivormingud, sõnumiskeemid ja API-lepingud, tuleb mudelis esitada esimese klassi ühenduste tüüpidena, mitte käsitleda läbipaistmatute stringidena või jätta mudelist täielikult välja.

Sõltuvuste jälgimine, mis hõlmab andmekihi seoseid. Mudel peab esindama mitte ainult koodidevahelisi kõnesid, vaid ka andmete vahendatud sõltuvusi, sest mitmekeelsetes süsteemides on andmed sageli peamine meedium, mille kaudu ühe keele väljund saab teise keele sisendiks.

Päringu jõudlus, mis toetab interaktiivset navigeerimist. Indeks peab toetama tavaliste navigeerimistoimingute puhul sekundist lühemat päringule vastamist. Mudel, mis nõuab interaktiivsete päringute asemel partiianalüüsi käivitamist, on kasulik võrguühenduseta mõjuanalüüsi jaoks, kuid ei saa aktiivse arenduse ajal reaalajas navigeerimist asendada.

Need nõuded kirjeldavad ettevõtte koodi luureplatvormi, mitte IDE laiendust ega keeleserverit. Sellise platvormi loomine ja hooldamine on tehniline alus mitmekeelse koodi navigeerimise praktikas toimimiseks. Alternatiiv, mis seisneb navigeerimise ebaõnnestumiste aktsepteerimises ja nende kulude lõputus maksmises, muutub vähem teostatavaks, mida suuremaks ja keerukamaks mitmekeelne süsteem kasvab.

Kuidas SMART TS XL Mitmekeelne navigeerimine

SMART TS XL on üles ehitatud eeldusele, et ettevõtte süsteeme ei saa mõista ühegi üksiku keele või üksiku repositooriumi prisma kaudu. Selle tarkvaraluure platvorm võtab vastu lähtekoodi kõigist keskkonna keeltest ja platvormidest, parsib igaüht keelespetsiifilise analüüsi abil ja loob ühtse ristviidete indeksi, mis esindab elementide vahelisi seoseid olenemata sellest, millisesse keelde need kuuluvad. Selle indeksi suhtes tehtud navigeerimispäringud tagastavad tulemusi, mis ületavad keelepiire, kuna indeks modelleerib kogu süsteemi, mitte selle keelespetsiifilist lõiku.

Platvorm modelleerib selgesõnaliselt keeltevahelisi liideseid, mida standardtööriistad ignoreerivad. JCL-samm, mis kutsub nimeliselt välja COBOL-programmi, on ristviidete graafikus esitatud sõltuvusena, mis ühendab JCL-sammu COBOL-programmiüksusega. Andmebaasi tabelisse kirjutav Java-meetod on esitatud andmesõltuvusena, mis ühendab Java-koodi tabeli definitsiooniga ja sealt edasi mis tahes muu keelega, mis loeb sama tabelit. Mitme programmi poolt viidatud COBOL-i käsiraamat on esitatud jagatud definitsioonina, nii et iga muudatus käsiraamatu struktuuris toob kohe esile kõik muudatusest mõjutatud programmid, olenemata keelest. See keeltevaheliste sõltuvuste selgesõnaline modelleerimine eristab tõelist keeltevahelist navigatsiooniplatvormi paralleelselt töötavate keelespetsiifiliste tööriistade kogumist.

SMART TS XLmõjuanalüüsi võimalus näitab selle ühtse mudeli praktilist väärtust. Kui arendaja peab mõistma jagatud komponendi, näiteks COBOL-andmemääratluse, andmebaasiskeemi elemendi, Java-liidese või JCL-protseduuri muutmise tagajärgi, jälgib platvorm selle komponendi sõltuvusgraafikut kõigis keelepiirides ja annab täieliku pildi sellest, mida see mõjutab. Tulemus esitatakse navigeeritava aruandena, mis on korraldatud keele, komponendi ja konkreetse viitekoha järgi, andes arendajatele enne muudatuse tegemist kogu vajaliku teabe, selle asemel, et tagajärgi hiljem avastada. See võimalus tegeleb otseselt eelmises osas kirjeldatud riskide akumuleerumisega, teisendades määramata keelteülese riski kvantifitseeritavaks, loetletavaks mõjuks.

Keelteülene navigeerimine kui kogu süsteemi omadus

Selle artikli keskne mõte on see, et koodi navigeerimine mitmekeelses keskkonnas on kogu süsteemi, mitte ühegi üksiku keeletööriista omadus. IDE, mis navigeerib ideaalselt COBOL-is, ja eraldi IDE, mis navigeerib ideaalselt Java-s, ei loo koos süsteemi, mis navigeerib COBOL-Java piiril. Need loovad kaks sõltumatut navigatsioonisüsteemi, mille vahel on tühimik ja see tühimik on koht, kus süsteemis asuvad kõige olulisemad seosed.

Selle lünga täitmiseks on vaja teistsugust tööriista: sellist, mis modelleerib süsteemi tervikuna, esitab keelepiirideüleseid suhteid esmaklassiliste üksustena ja pakub navigatsiooni, mis järgib neid suhteid kõikjale, kuhu need viivad. Organisatsioonide jaoks, mis haldavad keerukaid ja mitmekeelseid süsteeme ettevõtte tasandil, pole see võimekus luksus. Iga arenduspäev ilma selleta on päev, mil keelteülese navigatsiooni ebaõnnestumiste hind kuhjub: aeglasema kasutuselevõtu, pikemate intsidentide, riskantsemate muudatuste ja asendamatute teadmiste järkjärgulise koondumise näol isikute kätte, kes on käsitsi loonud keelteülesed mõttemudelid, mida tööriistad pakkuda ei suuda.