Když se už setkáváte s nekonečným code review nebo laděním, občas přemýšlíte, jak si usnadnit život. A po krátkém hledání nebo náhodném narazení můžete narazit na kouzelné spojení: "Statická analýza". Pojďme se podívat na to, co to je a jak může interagovat s vaším projektem.
Pokud píšete v nějakém moderním jazyce, pak si zřejmě ani neuvědomujete, že skrze statického analyzátora procházíte. Fakt je, že každý moderní kompilátor poskytuje alespoň minimální sadu upozornění na potenciální problémy v kódu. Například, při kompilaci C++ kódu ve Visual Studio můžete vidět následující:
V tomto výstupu vidíme, že proměnná var nikde ve funkci nebyla použita. Takže skutečně jste téměř vždy používali jednoduchý nástroj pro statickou analýzu kódu. Nicméně, na rozdíl od profesionálních analyzátorů, jako jsou Coverity, Klocwork nebo PVS-Studio, varování poskytovaná kompilátorem mohou naznačovat pouze malý rozsah problémů.
Pokud přesně nevíte, co je statická analýza a jak ji implementovat, , abyste se podrobněji seznámili s touto metodikou.
Proč je statická analýza potřebná?
Ve zkratce: urychlení a zjednodušení.
Statická analýza umožňuje odhalit spoustu různých problémů v kódu: od nesprávného používání jazykových konstrukcí po překlepy. Například místo
auto x = obj.x;
auto y = obj.y;
auto z = obj.z;jste napsali následující kód:
auto x = obj.x;
auto y = obj.y;
auto z = obj.x;Jak vidíte, v posledním řádku se objevila chyba. Například, PVS-Studio vydává následující varování:
Zvažte přezkoumání správnosti používání položky 'y'.
Pokud chcete experimentovat s touto chybou, zkuste připravený příklad na Compiler Explorer: **.
A jak víte, ne vždy lze okamžitě věnovat pozornost takovým částem kódu, a kvůli tomu se můžete zaseknout v ladění na dobré hodiny, aniž byste chápali, proč to vše funguje tak podivně.
Jedná se však o zjevnou chybu. A co když vývojář napsal neoptimální kód, protože zapomněl na nějakou jemnost jazyka? Nebo dokonce v kódu povolil ? К сожалению, подобные случаи совершенно обыденны и львиная часть времени тратится на то, чтобы отладить специфично работающий код, который содержит опечатки, типичные ошибки или undefined behavior.
Právě pro takové situace vznikla statická analýza. Je to pomocník pro vývojáře, který mu ukáže různé problémy v kódu a vysvětlí v dokumentaci, proč by tak neměl psát, k čemu to může vést a jak to opravit. Tady je příklad, jak to může vypadat: **.
Více zajímavých chyb, které může analyzátor odhalit, najdete v článcích:
Nyní, když jste si přečetli tento materiál a ujistili se o přínosu statické analýzy, mohli byste chtít vyzkoušet ji v praxi. Ale kde začít? Jak integrovat nový nástroj do aktuálního projektu? A jak se s ním seznámit tým? Na tyto otázky naleznete odpovědi níže.
Poznámka. Statická analýza nenahrazuje a neanuluje tak užitečnou věc, jako jsou přehledy kódu. Doplní tento proces a pomůže předem zaznamenat a opravit překlepy, nepřesnosti a nebezpečné konstrukce. Je mnohem produktivnější soustředit se při přehledech kódu na algoritmy a srozumitelnost kódu, než se zabývat hledáním špatně umístěné závorky nebo .
0. Seznámení s nástrojem
Všechno začíná zkušební verzí. Opravu se těžko rozhoduje zavést něco do procesu vývoje, pokud jste nikdy předtím neviděli nástroj naživo. Proto je prvním krokem stáhnout si .
Co se na této fázi dozvíte:
- Jaké jsou způsoby interakce s analyzátorem;
- Je analyzátor kompatibilní s vaším vývojovým prostředím;
- Jaké problémy jsou nyní ve vašich projektech.
Jakmile si nainstalujete vše potřebné, je prvním krokem spustit analýzu celého projektu (, , ). V případě PVS-Studio ve Visual Studio uvidíte podobný obrázek (kliknutelné):
Faktem je, že obvykle na projektech s velkou základnou kódu statické analyzátory generují obrovské množství upozornění. Není potřeba opravovat je všechny, protože váš projekt již funguje, což znamená, že tyto problémy nejsou kritické. Nicméně můžete se podívat na nejzajímavější upozornění. a upravit je podle potřeby. K tomu je třeba filtrovat výstup a ponechat pouze nejspolehlivější oznámení. V pluginu PVS-Studio pro Visual Studio se to provádí filtrováním podle úrovní a kategorií chyb. Pro co nejpřesnější výstup nechte aktivní pouze High a Obecné (také klikatelné):
Opravdu, 178 varování je mnohem snazší prohlédnout než několik tisíc…
V záložkách Medium a Low se často objeví dobrá varování, avšak do těchto kategorií jsou zařazeny diagnostiky, které mají nižší přesnost (spolehlivost). Podrobnosti o úrovních varování a možnostech práce pod Windows si můžete prohlédnout zde: **.
Úspěšně prozkoumat nejzajímavější chyby (a úspěšně je opravit) stojí za to . To je potřeba proto, aby nová varování nezanikla mezi starými. Kromě toho je statický analyzátor pomocníkem pro programátora, nikoli seznamem pro bugy. 🙂
1. Automatizace
Po seznámení nastává čas na nastavení pluginů a integraci do CI. Je třeba to udělat dříve, než programátoři začnou používat statický analyzátor. Faktem je, že programátor může zapomenout zapnout analýzu nebo ji vůbec nechtít. K tomu je potřeba provést určitou konečnou kontrolu, aby nezkontrolovaný kód nemohl proniknout do hlavní vývojové větve.
Co se na této fázi dozvíte:
- Jaké možnosti automatizace nástroj nabízí;
- Je analyzátor kompatibilní s vaším systémem sestavení.
Jelikož neexistuje ideální dokumentace, někdy je třeba napsat na . Je to normální a rádi vám pomůžeme. 🙂
A nyní přejdeme k službám nepřetržité integrace (CI). Jakýkoli analyzátor lze do nich bez vážných problémů implementovat. K tomu je potřeba vytvořit samostatný krok v pipeline, který se obvykle nachází po sestavení a unit testech. Dělá se to pomocí různých konzolových utilit. Například PVS-Studio poskytuje následující utility:
- (analýza řešení, C#, C++ projektů na Windows)
- (monitorování kompilace)
- (analýza C++ projektů na Linux / macOS)
- (analýza řešení, C# projektů na Linux / macOS)
- (analýza Java projektů)
- (konvertor souborů zprávy)
Pro integraci analýzy do CI je třeba udělat tři věci:
- Nainstalovat analyzátor;
- Spustit analýzu;
- Dodat výsledky.
Například pro instalaci PVS-Studio na Linux (Debian-based) je třeba provést následující příkazy:
wget -q -O - https://files.viva64.com/etc/pubkey.txt
| sudo apt-key add -
sudo wget -O /etc/apt/sources.list.d/viva64.list
https://files.viva64.com/etc/viva64.list
sudo apt-get update -qq
sudo apt-get install -qq pvs-studioV systémech řízených Windows není možné nainstalovat analyzátor pomocí správce balíčků, ale lze rozbalit analyzátor z příkazového řádku:
PVS-Studio_setup.exe /verysilent /suppressmsgboxes
/norestart /nocloseapplicationsVíce o nasazení PVS-Studio v systémech řízených Windows si můžete přečíst **.
Po instalaci je třeba spustit samotnou analýzu. Nicméně doporučuje se to provést až po kompilaci a testech. To je dáno tím, že pro statickou analýzu obvykle potřebujete dvakrát více času než pro kompilaci.
Jelikož způsob spuštění závisí na platformě a charakteristikách projektu, ukážu variantu pro C++ (Linux) jako příklad:
pvs-studio-analyzer analyze -j8
-o PVS-Studio.log
plog-converter -t errorfile PVS-Studio.log --cerr -wPrvní příkaz provede analýzu a druhý report do textového formátu, zobrazí ho na obrazovce a vrátí nenulový návratový kód v případě, že existují varování. Takový mechanismus je pohodlné používat k zablokování sestavení v případě, že existují zprávy o chybách. Nicméně můžete vždy odstranit příznak -w a nezablokovat sestavení obsahující varování.
Poznámka. Textový formát – to není pohodlné. Je uveden pouze jako příklad. Všimněte si zajímavějšího formátu zprávy – FullHtml. Umožňuje provádět navigaci po kódu.
Více o nastavení analýzy na CI si můžete přečíst v článku "" (Windows) nebo "" (Linux).
Dobře, nastavili jste práci analyzátoru na sestavovacím serveru. Nyní, pokud někdo nahrál neověřený kód, bude selhávat fáze kontroly a vy odhalíte problém, ale není to zcela pohodlné, protože efektivnější je kontrolovat projekt před tím, než dojde k sloučení větví, a to na fázi pull requestu.
Celkově se nastavení analýzy pull requestu neliší příliš od běžného spuštění analýzy na CI. S výjimkou potřeby získat seznam změněných souborů. Obvykle je možné je získat požádáním o rozdíl mezi větvemi pomocí git:
git diff --name-only HEAD origin/$MERGE_BASE > .pvs-pr.listNyní je třeba předat analyzátoru tento seznam souborů. Například v PVS-Studio je to realizováno pomocí příznaku. -S:
pvs-studio-analyzer analyze -j8
-o PVS-Studio.log
-S .pvs-pr.listO analýze pull requestů se můžete dozvědět **. I když váš CI není v seznamu uvedených služeb, bude pro vás užitečná obecná část věnovaná teorii tohoto typu analýzy.
Nastavením analýzy pull requestů můžete blokovat commity obsahující upozornění, čímž vytvoříte hranici, kterou nepřezkoumaný kód nemůže překročit.
To všechno je jistě dobré, ale rád bych měl možnost vidět všechna upozornění na jednom místě. Nejen z statického analyzátoru, ale i z unit testů nebo z dynamického analyzátoru. K tomu existují různé služby a pluginy. PVS-Studio například má .
2. Integrace na stroje vývojářů
Nyní je čas nainstalovat a nakonfigurovat analyzátor pro každodenní použití při vývoji. V tomto okamžiku jste se už seznámili s většinou způsobů práce, takže to můžeme nazvat tou nejjednodušší částí.
Nejjednodušší možností je, že si vývojáři mohou nainstalovat potřebný analyzátor sami. To však zabere hodně času a odvede je to od vývoje, proto můžete tento proces automatizovat pomocí instalátoru a potřebných příznaků. Pro PVS-Studio existují různé . Nicméně existují vždy balíčkové manažery, například Chocolatey (Windows), Homebrew (macOS) nebo desítky variant pro Linux.
Poté je potřeba nainstalovat potřebné pluginy, například pro , , atd.
3. Každodenní používání
V této fázi je na čase říct pár slov o způsobech, jak urychlit práci analyzátoru při každodenním používání. Kompletní analýza celého projektu zabere hodně času, ale jak často měníme kód najednou v celém projektu? Obtížně existuje tak rozsáhlá refaktorizace, která by najednou zasáhla celou kódovou základnu. Počet měněných souborů najednou zřídka přesáhne deset, takže je smysluplné je analyzovat. Pro takovou situaci existuje . Jen se nelekejte, to není další nástroj. Je to speciální režim, který umožňuje analyzovat pouze změněné soubory a jejich závislosti, a to automaticky po sestavení, pokud pracujete v IDE s nainstalovaným pluginem.
Pokud analyzátor objeví problémy v nedávno změněném kódu, upozorní vás na to sám. Například PVS-Studio vám o tom dá vědět pomocí upozornění:
Samozřejmě nestačí říct vývojářům, aby nástroj používali. Je třeba jim nějak vysvětlit, co to vlastně je a jak to funguje. Například zde jsou články o rychlém startu pro PVS-Studio, ale podobné tutoriály naleznete pro jakýkoli vámi preferovaný nástroj:
Podobné články poskytují vše potřebné informace pro každodenní používání a nezabírají příliš času. 🙂
Už při seznamování se s nástrojem jsme potlačili spoustu upozornění během jednoho z prvních spuštění. Bohužel, statické analyzátory nejsou dokonalé, a proto občas dávají falešné alarmy. Obvykle je snadné je potlačit, například v pluginu PVS-Studio pro Visual Studio stačí stisknout jedno tlačítko:
Ale můžete je nejen potlačovat. Například můžete podmínit podporu o přítomnosti problému. Pokud falešný alarm lze opravit, pak ve budoucích aktualizacích můžete zaznamenat, že se s každým dalším spuštěním stává stále méně a méně specifických falešných alarmů pro vaši kódovou základnu.
Po integraci
A jsme na konci všech etap integrace statické analýzy do vývojového procesu. Navzdory důležitosti nastavení takových nástrojů v CI, hlavním místem spuštění je počítač vývojáře. Koneckonců, statický analyzátor není soudce, který kdesi daleko říká, že kód nikam nepatří. Naopak, je to asistent, který vám naznačuje, pokud jste unavení, a připomíná, pokud na něco zapomenete.
Pravda, bez pravidelného používání, statická analýza pravděpodobně významně neulehčí vývoj. Vždyť její největší výhoda pro vývojáře spočívá nejen v hledání složitých a sporných částí kódu, ale také v jejich včasném odhalení. Souhlasíte, že zjistit problém, když opravy už byly odeslány na testování, není jen nepříjemné, ale také velmi zdlouhavé. Statická analýza však při pravidelném používání kontroluje každou změnu přímo na vašem počítači a informuje vás o podezřelých místech během práce na kódu.
A pokud vy nebo vaši kolegové stále nejste jisti, zda zavést analyzátor, doporučuji nyní přejít k přečtení článku "". V něm se řeší běžné obavy vývojářů, že statická analýza jim vezme čas a podobně.
Pokud chcete sdílet tento článek s anglicky mluvícím publikem, prosím použijte odkaz na překlad: Maxim Zvyagintsev. .
Zdroj: habr.com
