Belefáradt a végtelen kódellenőrzésbe vagy hibakeresésbe, és néha azon gondolkodik, hogyan lehetne egyszerűbbé tenni életét. Kis keresgélés után, vagy véletlenül rábukkanva pedig a bűvös mondatot láthatjuk: „Statikus elemzés”. Lássuk, mi ez, és hogyan tud kölcsönhatásba lépni a projekttel.
Valójában, ha bármilyen modern nyelven ír, akkor anélkül, hogy észrevette volna, átfuttatta egy statikus elemzőn. A tény az, hogy minden modern fordító, bár egy apró, figyelmeztetést biztosít a kód lehetséges problémáira. Például, amikor C++ kódot fordít a Visual Studio programban, a következőket láthatja:
Ebben a kimenetben azt látjuk, hogy a változó volt soha nem használták a funkcióban. Tehát a valóságban szinte mindig egy egyszerű statikus kódelemzőt használt. Azonban a professzionális elemzőkkel, mint például a Coverity, a Klocwork vagy a PVS-Studio eltérően a fordító által adott figyelmeztetések csak a problémák egy kis körét jelezhetik.
Ha nem tudja biztosan, mi az a statikus elemzés, és hogyan kell végrehajtani, hogy többet megtudjon erről a módszertanról.
Miért van szükség statikus elemzésre?
Dióhéjban: gyorsítás és egyszerűsítés.
A statikus elemzés lehetővé teszi, hogy sok különböző problémát találjon a kódban: a nyelvi konstrukciók helytelen használatától a gépelési hibákig. Például ahelyett
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;Mint látható, az utolsó sorban elírás van. Például a PVS-Studio a következő figyelmeztetést adja ki:
Fontolja meg az „y” elem használatának helyességét.
Ha bele akarja szúrni a kezét ebbe a hibába, próbáljon ki egy kész példát a Compiler Explorerben: **.
És amint érti, nem mindig lehet azonnal odafigyelni az ilyen kódrészletekre, és emiatt le lehet ülni hibakeresni egy jó órára, hogy vajon miért működik minden olyan furcsán.
Ez azonban egyértelműen tévedés. Mi van, ha a fejlesztő szuboptimális kódot írt, mert elfelejtette a nyelv bizonyos finomságait? Vagy akár a kódban is engedélyezte ? Sajnos az ilyen esetek teljesen mindennaposak, és az idő oroszlánrészét kifejezetten működő kódok hibakeresésével töltik, amelyek elírásokat, tipikus hibákat vagy meghatározatlan viselkedést tartalmaznak.
Ezekre a helyzetekre jelent meg a statikus elemzés. Ez egy asszisztens a fejlesztő számára, aki rámutat a kód különböző problémáira, és elmagyarázza a dokumentációban, hogy miért nem szükséges így írni, mihez vezethet és hogyan lehet javítani. Íme egy példa, hogyan nézhet ki: **.
További érdekes hibákat találhat, amelyeket az analizátor észlelhet a cikkekben:
Most, hogy elolvasta ezt az anyagot, és meggyőződött a statikus elemzés előnyeiről, érdemes lehet kipróbálnia. De hol kezdjem? Hogyan építs be egy új eszközt a jelenlegi projektedbe? És hogyan kell bemutatni neki a csapatot? Az alábbiakban ezekre a kérdésekre talál választ.
Megjegyzés. A statikus elemzés nem helyettesíti vagy semmisíti meg az olyan hasznos dolgokat, mint a kódellenőrzés. Kiegészíti ezt a folyamatot, segít előre észrevenni és kijavítani a gépelési hibákat, pontatlanságokat és veszélyes terveket. Sokkal produktívabb az algoritmusokra és a kód tisztaságára vonatkozó kódellenőrzésekre összpontosítani, ahelyett, hogy egy rossz helyen lévő zárójelet vagy .
0. Az eszköz megismerése
Minden egy próbaverzióval kezdődik. Valójában nehéz eldönteni, hogy bevisz-e valamit a fejlesztési folyamatba, ha még soha nem láttad élőben az eszközt. Ezért az első dolog, amit meg kell tennie, a letöltés .
Amit ebben a szakaszban megtanulsz:
- Milyen módokon léphet kapcsolatba az analizátorral;
- Kompatibilis az analizátor az Ön fejlesztői környezetével?
- Milyen problémák vannak jelenleg a projektjei során?
Miután mindent telepített, amire szüksége van, először futtassa le a teljes projekt elemzését (, , ). A Visual Studio PVS-Studio esetében hasonló képet fog látni (kattintható):
A tény az, hogy a statikus elemzők általában rengeteg figyelmeztetést adnak ki a nagy kódbázisú projekteknél. Nem kell mindegyiket kijavítani, mivel a projekt már működik, ami azt jelenti, hogy ezek a problémák nem kritikusak. Ön azonban és szükség esetén javítsa ki őket. Ehhez szűrnie kell a kimenetet, és csak a legmegbízhatóbb üzeneteket kell hagynia. A Visual Studio PVS-Studio beépülő moduljában ez hibaszintek és kategóriák szerinti szűréssel történik. A legpontosabb kimenet érdekében hagyja csak Magas и általános (kattintható is):
Valóban, 178 figyelmeztetés sokkal könnyebben látható, mint több ezer...
A lapokon közepes и Elő/Utó Gyakran vannak jó figyelmeztetések, de ezek a kategóriák magukban foglalják azokat a diagnosztikát, amelyeknek kisebb a pontossága (megbízhatósága). További információ a figyelmeztetési szintekről és a Windows alatti munkavégzés lehetőségeiről itt található: **.
A legérdekesebb hibákat sikeresen átnézni (és sikeresen kijavítani) érdemes . Erre azért van szükség, hogy az új figyelmeztetések ne vesszenek el a régiek között. Ezenkívül a statikus elemző a programozó asszisztense, nem pedig a hibák listája. 🙂
1. Automatizálás
Az ismerkedés után itt az ideje a bővítmények konfigurálásának és a CI-be való integrálásának. Ezt meg kell tenni, mielőtt a programozók elkezdik használni a statikus analizátort. Az a tény, hogy a programozó elfelejtheti engedélyezni az elemzést, vagy egyáltalán nem akarja megtenni. Ehhez mindent el kell végezni egy végső ellenőrzésen, hogy a teszteletlen kód ne kerülhessen az általános fejlesztési ágba.
Amit ebben a szakaszban megtanulsz:
- Milyen automatizálási lehetőségeket kínál az eszköz;
- Kompatibilis az analizátor az Ön összeszerelési rendszerével?
Mivel tökéletes dokumentáció nem létezik, néha be kell írni . Ez normális, és szívesen segítünk Önnek. 🙂
Most térjünk át a folyamatos integrációs (CI) szolgáltatásokra. Bármilyen analizátor beépíthető beléjük komolyabb probléma nélkül. Ehhez létre kell hozni egy külön szakaszt a folyamatban, amely általában az építési és az egységtesztek után található. Ez különféle konzol segédprogramokkal történik. Például a PVS-Studio a következő segédprogramokat biztosítja:
- (megoldások elemzése, C#, C++ projektek Windowson)
- (összeállítás figyelése)
- (C++ projektek elemzése Linux / macOS rendszeren)
- (megoldáselemzés, C# projektek Linuxon / macOS-en)
- (Java projektek elemzése)
- (jelentésfájl konvertáló)
Az elemzés CI-be való integrálásához három dolgot kell tennie:
- Telepítse az analizátort;
- Elemzés futtatása;
- Eredmények kézbesítése.
Például a PVS-Studio telepítéséhez Linuxra (Debian-base), a következő parancsokat kell futtatnia:
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-studioWindowst futtató rendszereken nincs lehetőség az elemző telepítésére a csomagkezelőből, de lehetőség van az elemző telepítésére a parancssorból:
PVS-Studio_setup.exe /verysilent /suppressmsgboxes
/norestart /nocloseapplicationsTovábbi információ a PVS-Studio telepítéséről Windows rendszeren **.
A telepítés után közvetlenül kell futtatnia az elemzést. Ezt azonban csak az összeállítás és a tesztek sikeres elvégzése után javasoljuk megtenni. Ennek az az oka, hogy a statikus elemzés általában kétszer annyi ideig tart, mint a fordítás.
Mivel az indítási mód a platformtól és a projekt jellemzőitől függ, példaként bemutatom a C++ (Linux) opciót:
pvs-studio-analyzer analyze -j8
-o PVS-Studio.log
plog-converter -t errorfile PVS-Studio.log --cerr -wAz első parancs elvégzi az elemzést, a második pedig szöveges formátumba konvertálja a jelentést, megjeleníti a képernyőn, és figyelmeztetések esetén 0-tól eltérő visszatérési kódot ad vissza. Egy ilyen mechanizmus kényelmesen használható a build blokkolására, ha hibaüzenetek jelennek meg. A zászlót azonban bármikor eltávolíthatja -w és ne blokkoljon olyan szerelvényt, amely figyelmeztetéseket tartalmaz.
Megjegyzés. A szöveg formátuma kényelmetlen. Egyszerűen példaként szolgál. Ügyeljen egy érdekesebb jelentésformátumra - FullHtml. Lehetővé teszi a kódban való navigálást.
A CI elemzés beállításáról a következő cikkben olvashat bővebben" (Windows) vagy "" (Linux).
Rendben, beállította az elemzőt a build szerveren. Most, ha valaki nem tesztelt kódot töltött fel, az ellenőrzési szakasz meghiúsul, és Ön képes lesz észlelni a problémát, azonban ez nem teljesen kényelmes, mivel hatékonyabb a projekt ellenőrzése nem az ágak összevonása után, hanem előtte, a lehívási kérelem szakaszában. A.
Általánosságban elmondható, hogy a lekérési kérés elemzésének beállítása nem sokban különbözik a CI-n végzett elemzés szokásos elindításától. Kivéve a módosított fájlok listájának beszerzését. Ezeket általában úgy kaphatjuk meg, hogy a git segítségével lekérdezzük az ágak közötti különbségeket:
git diff --name-only HEAD origin/$MERGE_BASE > .pvs-pr.listMost át kell adnia ezt a fájllistát az analizátornak bemenetként. Például a PVS-Studio-ban ez a jelzővel van megvalósítva -S:
pvs-studio-analyzer analyze -j8
-o PVS-Studio.log
-S .pvs-pr.listTovábbi információ a lehívási kérelmek elemzéséről **. Még ha CI nem is szerepel a cikkben említett szolgáltatások listáján, hasznosnak találja az ilyen típusú elemzés elméletével foglalkozó általános részt.
A lekérési kérelmek elemzésének beállításával blokkolhatja a figyelmeztetéseket tartalmazó véglegesítéseket, ezáltal létrehozva egy olyan határt, amelyet a teszteletlen kód nem léphet át.
Ez minden bizonnyal jó, de szeretném, ha az összes figyelmeztetést egy helyen láthatnám. Nem csak a statikus analizátorból, hanem az egységtesztekből vagy a dinamikus analizátorból is. Ehhez különféle szolgáltatások és bővítmények állnak rendelkezésre. A PVS-Studio például rendelkezik .
2. Integráció fejlesztőgépeken
Most itt az ideje telepíteni és konfigurálni az analizátort a mindennapi fejlesztési használatra. Ezen a ponton már megismerte a legtöbb munkamódszert, így ezt nevezhetjük a legegyszerűbb résznek.
A legegyszerűbb lehetőségként a fejlesztők maguk telepíthetik a szükséges elemzőt. Ez azonban sok időt vesz igénybe, és elvonja a figyelmüket a fejlesztésről, így ezt a folyamatot automatizálhatja egy telepítő és a szükséges jelzők segítségével. A PVS-Studio számára többféle . Azonban mindig vannak csomagkezelők, például a Chocolatey (Windows), a Homebrew (macOS) vagy több tucat lehetőség Linuxhoz.
Ezután telepítenie kell a szükséges bővítményeket, például a , , elvisszük helyi falvakba ahol megismerkedhet az őslakosok kultúrájával; ...
3. Napi használat
Ebben a szakaszban ideje néhány szót ejteni arról, hogyan lehet felgyorsítani az analizátort a napi használat során. A teljes projekt teljes elemzése sok időt vesz igénybe, de milyen gyakran változtatunk kódot egyszerre a teljes projektben? Alig van olyan nagy átdolgozás, amely azonnal kihat a teljes kódbázisra. Az egyszerre módosítandó fájlok száma ritkán haladja meg a tucatot, ezért érdemes ezeket elemezni. Egy ilyen helyzetre van . Csak ne ijedjen meg, ez nem egy másik eszköz. Ez egy speciális mód, amely lehetővé teszi, hogy csak a megváltozott fájlokat és azok függőségeit elemezze, és ez automatikusan megtörténik a felépítés után, ha IDE-ben dolgozik a telepített bővítménnyel.
Ha az analizátor problémákat észlel a nemrégiben módosított kódban, akkor ezt függetlenül jelenti. Például a PVS-Studio egy riasztással tájékoztatja Önt erről:
Természetesen nem elég, ha a fejlesztőket felszólítjuk az eszköz használatára. Valahogy el kell mondanunk nekik, hogy mi ez és hogyan. Íme például cikkek a PVS-Studio gyors indulásáról, de hasonló oktatóanyagokat találhat minden olyan eszközhöz, amelyet kedvel:
Az ilyen cikkek minden szükséges információt megadnak a mindennapi használathoz, és nem igényelnek sok időt. 🙂
Már az eszköz megismerésének szakaszában is sok figyelmeztetést elnyomtunk az egyik első indításkor. Sajnos a statikus analizátorok nem tökéletesek, ezért időről időre hamis pozitív eredményeket adnak. Általában könnyű elnyomni őket; például a Visual Studio PVS-Studio beépülő moduljában csak egy gombra kell kattintania:
Azonban többet tehet, mint hogy elnyomja őket. Például jelentheti a problémát az ügyfélszolgálatnak. Ha a hamis pozitív kijavítható, akkor a jövőbeli frissítések során észreveheti, hogy minden alkalommal egyre kevesebb a kódbázisra jellemző téves pozitív.
Az integráció után
Így a statikus elemzés fejlesztési folyamatba való integrálásának minden szakaszán keresztülmentünk. Az ilyen eszközök CI-n történő beállításának fontossága ellenére a futtatásuk legfontosabb helye a fejlesztő számítógépe. Végül is a statikus elemző nem olyan bíró, aki valahol messze tőled azt mondja, hogy a kód nem jó. Éppen ellenkezőleg, ez egy asszisztens, amely jelzi, ha fáradt, és emlékezteti, ha elfelejtett valamit.
Igaz, rendszeres használat nélkül a statikus elemzés nem valószínű, hogy jelentősen leegyszerűsíti a fejlesztést. Végül is a fő előnye a fejlesztő számára nem annyira az összetett és ellentmondásos kódrészletek keresésében rejlik, hanem azok korai felismerésében. Egyetért azzal, hogy egy probléma felfedezése a szerkesztések tesztelésre küldése után nemcsak kellemetlen, hanem nagyon időigényes is. Rendszeres használat esetén a statikus elemzés minden változást közvetlenül a számítógépén vizsgál, és a kódon való munka közben jelenti a gyanús helyeket.
És ha Ön vagy kollégái még mindig nem biztosak abban, hogy érdemes-e bevezetni az elemzőt, akkor azt javaslom, hogy most kezdje el elolvasni a cikket "A fejlesztők tipikus aggályaira ad választ, miszerint a statikus elemzés időbe telik, és így tovább.
Ha meg szeretné osztani ezt a cikket egy angolul beszélő közönséggel, kérjük, használja a fordítási linket: Maxim Zvyagintsev. .
Forrás: will.com