Miks tekstiotsing ei ole sama mis koodi mõistmine

Arendaja avab esimest korda suure pärandkoodibaasi. Nad peavad mõistma, mis juhtub kliendikirjega pärast konto sulgemist: millised programmid seda uuendavad, millised pakk-tööd seda hiljem loevad, milliseid välju töö käigus muudetakse ja kas mõni allavoolu süsteem sõltub lõplikust olekust. Loomulik esimene samm on otsing. Nad otsivad väljanime, skannivad tulemusi, avavad paar faili ja hakkavad lugema. Tunni aja jooksul on nad leidnud viited kaheteistkümnest programmist, kolmest SQL-skriptist ja JCL-töövoost. Nad on leidnud sama väljanime ka seitsmeteistkümnest kommentaariplokist, neljast logivormingu stringist, kahest testimisseadistusest ja muutujast täiesti mitteseotud alamsüsteemis, millel juhtub olema sama nimi. Nad ei suuda ainuüksi otsingutulemuste põhjal öelda, millised neist on tegelikud andmete lugemised, millised kirjutamised, millised teisendused ja millised juhuslikud nimede kokkupõrked. Nad teavad, mis välja nimi on. Nad ei saa veel aru, mida kood sellega teeb.

See lõhe stringi leidmise ja koodi mõistmise vahel ei ole lõhe, mida parem otsing täidaks. See on lõhe kahe põhimõtteliselt erineva päringutüübi vahel: üks, mis küsib „kus see tekst ilmub?“, ja teine, mis küsib „mida see kood teeb?“. Tekstiotsing on suurepärane vastus esimesele küsimusele. See ei ole üldse vastus teisele küsimusele ja nende kahe segamine on üks järjekindlamaid raisatud pingutuse, vastamata sõltuvuste ja vale mõjuhinnangu allikaid tarkvaraarenduses. See eristamine on olulisem suurtes, heterogeensetes ettevõttesüsteemides kui väikestes tänapäevastes koodibaasides, sest need süsteemid sisaldavad aastakümneid kogunenud struktuuri, keeltevahelisi sõltuvusi ja implitsiitseid seoseid, mis eksisteerivad ainult koodi käitumises, mitte üheski selle lähtekoodifailides esinevas stringis. Nagu uuriti analüüsis koodi kvaliteedi mõõdikud ja nende mõju, mõjutab koodibaasi keerukus oluliselt hooldatavust ja ükski tekstimustritest tuletatud mõõdik ei jäädvusta struktuurilisi seoseid, mis määravad koodi tegeliku käitumise.

Mida tekstiotsing tegelikult teeb

Tekstiotsing on alamsõngede sobitamise toiming, mida rakendatakse toores märgijadadena käsitletud failidele. Päring on string või muster. Tulemuseks on loend asukohtadest, kus see muster esineb. Tööriistal puuduvad teadmised keelest, milles failid on kirjutatud, grammatikast, mis annab tekstile struktuuri, ega mudelist koodielementide vahelistest seostest, mida tekst esindab. Grep, mis hõlmab miljonit COBOL-lähtekoodi rida, töötab sama mudeli järgi kui grep, mis hõlmab miljonit HTML-i rida: failides olevad märgijadad, mis on rühmitatud failitee järgi ja tagastatakse, kui märgijada sobib.

See on äärmiselt kasulik teatud tüüpi ülesannete puhul: teadaoleva stringi asukoha leidmine, konkreetse termini kasutamise või puudumise kinnitamine, nimetamiskonventsioonide kiire kontrollimine, konkreetset veateadet sisaldava faili leidmine. Nende ülesannete jaoks on tekstiotsing õige tööriist, sest need ülesanded on tegelikult stringide leidmiseks. Grepi ja selle ekvivalentide kiirus, kaasaskantavus ja konfiguratsioonivaba olemus on omadused, mis sobivad ideaalselt, kui küsimus on kujul „kas see string on nendes failides olemas ja kui on, siis kus?“.

