Proč textové vyhledávání není totéž co porozumění kódu

Vývojář poprvé otevírá rozsáhlou starší kódovou základnu. Potřebuje pochopit, co se stane se záznamem zákazníka, když je účet uzavřen: které programy jej aktualizují, které dávkové úlohy jej následně čtou, která pole se během procesu upravují a zda nějaký následný systém závisí na konečném stavu. Přirozeným prvním krokem je vyhledávání. Vyhledají název pole pomocí grepu, prohledají výsledky, otevřou několik souborů a začnou číst. Během hodiny najdou odkazy ve dvanácti programech, třech SQL skriptech a proudu úloh JCL. Stejný název pole také najdou v sedmnácti blocích komentářů, čtyřech řetězcích formátu protokolu, dvou testovacích přípravcích a proměnné ve zcela nesouvisejícím subsystému, který shodou okolností sdílí stejný název. Z výsledků vyhledávání nedokážou rozeznat, která z těchto dat jsou skutečná čtení, která zápisy, která transformace a která náhodné kolize názvů. Vědí, jak se pole nazývá. Zatím nechápou, co s ním kód dělá.

Tato mezera mezi nalezením řetězce a pochopením kódu není mezerou, kterou by lepší vyhledávání uzavíralo. Je to mezera mezi dvěma zásadně odlišnými druhy dotazování: jedním, který se ptá „kde se tento text objevuje?“, a druhým, který se ptá „co tento kód dělá?“. Textové vyhledávání je vynikající odpovědí na první otázku. Vůbec to není odpověď na druhou otázku a spojování těchto dvou je jedním z nejkonzistentnějších zdrojů zbytečného úsilí, přehlédnutých závislostí a nesprávného posouzení dopadu ve vývoji softwaru. Toto rozlišení je důležitější ve velkých, heterogenních podnikových systémech než v malých moderních kódových bázích, protože tyto systémy obsahují desetiletí nahromaděné struktury, závislosti mezi jazyky a implicitní vztahy, které existují pouze v chování kódu, nikoli v žádném řetězci, který se objevuje v jeho zdrojových souborech. Jak bylo zkoumáno v analýze metriky kvality kódu a jejich dopadSložitost kódové základny významně ovlivňuje udržovatelnost a žádná metrika odvozená pouze z textových vzorů nezachycuje strukturální vztahy, které určují, jak se kód skutečně chová.

Co textové vyhledávání vlastně dělá

Vyhledávání textu je operace porovnávání podřetězců aplikovaná na soubory považované za nezpracované sekvence znaků. Dotaz je řetězec nebo vzor. Výsledkem je seznam umístění, kde se daný vzor objevuje. Nástroj nezná jazyk, ve kterém jsou soubory napsány, nerozumí gramatice, která dává textu jeho strukturu, a nemá žádný model vztahů mezi prvky kódu, které text představuje. Grep napříč milionem řádků zdrojového kódu COBOL funguje na stejném modelu jako grep napříč milionem řádků HTML: sekvence znaků v souborech, seskupené podle cesty k souboru, vrácené, když se sekvence znaků shoduje.

To je nesmírně užitečné pro specifickou kategorii úkolů: nalezení místa výskytu známého řetězce, ověření, zda je konkrétní termín použit nebo chybí, provedení rychlé kontroly správnosti konvencí pojmenování, nalezení souboru, který obsahuje konkrétní chybovou zprávu. Pro tyto úkoly je textové vyhledávání tím správným nástrojem, protože se skutečně jedná o hledání řetězců. Rychlost, přenositelnost a nulová konfigurace příkazu grep a jeho ekvivalentů jsou vlastnosti, které se perfektně hodí, když je otázka ve tvaru „existuje tento řetězec v těchto souborech a pokud ano, kde?“.

Problém nastává, když se textové vyhledávání používá pro otázky, které se netýkají řetězců. „Co volá tuto funkci?“ se netýká toho, kde se název funkce objevuje. Je to otázka na graf volání, což je strukturální vlastnost kódu, jejíž konstrukce vyžaduje parsování a sémantickou analýzu. „Kde je toto pole zapsáno?“ se netýká toho, kde se název pole objevuje. Je to otázka na tok dat, na kterou je pro zodpovězení nutné porozumět sémantice přiřazení v daném jazyce. „Co se pokazí, když změním toto rozhraní?“ se netýká toho, kde se název rozhraní objevuje. Je to otázka na vztahy závislostí, která pro správnou odpověď vyžaduje vyřešení importů, dědičnosti a propojení mezi moduly.

