{"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 tuo processo, invece di cercare bug con essa","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

La mia decisione di scrivere questo articolo \u00e8 stata ispirata dalla grande quantit\u00e0 di materiale sull'analisi statica che ho notato sempre pi\u00f9 spesso. Innanzitutto, si tratta del blog PVS-studio<\/a><\/noindex>, che promuove attivamente se stesso su Habr attraverso recensioni di errori trovati dal loro strumento 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

Quando leggi tali recensioni, si ha l'impressione di avere a che fare con una pozione magica: premi un pulsante e voil\u00e0 \u2014 un elenco di difetti davanti ai tuoi occhi. Sembra che con il miglioramento degli analizzatori, verranno trovati automaticamente sempre pi\u00f9 bug, e i prodotti scansionati da questi robot diventeranno sempre migliori, senza alcuno sforzo da parte nostra.<\/p>\n

Ma non esistono elisir magici. Vorrei parlare di ci\u00f2 di cui di solito non si discute nei post del tipo \u00abecco cosa pu\u00f2 trovare il nostro robot\u00bb: cosa non possono fare gli analizzatori, qual \u00e8 il loro ruolo e la loro posizione nel processo di fornitura del software e come implementarli correttamente.<\/p>\n

\"Integra
\nIl riduttore (fonte: wikipedia<\/a><\/noindex>).<\/i>
\n<\/a><\/noindex><\/p>\n

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

\nChe cos'\u00e8, in termini pratici, l'analisi del codice sorgente? Forniamo alcuni sorgenti in input e in breve tempo (molto meno del tempo necessario per eseguire i test) otteniamo alcune informazioni sul nostro sistema. Il vincolo principale e matematicamente ineludibile \u00e8 che possiamo ottenere solo una classe abbastanza ristretta di informazioni in questo modo.<\/p>\n

Il pi\u00f9 famoso esempio di problema non risolvibile tramite analisi statica \u00e8 il problema dell'arresto<\/a><\/noindex>: \u00e8 un teorema che dimostra che non \u00e8 possibile sviluppare un algoritmo generale che, dati il codice sorgente di un programma, possa determinare se 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, definire se un programma arbitrario calcola una funzione con tale propriet\u00e0 \u00e8 un problema algoritmicamente irrisolvibile. Ad esempio, \u00e8 impossibile scrivere un analizzatore che, dato un codice sorgente qualsiasi, possa determinare se il programma analizzato \u00e8 un'implementazione di un algoritmo che calcola, ad esempio, il quadrato di un numero intero.<\/p>\n

Pertanto, la funzionalit\u00e0 degli analizzatori statici ha limiti ineludibili. Un analizzatore statico non potr\u00e0 mai determinare in tutti i casi situazioni come, ad esempio, il verificarsi di un 'null pointer exception' in linguaggi che consentono il valore null, o nei casi in cui si verifica un 'attribute not found' in linguaggi con tipizzazione dinamica. Ci\u00f2 che il pi\u00f9 sofisticato degli analizzatori statici pu\u00f2 fare \u00e8 evidenziare casi particolari, il cui numero rispetto a tutti i possibili problemi con il tuo codice sorgente \u00e8, senza esagerare, una goccia nel mare.<\/p>\n

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

\nDalle informazioni fornite, si pu\u00f2 concludere che l'analisi statica non \u00e8 un mezzo per ridurre il numero di difetti nel software. Mi permetto di affermare che, se applicata per la prima volta al tuo progetto, essa individuer\u00e0 nel codice dei punti \"interessanti\", ma probabilmente non trover\u00e0 difetti che influenzino la qualit\u00e0 del funzionamento del tuo programma.<\/p>\n

Gli esempi di difetti automaticamente trovati dagli analizzatori sono impressionanti, ma non bisogna dimenticare che questi esempi sono stati scoperti tramite la scansione di un ampio set di grandi basi di codice. Allo stesso modo, i ladri informatici, che possono testare diverse semplici password su un gran numero di account, riescono infine a individuare quegli account che utilizzano una password semplice.<\/p>\n

Ci\u00f2 significa che l'analisi statica non deve essere applicata? Certamente no! E per lo stesso motivo per cui \u00e8 utile controllare ogni nuova password contro la lista nera delle \"password semplici\".<\/p>\n

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

\nIn realt\u00e0, le problematiche affrontate dall'analisi statica sono decisamente pi\u00f9 ampie. Infatti, l'analisi statica comprende qualsiasi verifica del codice sorgente effettuata prima della sua esecuzione. Ecco alcune delle operazioni che possono essere svolte:<\/p>\n