Probleem ilmneb siis, kui tekstiotsingut kasutatakse küsimuste puhul, mis ei puuduta stringe. „Mis seda funktsiooni kutsub?“ ei ole küsimus selle kohta, kus funktsiooni nimi ilmub. See on küsimus väljakutsegraafi kohta, mis on koodi struktuuriline omadus, mille konstrueerimiseks on vaja parsimist ja semantilist analüüsi. „Kus see väli on kirjutatud?“ ei ole küsimus selle kohta, kus välja nimi ilmub. See on küsimus andmevoo kohta, millele vastamiseks on vaja mõista konkreetse keele omistamise semantikat. „Mis läheb katki, kui ma seda liidest muudan?“ ei ole küsimus selle kohta, kus liidese nimi ilmub. See on küsimus sõltuvussuhete kohta, millele õigeks vastamiseks on vaja lahendada importimine, pärimine ja moodulitevaheline sidestamine.

Kõik need küsimused kasutavad lähtepunktina nime, mistõttu on ahvatlev neid otsinguülesannetena käsitleda. Kuid nimi on ainult sisenemispunkt. Vastus peitub koodi struktuurimudelis, mitte lähtekoodifailide tekstis.

Müraprobleem: liiga palju tulemusi, millel pole mingit tähendust

Koodi mõistmise ülesannete puhul rakendatava tekstiotsingu esimene tõrketüüp on ületootmine: tagastatakse palju rohkem tulemusi kui on asjakohane, ilma mehhanismita, mis tuvastaks struktuurilt olulised ja juhuslikud tulemused.

Lühike identifikaator, näiteks status, id, typevõi date võivad suures koodibaasis esineda tuhandeid kordi. Isegi pikemad identifikaatorid põrkuvad keelte ja nimeruumide vahel: calculate_tax Näiteks funktsiooninimi Pythoni moodulis, COBOL-lõigunimi, andmebaasi salvestatud protseduur, JavaScripti abiprogramm ja logimiskonfiguratsioonis olev string annavad kõik vastavad tekstiotsingu tulemused. Arendaja, kes need tulemused saab, peab need käsitsi filtreerima, rakendades omaenda kooditeadmisi, et teha kindlaks, millised esinemised on asjakohased. See käsitsi filtreerimine on iseenesest koodi mõistmise ülesanne, mis tähendab, et arendaja teeb tööd, mida tööriist peaks tegema, ilma tööriista abita.

Praktikas filtreerivad arendajad intuitsiooni ja kogemuse järgi. Nad mõistavad, et testfaili tulemus ei ole tõenäoliselt tootmisversiooni väljakutse. Nad mõistavad, et kommentaariplokis olev tulemus on dokumentatsioon, mitte väljakutse. Nad jätavad kõrvale tulemused failides, mida nad peavad ebaoluliseks. Kuid need filtrid on ekslikud ja kontrollimatud. Arendaja, kes filtreerib enesekindlalt, võib eksida. Arendaja, kes filtreerib ettevaatlikult, võib kulutada tunde. Ja mõlemal juhul on tulemuseks leidude kogum, mis peegeldab arendaja otsustusvõimet, mitte koodi kontrollitud struktuurianalüüsi.

Vaatleme konkreetset näidet. COBOL-arendaja otsib enne lõigu nime eemaldamist:

kobol

SEARCH-RESULTS FOR "CALC-INTEREST":

1. CALC-INTEREST.PGM        line   5  : IDENTIFICATION DIVISION.
2. CALC-INTEREST.PGM        line  42  : CALC-INTEREST.
3. FINPROCESS.CBL            line 178  : PERFORM CALC-INTEREST
4. RPTMONTH.CBL              line  91  : * Old routine: CALC-INTEREST replaced by CALC-INT-V2
5. CUSTBATCH.CBL             line 234  : PERFORM CALC-INTEREST THRU CALC-INTEREST-EXIT
6. DATADICT.txt              line  12  : CALC-INTEREST - computes monthly interest for savings accts
7. TESTHARNESS.CBL           line  67  : PERFORM CALC-INTEREST
8. ARCHIVEJOB.CBL            line 156  : * PERFORM CALC-INTEREST (disabled 2019-03-14)