Každá z těchto otázek používá jako výchozí bod název, což láká k tomu, abychom je považovali za vyhledávací úlohy. Název je však pouze vstupním bodem. Odpověď se nachází ve strukturálním modelu kódu, nikoli v textu zdrojových souborů.

Problém s šumem: Příliš mnoho výsledků, které nic neznamenají

Prvním typem selhání textového vyhledávání aplikovaného na úlohy porozumění kódu je nadprodukce: vrací mnohem více výsledků, než je relevantních, bez mechanismu, který by identifikoval, které výsledky jsou strukturálně významné a které jsou náhodné.

Krátký identifikátor, jako například status, id, typenebo date se může v rozsáhlé kódové základně objevit tisíckrát. Ještě delší identifikátory kolidují napříč jazyky a jmennými prostory: calculate_tax jako název funkce v modulu Pythonu, název odstavce v COBOLu, uložená procedura v databázi, pomocný nástroj JavaScriptu a řetězec v konfiguraci protokolování, to vše vytváří shodné výsledky textového vyhledávání. Vývojář, který tyto výsledky obdrží, je musí filtrovat ručně a na základě vlastního porozumění kódu určit, které výskyty jsou relevantní. Toto ruční filtrování je samo o sobě úkolem porozumění kódu, což znamená, že vývojář vykonává práci, kterou měl nástroj dělat, bez jakékoli pomoci od nástroje.

V praxi vývojáři filtrují podle intuice a zkušeností. Rozpoznávají, že výsledek v testovacím souboru pravděpodobně neodpovídá produkčnímu volajícímu kódu. Rozpoznávají, že výsledek uvnitř bloku komentářů je dokumentace, nikoli volání. Ignorují výsledky v souborech, které považují za irelevantní. Tyto filtry jsou však omylné a neověřitelné. Vývojář, který filtruje s jistotou, se může mýlit. Vývojář, který filtruje opatrně, může filtrováním strávit hodiny. A v obou případech je výsledkem sada zjištění, která odráží úsudek vývojáře, nikoli ověřená strukturální analýza kódu.

Uvažujme konkrétní příklad. Vývojář v COBOLu hledá název odstavce, než jej odstraní:

cobol

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)

Z těchto osmi výsledků jsou přesně dva aktivní volající, které by se přerušily, pokud by byl odstavec odstraněn: řádky 3 a 5. Řádek 2 je definice. Řádky 4 a 8 jsou komentáře. Řádek 6 je položka datového slovníku. Řádek 7 je testovací svazek. Určení, které dva z těchto osmi výsledků představují aktivní weby s voláními, vyžaduje přečtení každého souboru v kontextu, pochopení syntaxe COBOLu a posouzení, co „zakázáno“ v komentáři na řádku 8 ve skutečnosti znamená pro spuštění. Surový materiál poskytlo textové vyhledávání. Pochopení kódu poskytlo odpověď.

Problém ticha: Relevantní výsledky, které se nikdy nevrátí

Druhým způsobem selhání je nedostatečná produkce: chybějící výsledky, které jsou strukturálně významné, protože nejsou vyjádřeny ve formě, které by textové vyhledávání odpovídalo.

Nepřímá volání jsou nejčastějším zdrojem chybějících výsledků. Když funkce A volá funkci B a funkce B volá zastaralou funkci C, textové vyhledávání názvu funkce C najde funkci B jako přímou volající funkci, ale nenajde funkci A jako nepřímou volající funkci. Zda je A relevantní výsledek, závisí na účelu vyhledávání: pokud je cílem pochopit vše, co spouští funkci C, pak je A kritické. Pokud je cílem pouze najít bezprostřední volající funkce, pak je A irelevantní. Textové vyhledávání toto rozlišení nedokáže rozlišit, protože nemá koncept grafu volání. Vrací jakýkoli text, který se shoduje, bez vědomí, čeho je odpovídající text součástí.

