{"id":32848,"date":"2019-10-31T21:49:16","date_gmt":"2019-10-31T18:49:16","guid":{"rendered":"https:\/\/prohoster.info\/blog\/vnedryajte-staticheskij-analiz-v-protsess-a-ne-ishhite-s-ego-pomoshhyu-bagi\/"},"modified":"2019-10-31T21:49:16","modified_gmt":"2019-10-31T18:49:16","slug":"vnedryajte-staticheskij-analiz-v-protsess-a-ne-ishhite-s-ego-pomoshhyu-bagi","status":"publish","type":"post","link":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/vnedryajte-staticheskij-analiz-v-protsess-a-ne-ishhite-s-ego-pomoshhyu-bagi","title":{"rendered":"Integr\u00e9r statisk analyse i processen, i stedet for at bruge den til at finde fejl.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

At skrive denne artikel blev jeg opmuntret af det store antal materialer om statisk analyse, som jeg oftere st\u00f8der p\u00e5. For det f\u00f8rste er det bloggen PVS-studio<\/a><\/noindex>, som aktivt promoverer sig selv p\u00e5 Habr ved hj\u00e6lp af anmeldelser af fejl, som deres v\u00e6rkt\u00f8j har fundet i open source-projekter. For nylig implementerede PVS-studio underst\u00f8ttelse af Java<\/a><\/noindex>, og selvf\u00f8lgelig kunne udviklerne af IntelliJ IDEA, hvis indbyggede analyserer i dag sandsynligvis er den mest avancerede for Java, ikke forblive udenfor<\/a><\/noindex>. <\/p>\n

N\u00e5r man l\u00e6ser s\u00e5danne anmeldelser, f\u00e5r man indtryk af, at der er tale om en magisk elixir: tryk p\u00e5 knappen, og voila \u2014 listen over defekter dukker op foran en. Det virker som om, at efterh\u00e5nden som analysatorerne forbedres, vil fejl blive fundet i st\u00f8rre og st\u00f8rre omfang, og de produkter, der er scannet af disse robotter, vil blive bedre og bedre uden nogen anstrengelse fra vores side.<\/p>\n

Men der findes ikke nogen magiske elixirer. Jeg vil gerne tale om, hvad der normalt ikke n\u00e6vnes i indl\u00e6g som \u00abher er hvad vores robot kan finde\u00bb: hvad analysev\u00e6rkt\u00f8jer ikke kan, hvilken reel rolle de spiller, og hvordan man implementerer dem korrekt i softwareleveringsprocessen.<\/p>\n

\"Integr\u00e9r
\nKatalysator (kilde: wikipedia<\/a><\/noindex>).<\/i>
\n<\/a><\/noindex><\/p>\n

Hvad statiske analysatorer aldrig vil kunne g\u00f8re<\/h2>\n

\nHvad er, set fra et praktisk synspunkt, analysen af kildekoden? Vi indsender nogle kildefiler, og p\u00e5 kort tid (voldsomt hurtigere end at k\u00f8re tests) f\u00e5r vi nogle oplysninger om vores system. Det grundl\u00e6ggende og matematisk uoverkommelige begr\u00e6nsning er, at vi kun kan f\u00e5 en relativt smal klasse af oplysninger p\u00e5 denne m\u00e5de.<\/p>\n

Det mest ber\u00f8mte eksempel p\u00e5 et problem, der ikke kan l\u00f8ses ved hj\u00e6lp af statisk analyse \u2014 stopproblemet<\/a><\/noindex>: det er en s\u00e6tning, der beviser, at det er umuligt at udvikle en generel algoritme, der kan bestemme p\u00e5 baggrund af kildekoden, om et program vil k\u00f8re i en uendelig l\u00f8kke eller afslutte p\u00e5 et begr\u00e6nset tidsrum. En udvidelse af denne s\u00e6tning er Rices s\u00e6tning<\/a><\/noindex>, der for ethvert ikke-trivielt egenskab ved beregnelige funktioner angiver, om et vilk\u00e5rligt program beregner en funktion med denne egenskab, er en algoritmisk uopsl\u00e5elig opgave. For eksempel er det umuligt at skrive en analyser, der for enhver kildekode kan bestemme, om det analyserede program er en implementering af en algoritme, der beregner for eksempel kvadratet af et helt tal.<\/p>\n

Dermed har funktionaliteten af statiske analysev\u00e6rkt\u00f8jer uoverkommelige begr\u00e6nsninger. En statisk analysator vil aldrig kunne bestemme s\u00e5danne ting i alle tilf\u00e6lde, som for eksempel forekomsten af \u201cnull pointer exception\u201d i sprog, der tillader null-v\u00e6rdier, eller i alle tilf\u00e6lde bestemme forekomsten af \u201cattribute not found\u201d i sprog med dynamisk typificering. Alt, hvad den mest avancerede statiske analysator kan g\u00f8re, er at fremh\u00e6ve s\u00e6rtilf\u00e6lde, antallet af hvilke blandt alle mulige problemer med din kildekode er, uden overdrivelse, en dr\u00e5be i havet.<\/p>\n

Statisk analyse er ikke fejlfinding<\/h2>\n

\nAf det ovenst\u00e5ende f\u00f8lger konklusionen: statisk analyse er ikke et redskab til at reducere antallet af defekter i programmet. Jeg vover at p\u00e5st\u00e5, at n\u00e5r det f\u00f8rst anvendes p\u00e5 dit projekt, vil det finde 'interessante' steder i koden, men sandsynligvis ikke finde nogen defekter, der p\u00e5virker kvaliteten af dit programs drift.<\/p>\n

Eksempler p\u00e5 defekter, der automatisk er fundet af analyser, er imponerende, men man skal ikke glemme, at disse eksempler er fundet ved at scanne et stort s\u00e6t store kodebaser. P\u00e5 samme m\u00e5de som hackere, der har mulighed for at gennemg\u00e5 flere enkle adgangskoder p\u00e5 et stort antal konti, til sidst finder de konti, hvor der er en simpel adgangskode.<\/p>\n

Betyder det, at statisk analyse ikke skal anvendes? Naturligvis ikke! Og netop af den samme grund, som det er vigtigt at kontrollere hver ny adgangskode mod listen over 'simple' adgangskoder.<\/p>\n

Statisk analyse er mere end fejlfinding<\/h2>\n

\nI virkeligheden er de praktisk l\u00f8selige opgaver, der kan analyseres, meget bredere. For statisk analyse er generelt enhver kontrol af kildekoden, der udf\u00f8res inden deres k\u00f8rsel. Her er nogle ting, man kan g\u00f8re:<\/p>\n