Nendest kaheksast tulemusest on täpselt kaks aktiivset kutsujat, mis lõigu eemaldamisel katkeksid: read 3 ja 5. Rida 2 on definitsioon. Read 4 ja 8 on kommentaarid. Rida 6 on andmesõnastiku kirje. Rida 7 on testimisraamistik. Selle kindlaksmääramine, millised kaks neist kaheksast tulemusest esindavad reaalajas kõnesaite, nõuab iga faili kontekstis lugemist, COBOL-süntaksi mõistmist ja hinnangu andmist selle kohta, mida 8. rea kommentaaris olev „keelatud” tegelikult täitmise jaoks tähendab. Tekstiotsing andis toormaterjali. Koodi mõistmine andis vastuse.

Vaikuse probleem: asjakohased tulemused, mida kunagi ei tagastata

Teine rikketüüp on alatootmine: struktuurilt olulised tulemused puuduvad, kuna need ei ole väljendatud kujul, mida tekstiotsing suudab sobitada.

Kaudsed otsingud on kõige levinum puuduvate tulemuste allikas. Kui funktsioon A kutsub funktsiooni B ja funktsioon B kutsub aegunud funktsiooni C, siis tekstiotsing C nime järgi leiab funktsiooni B otsese kutsujana, kuid mitte kaudse kutsujana funktsiooni A. See, kas A on asjakohane tulemus, sõltub otsingu eesmärgist: kui eesmärk on mõista kõike, mis käivitab funktsiooni C, siis on A kriitilise tähtsusega. Kui eesmärk on leida ainult koheseid kutsujaid, siis on A ebaoluline. Tekstiotsing ei saa seda vahet teha, kuna sellel puudub kõnegraafiku mõiste. See tagastab mis tahes sobiva teksti, teadmata, millest sobiv tekst koosneb.

Keeltevahelised viited on süstemaatiliselt puuduv kategooria. Java teenus, mis kutsub COBOL-programmi nimepidi vahetarkvara kihi kaudu, sisaldab COBOL-programmi nime string-literaalina, mida tekstiotsing suudab leida. Kuid sama Java teenus, mis loob programmi nime dünaamiliselt, loeb selle konfiguratsioonifailist või saadab selle abstraktsioonikihi kaudu, ei sisalda nime üldse. Need on kutsujad, keda tekstiotsing ei leia, olenemata sellest, kui põhjalikult seda rakendatakse. Nagu uuriti kontekstis staatiline analüüs hägustatud ja dünaamiliselt genereeritud koodil, kui täitmisteed väljendatakse kaudselt konfiguratsiooni, mallide või käitusaja lähetusmehhanismide kaudu, siis ei ole nende esindatud struktuurilisi seoseid võimalik ainult lähtekoodifailide tekstist taastada.

Väljaaliad ja teisendused loovad veel ühe kategooria vaikseid möödalaskmisi. COBOL-väli nimega WS-ACCT-BAL mis kirjutatakse andmebaasi veergu nimega ACCT_BALANCE, mida Java teenus seejärel loeb kujul accountBalanceja lõpuks serialiseeriti kui account_balance JSON-vastuses tähistab sama andmeelemendi kohta nelja erinevat tekstistringi. Ükskõik millise stringi otsing jätab ülejäänud kolm tähelepanuta. Teadmine, et kõik neli viitavad samale aluseks olevale ärikontseptsioonile, nõuab teisendusahela mõistmist, mitte ühegi nime kõigi esinemiste leidmist.

Mida koodi mõistmine tegelikult nõuab

Koodi mõistmine kui tehniline võimekus on võime vastata koodi kohta käivatele küsimustele, lähtudes selle struktuurist ja semantikast, mitte pinnapealsest tekstist. See nõuab koodi mudeli loomist ja päringute tegemist, mis esindab koodi tähendust, mitte ainult seda, mida see ütleb.

Suurettevõtete süsteemides arendusülesannete toetamiseks vajalikul tasemel koodi mõistmise minimaalsed tehnilised nõuded on märkimisväärsed. Igaüks neist esindab võimekust, mida tekstiotsingul pole ja mida ükski tekstiotsingu ja käsitsi töötamise kombinatsioon ei suuda usaldusväärselt suures mahus korrata.

Parsimine: tekstist struktuurini