Mezijazyčné odkazy jsou systematicky chybějící kategorií. Služba Java, která volá program v COBOLu jménem prostřednictvím middlewarové vrstvy, obsahuje název programu v COBOLu jako řetězcový literál, který textové vyhledávání dokáže najít. Ale tatáž služba Java, která dynamicky konstruuje název programu, čte jej z konfiguračního souboru nebo jej odesílá prostřednictvím abstrakční vrstvy, tento název vůbec neobsahuje. Jedná se o volající, které textové vyhledávání nemůže najít bez ohledu na to, jak důkladně je aplikováno. Jak bylo zkoumáno v kontextu statická analýza obfuskovaného a dynamicky generovaného kóduPokud jsou cesty provádění vyjádřeny nepřímo prostřednictvím konfigurace, šablon nebo mechanismů odesílání za běhu, strukturální vztahy, které reprezentují, nelze zjistit pouze z textu zdrojových souborů.

Aliasy a transformace polí vytvářejí další kategorii tichých chyb. Pole v COBOLu s názvem WS-ACCT-BAL který se zapisuje do sloupce databáze s názvem ACCT_BALANCE, následně přečtený službou Java jako accountBalancea nakonec serializován jako account_balance v odpovědi JSON představuje čtyři různé textové řetězce pro stejný datový prvek. Hledání kteréhokoli z těchto řetězců mine zbývající tři. Vědět, že všechny čtyři odkazují na stejný základní obchodní koncept, vyžaduje pochopení transformačního řetězce, nikoli nalezení všech výskytů daného názvu.

Co pochopení kódu skutečně vyžaduje

Porozumění kódu jako technická schopnost je schopnost odpovídat na otázky týkající se kódu na základě jeho struktury a sémantiky, nikoli povrchního textu. Vyžaduje vytvoření a dotazování modelu kódu, který reprezentuje to, co kód znamená, nikoli jen to, co říká.

Minimální technické požadavky na porozumění kódu na úrovni potřebné pro podporu vývojových úkolů ve velkých podnikových systémech jsou značné. Každý z nich představuje funkci, kterou textové vyhledávání nemá a kterou žádná kombinace textového vyhledávání a manuální práce nemůže spolehlivě replikovat ve velkém měřítku.

Parsování: Z textu do struktury

Prvním krokem nad rámec textového vyhledávání je parsování: čtení zdrojového kódu podle gramatiky jeho jazyka a vytvoření strukturované reprezentace, obvykle abstraktního syntaktického stromu, který kóduje syntaktické vztahy mezi prvky kódu. Parsovaná reprezentace PERFORM CALC-INTEREST THRU CALC-INTEREST-EXIT není řetězec; je to strukturovaný objekt, který identifikuje toto jako příkaz PERFORM s cílovým rozsahem, kde oba koncové body jsou názvy odstavců v aktuálním programu, které lze rozlišit podle struktury PROCEDURE DIVISION programu.

Parsování je specifické pro daný jazyk. Parser COBOL rozumí gramatice COBOL. Parser Java rozumí gramatice Java. Parser JCL rozumí syntaxi JCL. V podnikovém systému s více jazyky vyžaduje porozumění kódu parser pro každý jazyk přítomný v prostředí, který vytváří strukturální reprezentace, o kterých lze konzistentně uvažovat napříč jazyky. Jak je popsáno v podrobném zkoumání Statická analýza TypeScriptu v podnikovém měřítku, strukturální a sémantická analýza, která chápe, jak je kód organizován, jak moduly interagují a jak řízení a tok dat aplikací probíhají, je základem pro přechod od kontroly syntaxe ke skutečné inteligenci kódu.

Rozlišení symbolů: Od jmen k entitám

Po parsování musí být názvy ve zdrojovém kódu převedeny na entity, na které odkazují. Identifikátor CALC-INTEREST v příkazu PERFORM musí být přeložen na specifickou definici odstavce v konkrétním programu nebo sešitě. Název metody calculateLegacyFee v Java volání musí být přeloženo na specifickou definici metody v dané třídě s pohledem na dědičnost a přetížení. Název sloupce ACCT_BALANCE v SQL dotazu musí být přeložen na konkrétní sloupec v konkrétní tabulce ve schématu databáze.

Rozlišení symbolů transformuje název z řetězce na odkaz na konkrétní, identifikovatelnou entitu kódu s umístěním, typem a sadou vztahů k jiným entitám. Bez rozlišení symbolů jsou všechny dotazy kódu textovými dotazy. S ním je dotaz na „všechny volající této funkce“ strukturálním dotazem na vyřešený graf vztahů volání a vrací pouze výsledky, které jsou skutečnými voláními konkrétní funkce, nikoli všechny soubory, kde se název funkce objevuje.

