{"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\/it\/blog\/administrirovanie\/vnedryajte-staticheskij-analiz-v-protsess-a-ne-ishhite-s-ego-pomoshhyu-bagi","title":{"rendered":"Integra l'analisi statica nel processo, invece di cercare bug con essa","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

La mia scrittura di questo articolo \u00e8 stata stimolata da un gran numero di materiali sull'analisi statica, che sempre pi\u00f9 frequentemente attiravano la mia attenzione. Prima di tutto, \u00e8 il blog PVS-studio<\/a><\/noindex>, che promuove attivamente se stesso su Habr tramite recensioni sugli errori trovati dai loro strumenti in progetti open-source. Recentemente PVS-studio ha implementato il supporto per Java<\/a><\/noindex>, e naturalmente, gli sviluppatori di IntelliJ IDEA, il cui analizzatore integrato \u00e8 attualmente, probabilmente, il pi\u00f9 avanzato per Java, non potevano rimanere indifferenti<\/a><\/noindex>. <\/p>\n

Leggendo tali recensioni si ha l'impressione che si tratti di un elisir magico: premi il pulsante e voil\u00e0, ecco la lista dei difetti davanti a te. Sembra che con il perfezionamento degli analizzatori, i bug verranno trovati automaticamente in numero sempre maggiore, e i prodotti scansionati da questi robot diventeranno sempre migliori, senza alcuno sforzo da parte nostra.<\/p>\n

Ma non ci sono elisir magici. Vorrei parlare di ci\u00f2 di cui di solito non si discute nei post del tipo \"ecco cosa pu\u00f2 trovare il nostro robot\": cosa non possono fare gli analizzatori, qual \u00e8 il loro ruolo reale e il loro posto nel processo di consegna del software, e come implementarli correttamente.<\/p>\n

\"Integra
\nRuota dentata (fonte: Wikipedia<\/a><\/noindex>).<\/i>
\n<\/a><\/noindex><\/p>\n

Cosa non potranno mai fare gli analizzatori statici<\/h2>\n

\nCosa significa, dal punto di vista pratico, analizzare il codice sorgente? Forniamo alcuni sorgenti in input e in breve tempo (molto pi\u00f9 breve rispetto all'esecuzione dei test) otteniamo alcune informazioni sul nostro sistema. La limitazione fondamentale e matematicamente insormontabile consiste nel fatto che possiamo ottenere in questo modo solo una classe piuttosto ristretta di informazioni.<\/p>\n

Il pi\u00f9 famoso esempio di un problema irrisolvibile tramite analisi statica \u00e8 il problema dell'arresto<\/a><\/noindex>: \u00e8 un teorema che dimostra che non \u00e8 possibile sviluppare un algoritmo generale in grado di determinare, a partire dal codice sorgente di un programma, se esso entrer\u00e0 in un ciclo infinito o terminer\u00e0 in un tempo finito. L'estensione di questo teorema \u00e8 il teorema di Rice<\/a><\/noindex>, che afferma che, per qualsiasi propriet\u00e0 non banale delle funzioni calcolabili, la definizione di se un programma arbitrario calcola una funzione con tale propriet\u00e0 \u00e8 un problema algoritmicamente non risolvibile. Ad esempio, \u00e8 impossibile scrivere un analizzatore che, dato qualsiasi codice sorgente, determini se il programma analizzato \u00e8 l'implementazione di un algoritmo che calcola, per esempio, il quadrato di un intero.<\/p>\n

Pertanto, la funzionalit\u00e0 degli analizzatori statici presenta limitazioni insormontabili. Un analizzatore statico non sar\u00e0 mai in grado di determinare in tutti i casi cose come, ad esempio, l'insorgere di un \u00abnull pointer exception\u00bb nei linguaggi che ammettono un valore null, o di identificare in tutti i casi l'insorgere di un \u00abattribute not found\u00bb nei linguaggi con tipizzazione dinamica. Tutto ci\u00f2 che il pi\u00f9 sofisticato analizzatore statico pu\u00f2 fare \u00e8 evidenziare casi particolari, il cui numero rispetto a tutti i problemi possibili nel vostro codice sorgente \u00e8, senza esagerare, una goccia nell'oceano.<\/p>\n

L'analisi statica non \u00e8 ricerca di bug.<\/h2>\n

\nDa quanto detto sopra si conclude: l'analisi statica non \u00e8 uno strumento per ridurre il numero di difetti in un programma. Oso affermare che, quando applicata per la prima volta al vostro progetto, essa trover\u00e0 nel codice dei punti 'interessanti', ma molto probabilmente non trover\u00e0 difetti che influiscono sulla qualit\u00e0 del lavoro del vostro programma.<\/p>\n

Esempi di difetti trovati automaticamente dagli analizzatori sono impressionanti, ma non bisogna dimenticare che questi esempi sono stati trovati grazie alla scansione di un ampio set di grandi basi di codice. Allo stesso modo, gli hacker che hanno la possibilit\u00e0 di provare diverse semplici password su un gran numero di account, alla fine trovano quegli account con password semplici.<\/p>\n

Questo significa che non bisogna applicare l'analisi statica? Certo che no! E per lo stesso motivo per cui \u00e8 utile controllare ogni nuova password per vedere se finisce nella lista nera delle 'password semplici'.<\/p>\n

L'analisi statica \u00e8 pi\u00f9 della semplice ricerca di bug.<\/h2>\n

\nIn realt\u00e0, i compiti risolvibili tramite analisi sono molto pi\u00f9 ampi. Infatti, in generale, l'analisi statica \u00e8 qualsiasi verifica del sorgente, effettuata prima della loro esecuzione. Ecco alcune cose che si possono fare:<\/p>\n