Esimene samm tekstiotsingust edasi on parsimine: lähtekoodi lugemine vastavalt keele grammatikale ja struktureeritud esituse, tavaliselt abstraktse süntaksipuu loomine, mis kodeerib koodielementide süntaktilisi seoseid. Parsitud esitus PERFORM CALC-INTEREST THRU CALC-INTEREST-EXIT ei ole string; see on struktureeritud objekt, mis identifitseerib selle PERFORM-lausena vahemiku sihtmärgiga, kus mõlemad lõpp-punktid on lõigunimed praeguses programmis, mis on lahendatavad programmi PROCEDURE DIVISION struktuuri suhtes.

Parsimine on keelespetsiifiline. COBOL-parser mõistab COBOL-grammatikat. Java-parser mõistab Java-grammatikat. JCL-parser mõistab JCL-süntaksit. Mitmekeelses ettevõttesüsteemis nõuab koodi mõistmine parserit iga keskkonnas esineva keele jaoks, mis loob struktuurilisi esitusi, mille üle saab keeltes järjepidevalt arutleda. Nagu üksikasjalikus uurimises käsitletud TypeScripti staatiline analüüs ettevõtte tasandilStruktuuriline ja semantiline analüüs, mis mõistab koodi ülesehitust, moodulite omavahelist suhtlust ning juhtimise ja andmete rakenduses liikumise suunda, on aluseks süntaksikontrollist kaugemale minekule ja tõelise koodi intelligentsuse saavutamisele.

Sümbolite lahutusvõime: nimedest üksusteni

Pärast parsimist tuleb lähtekoodis olevad nimed lahendada üksusteks, millele nad viitavad. Identifikaator CALC-INTEREST PERFORM-lauses tuleb lahendada konkreetse programmi või vihiku konkreetse lõigu definitsiooniks. Meetodi nimi calculateLegacyFee Java-kõnes tuleb lahendada konkreetse meetodi definitsioonini konkreetses klassis, arvestades pärimist ja ülekoormust. Veeru nimi ACCT_BALANCE SQL-päringus tuleb lahendada andmebaasi skeemi konkreetse tabeli konkreetse veeruni.

Sümboliresolutsioon on see, mis teisendab stringi nime viiteks konkreetsele, tuvastatavale koodiüksusele, millel on asukoht, tüüp ja suhete komplekt teiste üksustega. Ilma sümboliresolutsioonita on kõik koodipäringud tekstipäringud. Selle puhul on päring „kõik selle funktsiooni kutsujad” struktuurne päring lahendatud kõnede seoste graafiku vastu, tagastades ainult need tulemused, mis on tegelikult konkreetse funktsiooni kõned, mitte kõiki faile, kus funktsiooni nimi juhtub esinema.

Sümbolite lahendamine muutub dramaatiliselt keerukamaks mitmekeelsetes keskkondades, kus sama mõistet nimetatakse keelepiiride lõikes erinevalt. Väljaekvivalentide keelteülene lahendamine, mida uuritakse laiemas kontekstis keskmise taastumisaja lühendamine keeltevahelise indekseerimise abil, on eeltingimuseks igale struktuurianalüüsile, mis jälgib andme- või juhtimisvoogu üle keelepiiri. Ilma selleta lõpeb analüüs keelepiiril ja selle pakutav arusaam on mittetäielik.

Juhtimisvoo analüüs: täitmisradade mõistmine

Juhtimisvoo analüüs kaardistab programmi võimalikud täitmisteed: milliseid harusid millistel tingimustel valitakse, millised laused on kättesaadavad, millised kooditeed on surnud ja millises järjekorras laused üksteise suhtes täidetakse. Seda teavet väljendatakse juhtimisvoo graafikuna, kus sõlmed esindavad järjestikuse koodi põhiplokke ja servad esindavad tingimuslikke või tingimusteta juhtimise üleandmisi.

Juhtimisvoo analüüs võimaldab vastata küsimustele nagu „millistel tingimustel see kooditee käivitub?“ ja „kas see kood on ligipääsetav mis tahes sisenemispunktist?“. Tekstiotsing ei saa neile küsimustele vastata, kuna need puudutavad käivitusteid, mitte stringide esinemiskohti. Lähtekoodis esinev lause võib käivituda või mitte käivituda, olenevalt tingimustest, mis määravad haru, milles see asub. Moodulis defineeritud funktsiooni võidakse kutsuda või mitte, olenevalt sellest, kas mõni käivitustee jõuab kutsumiskohta. Ainult juhtimisvoo analüüs saab neid omadusi määrata. Nagu on uuritud ... uurimisel. staatiliste koodiprobleemide prioriseerimine moderniseerimise ajalSee, mis eristab tegutsemist võimaldavat analüüsi leidudest, mis näivad olulised, kuid ei kajasta tegelikkust, on arusaamine, millised kooditeed tegelikult käivituvad, kui sageli need käivituvad ja millistel tingimustel need aktiveeruvad.