Rozlišení symbolů se stává dramaticky složitějším ve vícejazyčných prostředích, kde je stejný koncept napříč jazykovými hranicemi pojmenováván různě. Mezijazyčné rozlišení ekvivalencí polí, zkoumané v širším kontextu... zkrácení průměrné doby do zotavení díky indexování v různých jazycích, je nezbytným předpokladem pro jakoukoli strukturální analýzu, která sleduje tok dat nebo řízení přes hranice jazyka. Bez něj analýza končí na hranici a porozumění, které poskytuje, je neúplné.

Analýza toku řízení: Pochopení cest provádění

Analýza toku řízení mapuje možné cesty provádění v programu: které větve se provádějí za jakých podmínek, které příkazy jsou dosažitelné, které cesty kódu jsou mrtvé a v jakém pořadí se příkazy vzájemně provádějí. Tato informace je vyjádřena jako graf toku řízení, kde uzly představují základní bloky sekvenčního kódu a hrany představují podmíněné nebo bezpodmínečné přenosy řízení.

Analýza toku řízení umožňuje odpovědět na otázky typu „za jakých podmínek se tato cesta kódu spustí?“ a „je tento kód dosažitelný z jakéhokoli vstupního bodu?“. Textové vyhledávání nemůže na tyto otázky odpovědět, protože se týká cest provádění, nikoli toho, kde se řetězce objevují. Příkaz, který se objeví ve zdrojovém kódu, se může, ale nemusí spustit v závislosti na podmínkách, které omezují větev, ve které se nachází. Funkce definovaná v modulu může, ale nemusí být volána v závislosti na tom, zda jakákoli cesta provádění dosáhne místa volání. Tyto vlastnosti může určit pouze analýza toku řízení. Jak bylo zkoumáno při zkoumání upřednostňování problémů se statickým kódem během modernizacePochopení toho, které kódové cesty se skutečně spouštějí, jak často se spouštějí a za jakých podmínek se aktivují, je to, co odlišuje proveditelnou analýzu od zjištění, která vypadají významně, ale neodrážejí provozní realitu.

Analýza toku dat: Sledování hodnot v kódu

Analýza toku dat sleduje, jak se hodnoty pohybují programem: kde je proměnná přiřazena, kde je její hodnota čtena, jaké transformace se na ni aplikují mezi přiřazením a použitím a zda hodnota jedné proměnné závisí na hodnotě jiné. Tyto informace odpovídají na otázky typu „odkud pochází hodnota tohoto pole?“ a „jaký kód je ovlivněn, pokud se hodnota tohoto pole změní?“.

Analýza toku dat je technickým základem pro trasování polí, analýzu narušení a sledování závislostí na úrovni hodnot. Pracuje na grafu toku řízení programu, šíří informace o hodnotách podél cest provádění a zaznamenává, odkud hodnoty pocházejí, kam proudí a kde jsou spotřebovávány. Výsledkem je graf toku dat, který propojuje definice s použitími v celém prostoru provádění programu, nejen v rámci sekvenčního textu zdrojového souboru.

V podnikových systémech musí analýza datového toku překračovat hranice jazyků, aby byla užitečná. Hodnota, která pochází z programu v COBOLu, prochází zápisem do databáze a následně je čtena službou Java, má datový tok, který překračuje hranice dvou jazyků. Sledování tohoto toku vyžaduje analýzu datového toku, která chápe sémantiku přiřazení v COBOLu, pohyb dat SQL a přiřazení proměnných v Javě jako součást stejné sjednocené analýzy, nikoli jako tři samostatné analýzy, jejichž výsledky je nutné ručně propojit. Jak je podrobně uvedeno v analýze přenos znalostí z malých a středních podniků zabývajících se COBOLem do moderních vývojových týmůSchopnost vytvořit složité systémy v jazyce COBOL srozumitelné pro moderní vývojáře, aniž by od nich bylo nutné jazyk ovládat, závisí na strukturální analýze, která dokáže reprezentovat chování systému ve formě přesahující zdrojový text.

Úkoly, kde na rozdílu nejvíce záleží

Rozdíl mezi textovým vyhledáváním a porozuměním kódu není akademický. Projevuje se u specifických, vysoce náročných vývojových úkolů, kde nesprávný nástroj produkuje výsledky, které vypadají jako úplné, ale nejsou, a kde má řešení neúplných výsledků měřitelné důsledky.

