Az állandó code review vagy hibakeresés közepette néha elgondolkodsz, hogyan könnyíthetnéd meg az életed. Kicsit keresgélve, vagy véletlenül rábukkanva találkozhatsz a varázslatos kifejezéssel: "Statikus elemzés". Nézzük meg, mi is ez és hogyan tud kapcsolódni a projektedhez.
Valójában, ha bármilyen modern nyelven írsz, akkor, talán észrevétlenül, átengeded azt egy statikus elemzőn. Az a helyzet, hogy minden modern fordító szolgáltat, még ha apró is, de egy sor figyelmeztetést a potenciális problémákról a kódban. Például, amikor C++ kódot fordítasz a Visual Studio-ban, a következőket láthatod:
Ebben a kimenetben látjuk, hogy a változó var sehol nem volt felhasználva a függvényben. Tehát igazából szinte mindig használtál egy egyszerű statikus kódellenőrzőt. Azonban ellentétben a professzionális elemzőkkel, mint a Coverity, Klocwork vagy PVS-Studio, a fordító által megadott figyelmeztetések csak egy szűk spektrumú problémát jeleznek.
Ha nem tudod pontosan, mi az a statikus elemzés és hogyan kell alkalmazni, , hogy részletesebben megismerkedhess ezzel a módszertannal.
Miért van szükség statikus elemzésre?
Röviden: gyorsítás és egyszerűsítés.
A statikus elemzés számos különböző problémát talál a kódban: a nyelvi konstrukciók helytelen használatától kezdve, egészen a gépelési hibákig. Például, ahelyett, hogy
auto x = obj.x;
auto y = obj.y;
auto z = obj.z;A következő kódot írtad:
auto x = obj.x;
auto y = obj.y;
auto z = obj.x;Ahogy látod, az utolsó sorban hiba keletkezett. Például a PVS-Studio a következő figyelmeztetést adja:
Fontold meg 'y' elem használatának helyességét.
Ha szeretnéd kézzel is kipróbálni ezt a hibát, akkor próbáld ki a kész példát a Compiler Explorer-en: **.
És ahogy megérted, nem mindig figyelünk az ilyen kódrészekre azonnal, és emiatt órákig elakadhatunk a hibakeresésben, azon töprengve, miért működik minden olyan furcsán.
Ez azonban egy nyilvánvaló hiba. Mi van, ha a fejlesztő nem optimális kódot írt, mert elfelejtett egy nyelvi finomságot? Vagy még inkább, ha a kódban ? К сожалению, подобные случаи совершенно обыденны и львиная часть времени тратится на то, чтобы отладить специфично работающий код, который содержит опечатки, типичные ошибки или undefined behavior.
Kifejezetten ezekre a helyzetekre jött létre a statikus elemzés. Ez a fejlesztők segítője, amely rámutat különböző kódproblémákra, és elmagyarázza a dokumentációban, miért nem így kellene írni, miért vezethet ez problémákhoz, és hogyan lehet ezeket megjavítani. Íme egy példa, hogy ez hogyan nézhet ki: **.
További érdekes hibák, amelyeket az elemző felfedezhet, megtalálhatók a cikkekben:
Most, hogy elolvastad ezt az anyagot, és megbizonyosodtál a statikus elemzés előnyeiről, lehet, hogy szeretnéd kipróbálni a gyakorlatban. De hol is kezdj? Hogyan integrálj egy új eszközt a meglévő projektbe? És hogyan ismertessük meg a csapattal? Ezekre a kérdésekre lent találod a válaszokat.
Megjegyzés. A statikus elemzés nem helyettesíti és nem törli el azt a hasznos dolgot, mint a kódellenőrzések. Kiegészíti ezt a folyamatot, segítve előre észlelni és kijavítani a nyomdai hibákat, pontatlanságokat és férfias szerkezeteket. Sokkal produktívabb a kódellenőrzéseknél a algoritmusokra és a kód érthetőségére összpontosítani, nem pedig a rosszul elhelyezett zárójelek vagy .
0. Az eszközzel való ismerkedés
Minden a próbaverzióval kezdődik. Valóban nehéz bármit is integrálni a fejlesztési folyamatba, ha még soha nem láttál egy eszközt élőben. Ezért először le kell töltened .
Mit fogsz megtudni ezen a lépésen:
- Milyen módon lehet interakcióba lépni az elemzővel;
- Kompatibilis-e az elemző a fejlesztési környezeteddel;
- Milyen problémák találhatók jelenleg a projektjeidben.
Miután mindent telepítettél, az első lépés a teljes projekt elemzésének elindítása (, , ). A PVS-Studio esetében a Visual Studio-ban hasonló képet fogsz látni (kattintható):
A helyzet az, hogy általában a nagy kódalapú projektek statikus elemzője hatalmas mennyiségű figyelmeztetést ad ki. Nincs szükség az összes javítására, mivel a projekted már működik, így ezek a problémák nem kritikusak. Azonban te és szükség esetén javítani azokat. Ehhez szűrni kell a kimenetet, és csak a legmegbízhatóbb üzeneteket kell hagyni. A PVS-Studio plugin a Visual Studio számára ezt a hibák szintjei és kategóriái szerint történő szűréssel végzi. A legpontosabb kimenet érdekében csak azokat hagyja bekapcsolva, amelyek Magas és Általános (ez is kattintható):
Valóban, 178 figyelmeztetést sokkal egyszerűbb átnézni, mint több ezer…
A lapokon Közepes és Alacsony gyakran előfordulnak jó figyelmeztetések, azonban ezekbe a kategóriákba azok a diagnózisok kerülnek, amelyeknek kisebb a pontossága (megbízhatósága). A figyelmeztetések szintjeiről és a Windows alatt való munkavégzés lehetőségeiről itt olvashat bővebben: **.
Sikeresen átnézve a legérdekesebb hibákat (és sikeresen javítva azokat) érdemes . Ezt azért szükséges megtenni, hogy az új figyelmeztetések ne veszjenek el a régiek között. Ezenkívül a statikus elemző a programozók segítője, nem pedig egy hiba lista. 🙂
1. Automatizálás
A megismerkedés után elérkezik az ideje a pluginok beállításának és az CI-vel való integrációnak. Ezt meg kell tenni, mielőtt a programozók elkezdenék használni a statikus elemzőt. A probléma az, hogy a programozó elfelejtheti bekapcsolni az elemzést, vagy akár meg sem akarja tenni. Ehhez egy végső ellenőrzést kell végezni annak érdekében, hogy a nem ellenőrzött kód ne kerüljön a közös fejlesztési ágba.
Mit fog megtudni ezen a ponton:
- Milyen automatizálási lehetőségeket kínál az eszköz;
- Összeegyeztethető-e az elemző az Ön build rendszerével.
Mivel tökéletes dokumentáció nem létezik, néha írni kell a . Ez normális, és örömmel segítünk Önnek. 🙂
Most pedig lépjünk át a folyamatos integrációs (CI) szolgáltatásokra. Bármely elemzőt problémamentesen be lehet építeni ezekbe. Ehhez külön lépést kell létrehozni a pipeline-ban, amely általában a build és az egységtesztelés után helyezkedik el. Ezt különféle parancssori segédprogramok segítségével végezzük. Például a PVS-Studio a következő segédprogramokat nyújtja:
- (megoldások, C#, C++ projektek analízise Windows-on)
- (fordítás figyelése)
- (C++ projektek elemzése Linux-on / macOS-on)
- (megoldások, C# projektek elemzése Linux-on / macOS-on)
- (Java projektek elemzése)
- (jelentés fájlok konvertere)
Az elemző CI-be való integrálásához három dolgot kell elvégezni:
- Telepíteni az elemzőt;
- Futtatni az elemzést;
- Szállítsa le az eredményeket.
Például a PVS-Studio Linux (Debian alapú) telepítéséhez a következő parancsokat kell végrehajtani:
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-studioWindows rendszerű gépeken nincs lehetőség a csomagkezelőből telepíteni az elemzőt, de van lehetőség az elemző parancssorból történő telepítésére:
PVS-Studio_setup.exe /verysilent /suppressmsgboxes
/norestart /nocloseapplicationsTovábbi információk a PVS-Studio Windows rendszereken történő telepítéséről **.
A telepítés után közvetlenül el kell indítani az elemzést. Azonban ezt ajánlott csak azután megtenni, miután a fordítás és a tesztek befejeződtek. Ennek oka, hogy a statikus elemzés általában a fordítás időtartamának kétszeresét igényli.
Mivel az indítás módja a platformtól és a projekt jellemzőitől függ, bemutatok egy példát a C++ (Linux) esetében:
pvs-studio-analyzer analyze -j8
-o PVS-Studio.log
plog-converter -t errorfile PVS-Studio.log --cerr -wAz első parancs végrehajtja az elemzést, a második pedig az eredményt szöveges formátumban kiírja a képernyőre, és ha figyelmeztetések vannak, nem 0 visszatérési kódot ad. Ez a mechanizmus kényelmesen használható a hibák megjelenésekor a fordítás blokkolására. Azonban mindig eltávolíthatja a jelzőt, -w és nem blokkolja a fordítást figyelmeztetésekkel.
Megjegyzés. A szöveges formátum nem kényelmes. Csak példa kedvéért hoztuk fel. Figyeljen a jelentés egy érdekesebb formátumára — FullHtml. Ez lehetővé teszi a kódon való navigálást.
További információk az elemzés CI-ra történő beállításáról olvashatók a "" (Windows) vagy "" (Linux).
Rendben van, beállította az elemzőt az építési szerveren. Most, ha valaki feltöltött ellenőrizetlen kódot, a felülvizsgálati rész megbukik, és Ön képes lesz észlelni a problémát, de ez nem túl kényelmes, mivel hatékonyabb a projektet azelőtt ellenőrizni, mielőtt a szálak összeérnének, nem pedig utána, a pull request szakaszában.
Általánosságban a pull request elemzésének beállítása nem különbözik túl sokban a szokásos CI elemzési indítástól. Az egyetlen különbség az, hogy meg kell szereznie a módosított fájlok listáját. Ezt általában a git segítségével lehet meglátogatni, ahol kérheti a szálak közötti különbségeket:
git diff --name-only HEAD origin/$MERGE_BASE > .pvs-pr.listMost már át kell adni az elemzőnek ezt a fájllistát. Például a PVS-Studio ezt egy kapcsoló segítségével valósítja meg. -S:
pvs-studio-analyzer analyze -j8
-o PVS-Studio.log
-S .pvs-pr.listTovábbi információkat a pull requestek elemzéséről **. Még ha a CI rendszered nincs is a cikkben említett szolgáltatások listáján, az általános szakasz hasznos lesz számodra, amely ezzel a típusú elemzéssel foglalkozik.
A pull requestek elemzésének beállításával blokkolhatod a figyelmeztetéseket tartalmazó commitokat, ezáltal létrehozva egy határt, amit a nem ellenőrzött kód nem léphet át.
Ez mind kétségtelenül jó, de szeretném, ha lenne lehetőségem az összes figyelmeztetést egyhelyütt megnézni. Nemcsak a statikus elemzőtől, hanem a unit tesztektől vagy a dinamikus elemzőtől is. Erre különböző szolgáltatások és bővítmények állnak rendelkezésre. Például a PVS-Studio rendelkezik .
2. Integráció a fejlesztők gépein
Most eljött az idő, hogy telepítsd és beállítsd az elemzőt a napi használatra a fejlesztés során. Eddig már megismerkedtél a munkamódszerekkel, ezért ezt nevezhetjük a legkönnyebb résznek.
A legegyszerűbb lehetőség, hogy a fejlesztők maguk telepíthessék a szükséges elemzőt. Ez azonban sok időt igényel, és eltereli őket a fejlesztéstől, ezért automatizálhatod ezt a folyamatot, egy telepítő és a szükséges kapcsolók segítségével. A PVS-Studio-hoz különféle . Mindazonáltal mindig rendelkezésre állnak csomagkezelők, például a Chocolatey (Windows), a Homebrew (macOS) vagy tucatnyi lehetőség Linuxra.
Ezután telepíteni kell a szükséges bővítményeket, például a , , stb.
3. Napi használat
Ezen a ponton érdemes néhány szót szólni az elemző munkájának felgyorsítási módszereiről a napi használat során. A projekt teljes elemzése nagyon sok időt vesz igénybe, de gyakran változtatunk a kódon az egész projektben? Aligha létezik ekkora terjedelmű refaktorálás, ami azonnal érintené az egész kódalapját. Az egyszerre módosított fájlok száma ritkán haladja meg a tucatot, ezért csak ezeket érdemes elemezni. Ilyen helyzetre van . Csak ne riadjon meg, ez nem egy újabb eszköz. Ez egy speciális mód, amely lehetővé teszi a módosított fájlok és azok függőségeinek automatikus elemzését build után, ha IDE-t használ pluginnal.
Ha az elemző problémákat talál a nemrégiben módosított kódban, azt önállóan jelzi. Például a PVS-Studio értesítést küld erről:
Nyilvánvaló, hogy nem elegendő azt mondani a fejlesztőknek, hogy használjanak eszközt. Valahogy el kell mondani nekik, hogy mi ez és hogyan működik. Például itt van egy gyors kezdési útmutató a PVS-Studio-hoz, de hasonló oktatóanyagokat találhat bármely általa preferált eszközhöz:
Az ilyen cikkek minden szükséges információt megadnak a napi használathoz, és nem vesznek el sok időt. 🙂
Még az eszközzel való ismerkedés fázisában is sok figyelmeztetést elnyomtunk az első indítások során. Sajnos a statikus elemzők nem tökéletesek, ezért időnként hamis riasztásokat adnak. Ezeket általában könnyű elnyomni, például a Visual Studio PVS-Studio pluginjában elegendő egy gombot megnyomni:
De nem csak elnyomni lehet őket. Például jelezheti a támogatásnak, hogy problémát észlelt. Ha a hamis riasztás javítható, a jövőbeli frissítések során egyre kevesebb, a kódalapodra jellemző hamis riasztásra lehet figyelmes.
Az integráció után
Így végigmentünk a statikus elemzés integrálásának minden lépésén a fejlesztési folyamatba. Bár az ilyen eszközök CI-n történő beállítása kulcsfontosságú, a legfontosabb indítási hely a fejlesztő számítógépe. A statikus elemző nem egy bíró, aki távolról mondja meg, hogy a kód nem megfelelő. Ellenkezőleg, ez egy segítő, aki utal, ha fáradt vagy, és emlékeztet, ha valamire elfeledkeztél.
Az igazság az, hogy a statikus elemzés rendszeres használata nélkül valószínűleg nem egyszerűsíti le a fejlesztést. A legfőbb előnye a fejlesztők számára nem annyira a bonyolult és vitatható kódrészek keresésében rejlik, hanem a korai észlelésükben. Gondolja el, milyen kellemetlen, amikor egy probléma derül ki, miután a módosítások már tesztelésre kerültek, és mennyire időigényes ez. A statikus elemzés viszont rendszeres használat mellett minden egyes módosítást átnéz a számítógépén, és jelzi a gyanús részeket a kódolás során.
Ha Ön vagy kollégái még mindig nem biztosak abban, hogy érdemes-e bevezetni az elemzőt, javaslom, hogy most olvassák el a cikket "". Ebben a cikkben a fejlesztők tipikus aggályait tárgyaljuk, miszerint a statikus elemzés időt fog elvenni tőlük és így tovább.
Ha meg szeretné osztani ezt a cikket angol nyelvű közönséggel, kérem, használja a fordítás linkjét: Maxim Zvyagintsev. .
Forrás: habr.com