Andmevoo analüüs: väärtuste jälgimine koodi kaudu

Andmevoo analüüs jälgib, kuidas väärtused programmis liiguvad: kuhu muutuja omistatakse, kust selle väärtust loetakse, milliseid teisendusi omistamise ja kasutamise vahel rakendatakse ning kas ühe muutuja väärtus sõltub teise muutuja väärtusest. See teave vastab küsimustele, näiteks „kust selle välja väärtus pärineb?“ ja „millist koodi mõjutab selle välja väärtuse muutus?“.

Andmevoo analüüs on tehniline alus väljajälgimiseks, plekkide analüüsiks ja sõltuvuste jälgimiseks väärtuste tasandil. See töötab programmi juhtimisvoo graafikul, levitades väärtusteavet mööda täitmisteed ja salvestades väärtuste päritolu, liikumist ja tarbimist. Tulemuseks on andmevoo graafik, mis ühendab definitsioonid kasutusaladega kogu programmi täitmisruumis, mitte ainult lähtekoodifaili järjestikuse teksti sees.

Ettevõtte süsteemides peab andmevoo analüüs olema kasulik, et see ületaks keelepiire. Väärtus, mis pärineb COBOL-programmist, läbib andmebaasi kirjutamise ja mida seejärel loeb Java-teenus, sisaldab andmevoogu, mis ületab kahte keelepiiri. Selle voo jälgimiseks on vaja andmevoo analüüsi, mis mõistab COBOL-i määramise semantikat, SQL-andmete liikumist ja Java muutujate määramist sama ühtse analüüsi osana, mitte kolme eraldi analüüsina, mille tulemused tuleb käsitsi ühendada. Nagu on üksikasjalikult kirjeldatud analüüsis teadmiste edasiandmine COBOL-i VKEdelt kaasaegsetele arendusmeeskondadele, võime muuta keerulised COBOL-süsteemid tänapäeva arendajatele arusaadavaks ilma, et nad peaksid keelt omandama, sõltub struktuurianalüüsi olemasolust, mis suudab süsteemi käitumist esitada kujul, mis ületab lähteteksti.

Ülesanded, kus erinevus on kõige olulisem

Tekstiotsingu ja koodi mõistmise eristamine ei ole akadeemiline. See tuleb esile spetsiifilistes ja kõrge riskiga arendusülesannetes, kus vale tööriist annab tulemusi, mis näivad olevat täielikud, kuid ei ole seda, ning kus mittetäielike tulemuste põhjal tegutsemisel on mõõdetavad tagajärjed.

Mõjuanalüüs enne muudatuste tegemist

Enne funktsiooni signatuuri muutmist, välja ümbernimetamist või jagatud utiliidi käitumise muutmist peab arendaja teadma, mida see mõjutab. See on mõjuanalüüs: kõigi muudetavast elemendist sõltuva komponendi loetlemine, et muudatust saaks ohutult teha ja kõiki mõjutatud komponente saaks värskendada. Mõjuanalüüs on koodi mõistmise ülesanne. See nõuab komponentide vaheliste sõltuvussuhete lahendamist, nende suhete läbimist muudetud elemendist väljapoole ja iga mõjutatud komponendi tagastamist sõltuvuspuu mis tahes tasemel.

Tekstiotsing lähendab mõjuanalüüsi, leides muudetud elemendi nime asukoha. Kuid see ei suuda eristada sõltuvust kommentaarist, otsest sõltuvust transitiivsest ega aktiivset sõltuvust viitest surnud koodis. Arendaja, kes tugineb enne olulise muudatuse tegemist mõjuanalüüsi tegemiseks tekstiotsingule, teeb ohutuse seisukohalt kriitilise otsuse ligikaudse hinnangu põhjal. Väikeses, ühes keeles koodibaasis võib ligikaudne väärtus olla piisavalt lähedal. Ettevõtte süsteemis, kus on keelteülesed sõltuvused, paljude teenuste poolt tarbitavad jagatud teegid ja aastakümneid kogunenud kõnesuhted, võib tekstiotsingu tulemuste ja muudatuse tegeliku mõju vahe olla märkimisväärne.