Analýza dopadu před provedením změny

Před úpravou signatury funkce, přejmenováním pole nebo změnou chování sdíleného nástroje musí vývojář vědět, co bude ovlivněno. Toto je analýza dopadu: výčet všech komponent, které závisí na měněném prvku, aby bylo možné změnu provést bezpečně a všechny ovlivněné komponenty mohly být aktualizovány. Analýza dopadu je úkol porozumění kódu. Vyžaduje vyřešení vztahů závislostí mezi komponentami, procházení těchto vztahů od změněného prvku směrem ven a vrácení všech komponent, které budou ovlivněny na jakékoli úrovni stromu závislostí.

Textové vyhledávání aproximuje analýzu dopadu nalezením místa, kde se objevuje název změněného prvku. Nedokáže však rozlišit závislost od komentáře, přímou závislost od tranzitivní ani aktivní závislost od odkazu v mrtvém kódu. Vývojář, který se před významnou změnou spoléhá na textové vyhledávání pro analýzu dopadu, činí bezpečnostní rozhodnutí na základě aproximace. V malé kódové základně s jedním jazykem může být aproximace dostatečně blízká. V podnikovém systému s mezijazykovými závislostmi, sdílenými knihovnami spotřebovanými mnoha službami a desítkami let nahromaděných vztahů volání může být rozdíl mezi tím, co textové vyhledávání vrátí, a skutečným dopadem změny, značný.

Zvažte rozdíl v tom, co tyto dva přístupy vracejí pro změnu schématu široce používaného sloupce databáze:

Co potřebuje vývojář vědět	Výsledek textového vyhledávání	Výsledek porozumění kódu
Programy, které čtou tento sloupec	Všechny soubory obsahující název sloupce, včetně komentářů	Pouze programy s příkazy SQL SELECT, které odkazují na tento sloupec
Programy, které píší tento sloupec	Stejný nefiltrovaný seznam	Pouze programy s příkazy SQL INSERT nebo UPDATE zapisujícími do tohoto sloupce
Služby závislé na tomto sloupci	Žádná viditelnost v různých jazycích	Služby Javy, Pythonu a .NET, které mapují sloupec na pole objektu
Odkazy na mrtvý kód	Zahrnuto ve výsledcích, neoznačeno	Vyloučené nebo označené samostatně
Tranzitivní závislé osoby	Není vidět	Výčet do libovolné hloubky
Důvěra v úplnost	Neznámý	Ověřitelné oproti indexovanému rozsahu

Zaškolení a navigace kódem

Vývojář, který je nově v oblasti rozsáhlé kódové základny, si musí vytvořit mentální model toho, co kód dělá: jak se komponenty propojují, jaká data proudí systémem, které programy jsou vstupními body a které utility a jak vypadá cesta provádění daného obchodního procesu. Toto cvičení zaměřené na budování modelu je převážně úkolem porozumění kódu. Textové vyhledávání pomáhá s nalezením konkrétních řetězců, ale neposkytuje žádný strukturální kontext: vyhledává, kde se slovo objevuje, ale ne jakou roli hraje kód, který ho v systému obsahuje.

Nástroje pro porozumění kódu urychlují zavádění systému tím, že usnadňují navigaci ve struktuře systému. Interaktivní graf volání ukazuje, které programy volají které další. Sledování toku dat ukazuje, kde pole začíná a kde končí. Vizualizace toku řízení ukazuje, jaké podmínky určují, které větve se spouštějí. Mapa závislostí ukazuje, které komponenty lze bezpečně upravovat nezávisle a které vyžadují koordinaci s ostatními týmy. Nic z toho není produktem textového vyhledávání. Jsou to produkty strukturální analýzy, kterou provádějí nástroje pro porozumění kódu. Jak bylo zkoumáno v kontextu co je statická analýza kóduSchopnost orientovat se ve složitosti prostřednictvím strukturované analýzy namísto manuálního čtení je to, co umožňuje týmům efektivně pracovat v systémech, které jsou příliš velké na to, aby si je jednotlivec dokázal udržet v hlavě.

Identifikace mrtvého kódu a nepoužívaných prvků