Mõelge erinevusele, mida need kaks lähenemisviisi tagastavad laialdaselt kasutatava andmebaasi veeru skeemi muutmise korral:

Mida arendaja peab teadma	Tekstiotsingu tulemus	Koodi mõistmise tulemus
Programmid, mis seda veergu loevad	Kõik failid, mis sisaldavad veeru nime, sealhulgas kommentaarid	Ainult programmid, mille SQL SELECT-laused viitavad sellele veerule
Programmid, mis kirjutavad selle veeru	Sama filtreerimata loend	Sellesse veergu kirjutavad ainult programmid, millel on SQL INSERT või UPDATE käsklused
Sellest veerust sõltuvad teenused	Keelteülene nähtavus puudub	Java, Pythoni ja .NET teenused, mis seovad veeru objektiväljaga
Surnud koodi viited	Tulemustesse lisatud, märgistamata	Välistatud või eraldi märgistatud
Transitiivsed ülalpeetavad	Pole näha	Loetletud mis tahes sügavuseni
Täielikkuse kindlus	Tundmatu	Indekseeritud ulatuse suhtes kontrollitav

Sisseelamine ja koodi navigeerimine

Arendaja, kes on suure koodibaasiga alles alustamas, peab looma koodi toimimise mentaalse mudeli: kuidas komponendid ühenduvad, millised andmed süsteemis liiguvad, millised programmid on sisenemispunktid ja millised utiliidid ning milline näeb välja antud äriprotsessi täitmistee. See mudeli loomise harjutus on peamiselt koodi mõistmise ülesanne. Tekstiotsing aitab leida konkreetseid stringe, kuid ei anna struktuurilist konteksti: see leiab, kus sõna esineb, kuid mitte seda, millist rolli süsteemis selle sisaldav kood mängib.

Koodi mõistmise tööriistad kiirendavad sisseelamist, muutes süsteemi struktuuri navigeeritavaks. Interaktiivne kõnegraafik näitab, millised programmid kutsuvad milliseid teisi. Andmevoo jälg näitab, kust väli pärineb ja kuhu see lõpeb. Juhtimisvoo visualiseerimine näitab, millised tingimused reguleerivad, milliseid harusid käivitatakse. Sõltuvuskaart näitab, milliseid komponente on ohutu iseseisvalt muuta ja millised vajavad koordineerimist teiste meeskondadega. Ükski neist ei ole tekstiotsingu tulemus. Need on struktuurianalüüsi tulemused, mida koodi mõistmise tööriistad teevad. Nagu on uuritud kontekstis Mis on staatiline koodianalüüsVõime keerukuses orienteeruda struktureeritud analüüsi, mitte käsitsi lugemise abil, võimaldab meeskondadel tõhusalt töötada süsteemides, mis on liiga suured, et ükski inimene neid pähe mahutaks.

Surnud koodi ja kasutamata elementide tuvastamine

Surnud kood on kood, mis on defineeritud, kuid mitte kunagi käivitatud: funktsioonid, mida kunagi ei kutsuta, harud, milleni kunagi ei jõuta, muutujad, mis on määratud, kuid mida kunagi ei loeta. Surnud koodi tuvastamine on koodi mõistmise ülesanne, mis nõuab täieliku kõnegraafiku loomist ja selle kindlaksmääramist, millistel defineeritud elementidel pole sissetulevaid kõneservasid ühestki kättesaadavast sisenemispunktist. Tekstiotsing ei suuda surnud koodi tuvastada, sest surnud koodile viidatakse definitsiooni järgi eikusagilt. Viite puudumine ei ole string, mida tekstiotsing suudab leida.