Mrtvý kód je kód, který je definován, ale nikdy není spuštěn: funkce, které nejsou nikdy volány, větve, kterých není nikdy dosaženo, proměnné, které jsou přiřazeny, ale nikdy nejsou přečteny. Identifikace mrtvého kódu je úkol porozumění kódu, který vyžaduje konstrukci kompletního grafu volání a určení, které definované prvky nemají žádné příchozí hrany volání z jakéhokoli dosažitelného vstupního bodu. Textové vyhledávání nemůže identifikovat mrtvý kód, protože mrtvý kód je ze své podstaty odkazován odnikud. Absence odkazu není řetězec, který by textové vyhledávání mohlo najít.

Pro odstranění zastaralých funkcí je přímo relevantní identifikace mrtvého kódu. Některé prvky, které se jeví jako volající zastaralé funkce, mohou samy o sobě být mrtvým kódem: funkce, které byly napsány pro volání zastaralé funkce, ale samy nikdy nejsou volány, a proto nepředstavují žádnou aktivní závislost. Rozlišení aktivních volajících od mrtvých volajících vyžaduje stejnou analýzu grafu volání, která obecně identifikuje mrtvý kód. Jak bylo zkoumáno v kontextu základní techniky refaktoringuStatická analýza použití poskytuje dostatečný vhled k určení, zda jsou funkce, popisky, odstavce nebo moduly vůbec volány, a tato analýza je možná pouze prostřednictvím strukturální konstrukce grafu volání, nikoli prostřednictvím počítání výskytů textu.

Audit bezpečnosti a dodržování předpisů

Audit zabezpečení a dodržování předpisů vyžaduje sledování citlivých dat v systému: identifikaci místa, kde jsou uloženy osobní údaje, které cesty kódu k nim mají přístup, zda jsou kontroly řízení přístupu správně umístěny v každé cestě provádění, která vede k citlivým datům, a zda citlivá data mohou uniknout ze systému prostřednictvím protokolování, chybových zpráv nebo odpovědí API. Jedná se o úlohy analýzy toku dat a toku řízení, které textové vyhledávání špatně aproximuje.

Textové vyhledávání pro název citlivého pole vyhledá soubory, které daný název obsahují. Nelze určit, zda tyto soubory provádějí autorizovaný přístup, neoprávněný přístup nebo vůbec žádný přístup. Nelze určit, zda v cestě provádění vedoucí k přístupu k poli existuje kontrola řízení přístupu. Nelze vysledovat, zda je hodnota pole následně zapsána do protokolu nebo vrácena v odpovědi API, která by ji obsahovat neměla. Analýza kontaminace, která sleduje tok citlivých hodnot systémem a identifikuje, kde mohou dosáhnout nedůvěryhodných výstupů, je funkcí analýzy toku dat. Je to to, co poskytují nástroje pro porozumění kódu zaměřené na bezpečnost a co textové vyhledávání nedokáže aproximovat.

Jak SMART TS XL Zajišťuje porozumění kódu v celém podniku

SMART TS XL je postaven na předpokladu, že podnikové systémy vyžadují strukturální porozumění, nikoli vyhledávání textu. Jeho platforma Software Intelligence analyzuje zdrojový kód z každého jazyka a platformy v prostředí, pro každý z nich vytváří abstraktní syntaktické stromy specifické pro daný jazyk a tyto stromy převádí do jednotného grafu napříč jazyky, který reprezentuje strukturální vztahy celého systému. Programy v COBOLu, toky úloh JCL, služby Java, aplikace .NET, skripty Pythonu, schémata SQL, moduly TypeScript a konfigurační artefakty jsou v tomto grafu reprezentovány jako uzly a hrany, přičemž vztahy jsou vyjádřeny jako typovaná spojení: volání, datové toky, zahrnutí do sešitů, odkazy na schémata a mezijazykové ekvivalence.

Podnikové vyhledávání na platformě poskytuje vstupní bod pro úkoly porozumění kódu, ale funguje zásadně odlišně od textového vyhledávání. Výsledky jsou uspořádány podle typu vztahu a struktury artefaktů, nikoli podle výskytu řetězce. Dotaz na název pole vrací definice, čtení, zápisy, SQL odkazy a zahrnutí do sešitu jako samostatně kategorizované typy výsledků, takže vývojář, který se zeptá „co zapisuje do tohoto pole?“, obdrží přesně vztahy zápisu, nikoli smíšený seznam všech souborů, kde se název objeví. Tato strukturální organizace výsledků vyhledávání odráží základní model křížových odkazů a poskytuje vývojářům konkrétní a akční informace, které potřebují, aniž by museli ručně filtrovat výskyty řetězců.

Analýza dopadu, procházení grafu volání, vizualizace toku řízení a sledování toku dat platformy fungují na stejném jednotném strukturálním modelu. Když vývojář identifikuje zastaralou funkci, graf volání zobrazí všechny volající na všech úrovních hierarchie. Pokud je plánována změna schématu, analýza dopadu vyjmenuje všechny uživatele napříč všemi jazyky. Když vývojář, který se chystá na nástup, potřebuje porozumět dávkovému procesu, vizualizace toku řízení umožňuje snadnou navigaci po cestě provádění, aniž by musel postupně číst stovky řádků zdrojového kódu. Jak bylo zkoumáno v širším kontextu... zkušenosti vývojářů a DX metriky pro starší kódové základnySložitost kódu a strukturální složitost jsou faktory, které určují udržovatelnost, a nástroje, které odhalují tyto strukturální vlastnosti, spíše než jen povrchní text, jsou tím, co umožňuje spravovat složité systémy ve velkém měřítku.

Rozdíl mezi tím, co SMART TS XL poskytuje a to, co textové vyhledávání poskytuje, je rozdíl mezi zodpovězenou otázkou a zahájenou otázkou. Textové vyhledávání zahajuje šetření. Porozumění kódu ho dokončuje.

Trvalé náklady na nahrazování porozumění hledáním

Praktické důsledky chápání textového vyhledávání jako náhrady za porozumění kódu se tiše hromadí v každém vývojovém úkolu, který vyžaduje strukturální znalost kódové základny. Každé posouzení dopadu, které se spoléhá na textové vyhledávání, s sebou nese neznámé množství přehlédnutých závislostí. Každé trasování pole, které se zastaví na hranici jazyka, ponechává část systému neviditelnou. Každá identifikace mrtvého kódu, která počítá výskyty řetězců namísto analýzy dosažitelnosti grafu volání, zahrnuje falešně pozitivní výsledky a mine skutečně mrtvý kód. Každý bezpečnostní audit, který hledá citlivé názvy polí namísto trasování toku dat skrze prováděcí cesty, poskytuje ujištění, které je neúplné a neověřitelné.

V malé, jednom jazyce používané a často upravované kódové základně mohou být tyto náklady zvládnutelné. Vývojáři mají dostatek kontextu k přesnému filtrování výsledků vyhledávání, hranice systému chápou všichni v týmu a manuální kontrola dostatečně rychle vyplní mezeru po textovém vyhledávání, aby se předešlo vážným chybám. Ve velkém podnikovém systému s více jazyky, desítkami let nahromaděného kódu a týmovými strukturami, které znamenají, že žádný jednotlivec nerozumí celku, se náklady hromadí. V produkčním prostředí se objevují přehlédnuté závislosti. Hodnocení dopadů, která v zasedací místnosti vzbuzovala sebevědomí, způsobuje překvapivé selhání ve vydání. Bezpečnostní audity, které pokrývaly každý výskyt řetězce, nezachycují cesty toku dat, které odhalují citlivá data. Znalosti, které byly uchovávány v hlavách vývojářů, kteří od té doby odešli, nelze rekonstruovat z textového vyhledávání, protože strukturální vztahy, kterým rozuměli, nebyly nikdy zakódovány v žádném řetězci ve zdrojových souborech.

Přechod od textového vyhledávání k porozumění kódu nepředstavuje nahrazení jednoho nástroje jiným. Textové vyhledávání si zachovává svou roli pro úkoly, pro které je vhodné: vyhledávání řetězců, rychlá orientace, kontrola konfigurace a navigace v souborech. Porozumění kódu poskytuje strukturální analýzu, kterou textové vyhledávání nemůže: volání grafů, trasování datových toků, analýza dopadů, identifikace mrtvého kódu a řešení závislostí mezi jazyky. Tyto dva nástroje fungují na různých úrovních abstrakce, odpovídají na různé kategorie otázek a slouží různým účelům. Cena za jejich smíšení se vyplácí v podobě přehlédnutých závislostí, nesprávných posouzení a neustálého hromadění rizik, které plyne z provádění následných změn ve složitých systémech s neúplným modelem toho, co skutečně dělají.