Aegunud funktsioonide eemaldamiseks on surnud koodi tuvastamine otseselt oluline. Mõned elemendid, mis näivad olevat aegunud funktsiooni kutsujad, võivad ise olla surnud kood: funktsioonid, mis on kirjutatud aegunud funktsiooni kutsumiseks, kuid mida ennast kunagi ei kutsuta ja seega ei esinda need reaalajas sõltuvust. Reaalajas kutsujate eristamine surnud kutsujatest nõuab sama kõnegraafi analüüsi, mis tuvastab surnud koodi üldiselt. Nagu uuriti kontekstis olulised refaktoreerimise tehnikadstaatiline kasutusanalüüs annab piisavalt teavet, et teha kindlaks, kas funktsioone, silte, lõike või mooduleid kunagi kutsutakse, ning see analüüs on võimalik ainult struktuurilise kutsegraafiku konstrueerimise, mitte tekstiesinemiste loendamise kaudu.

Turvalisuse ja vastavuse auditeerimine

Turvalisuse ja vastavuse auditeerimine nõuab tundlike andmete jälgimist süsteemis: isikuandmete salvestamise koha, neile juurdepääsu võimaldavate kooditeede, juurdepääsukontrollide korrektse paigutamise iga tundlike andmeteni viiva teostustee puhul ning tundlike andmete süsteemist väljapääsu logimise, veateadete või API vastuste kaudu. Need on andmevoo ja juhtimisvoo analüüsi ülesanded, millele tekstiotsing halvasti ligikaudselt reageerib.

Tundliku väljanime tekstiotsing leiab faile, mis seda nime sisaldavad. See ei suuda kindlaks teha, kas nendel failidel on volitatud juurdepääs, volitamata juurdepääs või puudub juurdepääs üldse. See ei suuda kindlaks teha, kas väljale juurdepääsuni viiva täitmisteekonnal on juurdepääsukontrolli kontroll. See ei suuda jälgida, kas välja väärtus kirjutatakse hiljem logisse või tagastatakse API vastuses, mis ei peaks seda sisaldama. Rikkumisanalüüs, mis jälgib tundlike väärtuste voogu süsteemis ja tuvastab, kus need võivad jõuda ebausaldusväärsete väljunditeni, on andmevoo analüüsi võimalus. See on see, mida pakuvad turvateadlikud koodi mõistmise tööriistad ja mida tekstiotsing ei suuda ligikaudselt hinnata.

Kuidas SMART TS XL Pakub koodi mõistmist kogu ettevõttes

SMART TS XL on üles ehitatud eeldusele, et ettevõttesüsteemid vajavad struktuuri mõistmist, mitte teksti otsimist. Selle tarkvaraluure platvorm parsib lähtekoodi igast keelest ja platvormilt keskkonnas, loob iga keele jaoks keelepõhised abstraktsed süntaksipuud ja lahendab need puud ühtseks keelteüleseks graafiks, mis esindab kogu süsteemi struktuurilisi seoseid. COBOL-programmid, JCL-töövood, Java-teenused, .NET-rakendused, Pythoni skriptid, SQL-skeemid, TypeScripti moodulid ja konfiguratsiooniartefaktid on kõik selles graafikus esindatud sõlmede ja servadena, kusjuures seosed on väljendatud tüüpitud ühendustena: kõned, andmevood, õpikute lisamised, skeemiviited ja keeltevahelised ekvivalentsused.

Platvormi ettevõtte otsinguvõimalus pakub koodi mõistmise ülesannete lähtepunkti, kuid see toimib põhimõtteliselt erinevalt tekstiotsingust. Tulemused on korraldatud seose tüübi ja artefakti struktuuri, mitte stringi esinemise järgi. Väljanime päring tagastab definitsioonid, lugemised, kirjutamised, SQL-viited ja käsiraamatu lisamised eraldi kategoriseeritud tulemuste tüüpidena, nii et arendaja, kes küsib „mida sellele väljale kirjutatakse?“, saab täpselt kirjutamisseosed, mitte segaloendi kõigist failidest, kus nimi esineb. See otsingutulemuste struktuuriline korraldus peegeldab aluseks olevat ristviidete mudelit ja annab arendajatele vajaliku konkreetse ja praktilise teabe ilma, et nad peaksid stringi esinemisi käsitsi filtreerima.

Platvormi mõjuanalüüs, kõnegraafi läbimine, juhtimisvoo visualiseerimine ja andmevoo jälgimise võimalused toimivad kõik samal ühtsel struktuurimudelil. Kui arendaja tuvastab aegunud funktsiooni, kuvab kõnegraaf kõik helistajad hierarhia igal tasandil. Skeemi muutmise kavandamisel loetleb mõjuanalüüs kõik tarbijad igas keeles. Kui alustav arendaja peab mõistma partiiprotsessi, muudab juhtimisvoo visualiseerimine teostustee navigeeritavaks ilma, et ta peaks järjest lugema sadu ridu lähtekoodi. Laiemas kontekstis uurituna arendajakogemus ja DX-mõõdikud pärandkoodibaaside jaoksKoodi keerukus ja struktuuriline keerukus on tegurid, mis määravad hooldatavuse, ning tööriistad, mis paljastavad need struktuurilised omadused, mitte ainult pinnateksti, muudavad keerulised süsteemid mastaapselt hallatavaks.

Erinevus selle vahel, mis SMART TS XL pakub ja tekstiotsing näitab, mis vahe on vastatud küsimusel ja alustatud küsimusel. Tekstiotsing alustab uurimist. Koodi mõistmine viib selle lõpule.

Otsingu asendamine mõistmisega – pidev hind

Tekstiotsingu käsitlemine koodi mõistmise asendajana kuhjub vaikselt igasse arendusülesandesse, mis nõuab koodibaasi struktuurilisi teadmisi. Iga tekstiotsingule tuginev mõjuhindamine kannab endas tundmatut hulka vastamata sõltuvusi. Iga keelepiiril peatuv väljajälg jätab osa süsteemist nähtamatuks. Iga surnud koodi tuvastamine, mis loendab stringi esinemisi kõnegraafi kättesaadavuse analüüsimise asemel, sisaldab valepositiivseid tulemusi ja jätab tähelepanuta tõelise surnud koodi. Iga turvaaudit, mis otsib tundlikke väljanimesid andmevoo jälgimise asemel läbi täitmisteede, annab mittetäieliku ja kontrollimatu kinnituse.

Väikeses, ühes keeles ja sageli muudetavas koodibaasis võivad need kulud olla hallatavad. Arendajatel on piisavalt konteksti otsingutulemuste täpseks filtreerimiseks, süsteemi piirid on kõigile meeskonnaliikmetele arusaadavad ja käsitsi kontroll täidab tekstiotsingu jäetud tühimiku piisavalt kiiresti, et vältida tõsiseid vigu. Suures ettevõttesüsteemis, kus on mitu keelt, aastakümneid kogunenud kood ja meeskonnastruktuurid, mis tähendavad, et ükski inimene ei mõista tervikut, kasvavad kulud kokku. Vastamata sõltuvused tulevad tootmises pinnale. Koosolekuruumis usaldust tekitanud mõjuhinnangud põhjustavad väljalaskes ootamatuid ebaõnnestumisi. Turvaauditid, mis hõlmasid iga stringi esinemist, ei avasta tundlikke andmeid paljastavaid andmevoo teid. Teadmisi, mis olid arendajate peas, kes on sellest ajast edasi liikunud, ei saa tekstiotsingust taastada, sest struktuurilisi seoseid, millest nad aru said, ei kodeeritud kunagi lähtekoodifailide üheski stringis.

Üleminek tekstiotsingult koodi mõistmisele ei asenda ühte tööriista teisega. Tekstiotsing säilitab oma rolli ülesannete jaoks, milleks see sobib: stringi leidmine, kiire orienteerumine, konfiguratsioonikontrollid ja failide navigeerimine. Koodi mõistmine pakub struktuurianalüüsi, mida tekstiotsing ei suuda: väljakutsegraafikud, andmevoo jäljed, mõjuanalüüs, surnud koodi tuvastamine ja keeltevahelise sõltuvuse lahendamine. Need kaks toimivad erinevatel abstraktsioonitasanditel, vastavad erinevatele küsimuste kategooriatele ja täidavad erinevaid eesmärke. Nende segamini ajamise hind avaldub vastamata sõltuvustes, valedes hinnangutes ja pidevas riski kuhjumises, mis tuleneb keerukates süsteemides oluliste muudatuste tegemisest mittetäieliku mudeliga sellest, mida nad tegelikult teevad.