Könnyű kipróbálni egy statikus kódelemzőt. De ennek megvalósítása, különösen egy nagy, régi projekt fejlesztése során, készségeket igényel. Ha helytelenül végzik el, az elemző hozzáadhat munkát, lelassíthatja a fejlődést és demotiválhatja a csapatot. Röviden beszéljünk arról, hogyan lehet megfelelően megközelíteni a statikus elemzés integrálását a fejlesztési folyamatba, és hogyan kezdjük el használni a CI/CD részeként.
Bevezetés
Nemrég felkeltette a figyelmemet a "". Egyrészt ez egy jó cikk, érdemes megismerkedni vele. Másrészt számomra úgy tűnik, hogy még mindig nem ad teljes választ arra, hogyan lehet fájdalommentesen megvalósítani a statikus elemzést egy sok projektben A cikk azt írja, hogy Elfogadhatja a technikai tartozást és csak az új kódon dolgozhat, de nincs válasz arra, hogy később mit kezdjen ezzel a technikai tartozással.
A PVS-Studio csapatunk véleményt alkot erről a témáról. Nézzük meg, hogyan merül fel a statikus kódelemző megvalósításának problémája, hogyan lehet ezt a problémát leküzdeni, és hogyan lehet fájdalommentesen, fokozatosan megszüntetni a technikai adósságot.
Problémák
Általában nem nehéz elindítani és megnézni, hogyan működik egy statikus analizátor []. Érdekes hibákat vagy akár félelmetes potenciális sebezhetőségeket is láthat a kódban. Még javíthat is valamit, de akkor sok programozó feladja.
Minden statikus analizátor hamis pozitív eredményt ad. Ez a statikus kódelemzés módszertanának sajátossága, és nem lehet ellene tenni semmit. Általános esetben ez egy megoldhatatlan probléma, amit Rice tétele is megerősít []. A gépi tanulási algoritmusok sem segítenek []. Még ha az ember nem mindig tudja megmondani, hogy ez vagy az a kód hibás-e, akkor ne várja el ezt a programtól :).
A hamis pozitív eredmény nem jelent problémát, ha a statikus analizátor már konfigurálva van:
- Irreleváns szabálykészletek letiltása;
- Néhány irreleváns diagnosztika le van tiltva;
- Ha C-ről vagy C++-ról beszélünk, akkor azokat a makrókat jelölik meg, amelyek konkrét konstrukciókat tartalmaznak, amelyek miatt haszontalan figyelmeztetések jelennek meg minden olyan helyen, ahol ilyen makrókat használnak;
- Olyan saját funkciók vannak megjelölve, amelyek a rendszerfunkciókhoz hasonló műveleteket hajtanak végre (saját analógja memcpy vagy printf) [];
- A hamis pozitívumok kifejezetten letiltásra kerülnek a megjegyzések használatával;
- És így tovább.
Ebben az esetben alacsony, körülbelül 10-15%-os téves pozitív arányra számíthatunk []. Más szavakkal, 9 elemző figyelmeztetésből 10 valós problémát jelez a kódban, vagy legalábbis „erős szagú kódot”. Egyetértek, ez a forgatókönyv rendkívül kellemes, és az analizátor a programozó igazi barátja.
Valójában egy nagy projektben a kezdeti kép teljesen más lesz. Az elemző több száz vagy ezer figyelmeztetést ad ki az örökölt kódra. Lehetetlen gyorsan megérteni, hogy ezek közül a figyelmeztetések közül melyek relevánsak és melyek nem. Irracionális leülni és elkezdeni foglalkozni ezekkel a figyelmeztetésekkel, mivel a fő munka ebben az esetben napokra vagy hetekre leáll. Általában egy csapat nem engedheti meg magának egy ilyen forgatókönyvet. Hatalmas számú különbség is lesz, amelyek elrontják a változástörténetet. A kód oly sok töredékének gyors tömeges szerkesztése pedig elkerülhetetlenül új elírási hibákat és hibákat eredményez.
És ami a legfontosabb, egy ilyen bravúrnak a figyelmeztetések elleni küzdelemben nincs sok értelme. Egyetért azzal, hogy mivel a projekt már évek óta sikeresen fut, a legtöbb kritikus hibát már kijavították. Igen, ezek a javítások nagyon drágák voltak, hibakeresést kellett végrehajtani, negatív felhasználói visszajelzéseket kaptak a hibákról stb. A statikus elemző segít sok ilyen hiba kijavításában a kódolási szakaszban, gyorsan és olcsón. Jelenleg azonban, így vagy úgy, ezeket a hibákat kijavították, és az analizátor elsősorban a régi kód nem kritikus hibáit észleli. Előfordulhat, hogy ezt a kódot nem, nagyon ritkán használják, és a benne lévő hiba nem vezethet észrevehető következményekhez. Lehet, hogy valahol a gomb árnyéka rossz színű, de ez senkit sem zavar a termék használatában.
Természetesen a kisebb hibák is hibák maradnak. És néha egy hiba valódi sebezhetőséget rejthet. Azonban mindenről lemondani és napokat/heteket eltölteni az alig megnyilvánuló hibákkal, kétes ötletnek tűnik.
A programozók nézik, nézik, nézik ezeket a figyelmeztetéseket a régi működő kóddal kapcsolatban... És azt gondolják: megtehetjük statikus elemzés nélkül. Írjunk néhány új hasznos funkciót.
A maguk módján igazuk van. Úgy gondolják, először valahogy meg kell szabadulniuk ezektől a figyelmeztetésektől. Csak akkor tudják majd hasznot húzni a kódelemző rendszeres használatából. Ellenkező esetben az új figyelmeztetések egyszerűen belefulladnak a régiekbe, és senki sem fog rájuk figyelni.
Ez ugyanaz az analógia, mint a fordítói figyelmeztetések esetében. Nem ok nélkül javasolják a fordítói figyelmeztetések számának 0-n tartását. Ha 1000 figyelmeztetés van, akkor 1001-nél senki sem fog rá figyelni, és nem világos, hogy hol keresse ezt a legújabb figyelmeztetést.
A legrosszabb ebben a történetben, ha valaki felülről ebben a pillanatban statikus kódelemzésre kényszerít. Ez csak demotiválja a csapatot, mivel az ő szemszögükből további bürokratikus bonyolultság lesz, ami csak akadályozza. Senki nem nézi meg az elemző jelentéseit, és minden felhasználás csak „papíron” lesz. Azok. Formálisan az elemzés beépül a DevOps folyamatba, de a gyakorlatban ez senkinek sem előnyös. Részletes történeteket hallhattunk a standokon a konferencia résztvevőitől. Egy ilyen tapasztalat hosszú időre, ha nem örökre eltántoríthatja a programozókat a statikus elemző eszközök használatától.
Technikai adósság bevezetése és megszüntetése
Valójában nincs semmi nehéz vagy ijesztő a statikus elemzés bevezetésében, még egy nagy, régi projektben sem.
CI / CD
Sőt, az analizátor azonnal a folyamatos fejlesztési folyamat részévé tehető. Például a PVS-Studio disztribúció olyan segédprogramokat tartalmaz, amelyekkel kényelmesen megtekintheti a jelentést a szükséges formátumban, valamint értesítéseket küld azoknak a fejlesztőknek, akik a kód problémás részeit írták. Azok számára, akiket jobban érdekel a PVS-Studio elindítása CI/CD rendszerekről, javaslom, hogy ismerkedjen meg a megfelelő dokumentáció és cikksorozat:
De térjünk vissza arra a kérdésre, hogy a kódelemző eszközök bevezetésének első szakaszaiban nagyszámú téves pozitív eredmény jelentkezett.
Meglévő technikai tartozás kijavítása és új figyelmeztetések kezelése
A modern kereskedelmi statikus analizátorok csak az új vagy módosított kódban megjelenő új figyelmeztetések tanulmányozását teszik lehetővé. Ennek a mechanizmusnak a megvalósítása változó, de a lényeg ugyanaz. A PVS-Studio statikus analizátorban ez a funkció a következőképpen valósul meg.
A statikus elemzés használatának gyors megkezdéséhez azt javasoljuk a PVS-Studio felhasználóinak, hogy használják a figyelmeztetések tömeges elnyomásának mechanizmusát []. Az általános elképzelés a következő. A felhasználó elindította az analizátort, és számos figyelmeztetést kapott. Mivel egy hosszú évek óta fejlesztés alatt álló projekt él, fejlődik és pénzt keres, ezért nagy valószínűséggel nem sok kritikus hibákra utaló figyelmeztetés lesz a jelentésben. Más szóval, a kritikus hibákat így vagy úgy, drágább módszerekkel vagy az ügyfelek visszajelzéseinek köszönhetően már kijavították. Ennek megfelelően minden, amit az elemző jelenleg talál, technikai adósságnak tekinthető, amit nem célszerű azonnal megpróbálni megszüntetni.
Megmondhatja a PVS-Studio-nak, hogy ezeket a figyelmeztetéseket egyelőre irrelevánsnak tekintse (a technikai adósságot mentse el későbbre), és többé nem jeleníti meg őket. Az elemző létrehoz egy speciális fájlt, ahol elmenti az információkat a még nem érdekes hibákról. És most a PVS-Studio csak új vagy megváltozott kód esetén ad ki figyelmeztetést. Ráadásul mindezt ügyesen valósítják meg. Ha például egy üres sort adunk a forráskódfájl elejéhez, akkor az elemző megérti, hogy valójában semmi sem változott, és továbbra is hallgat. Ez a jelölőfájl behelyezhető egy verziókezelő rendszerbe. A fájl nagy, de ez nem probléma, mivel nincs értelme gyakran tárolni.
Mostantól minden programozó csak az új vagy módosított kóddal kapcsolatos figyelmeztetéseket fogja látni. Így, ahogy mondani szokás, másnaptól elkezdheti használni az analizátort. És később visszatérhet a technikai adóssághoz, és fokozatosan javíthatja a hibákat és konfigurálhatja az analizátort.
Tehát az elemző bevezetésével kapcsolatos első probléma egy nagy régi projektben megoldódott. Most nézzük meg, mit tegyünk a technikai tartozással.
Hibajavítások és átalakítások
A legegyszerűbb és legtermészetesebb dolog az, ha szánunk egy kis időt a tömegesen elnyomott analizátor-figyelmeztetések elemzésére, és fokozatosan kezeljük őket. Valahol javítani kell a kódban lévő hibákat, valahol újra kell állítani, hogy közölje az elemzővel, hogy a kód nem problémás. Egyszerű példa:
if (a = b)A legtöbb C++ fordító és elemző panaszkodik az ilyen kódokra, mivel nagy a valószínűsége annak, hogy valóban írni akartak. (a == b). De van egy kimondatlan megegyezés, és ezt általában fel is jegyezték a dokumentációban, hogy ha vannak további zárójelek, akkor úgy tekintik, hogy a programozó szándékosan írt ilyen kódot, és nem kell káromkodni. Például a PVS-Studio diagnosztikai dokumentációjában egyértelműen le van írva, hogy a következő sort helyesnek és biztonságosnak tekintjük:
if ((a = b))Egy másik példa. El van felejtve ebben a C++ kódban? szünet vagy nem?
case A:
foo();
case B:
bar();
break;A PVS-Studio analizátor itt figyelmeztetést ad ki . Lehetséges, hogy ez nem hiba, ebben az esetben az attribútum hozzáadásával adjon tippet az elemzőnek vagy például __attribútum__((allthrough)):
case A:
foo();
[[fallthrough]];
case B:
bar();
break;Elmondható, hogy az ilyen kódmódosítások nem javítják a hibát. Igen, ez igaz, de két hasznos dolgot tesz. Először is, az analizátor jelentés megszabadul a hamis pozitív eredményektől. Másodszor, a kód érthetőbbé válik a karbantartásában részt vevő emberek számára. És ez nagyon fontos! Már csak ezért is érdemes kisebb átalakításokat végezni, hogy a kód áttekinthetőbb és könnyebben karbantartható legyen. Mivel az elemző nem érti, hogy szükség van-e a „törésre” vagy sem, ez a programozó kollégák számára sem lesz egyértelmű.
A hibajavításokon és átalakításokon kívül kifejezetten elnyomhatja a nyilvánvalóan hamis elemző figyelmeztetéseket. Néhány nem releváns diagnosztika letiltható. Például valaki azt gondolja, hogy a figyelmeztetések értelmetlenek lebegő/kettős értékek összehasonlításáról. Néhányan pedig fontosnak és tanulmányozásra érdemesnek tartják őket []. Hogy mely figyelmeztetések számítanak relevánsnak és melyek nem, azt a fejlesztőcsapat dönti el.
Vannak más módszerek is a téves riasztások elnyomására. Például a makrójelölést korábban említettük. Mindezt részletesebben a dokumentáció írja le. A legfontosabb annak megértése, hogy ha fokozatosan és szisztematikusan közelíti meg a hamis pozitív eredményekkel való munkát, nincs velük semmi baj. Az érdektelen figyelmeztetések túlnyomó többsége a konfigurálás után eltűnik, és csak azok a helyek maradnak meg, amelyek valóban alapos tanulmányozást és néhány kódmódosítást igényelnek.
Emellett mindig segítünk ügyfeleinknek a PVS-Studio felállításában, ha bármilyen nehézség adódik. Sőt, voltak esetek, amikor mi magunk szüntettük meg a téves figyelmeztetéseket és javítottuk ki a hibákat []. Minden esetre úgy döntöttem, megemlítem, hogy ez a lehetőség a kiterjesztett együttműködésre is lehetséges :).
Racsnis módszer
Van egy másik érdekes megközelítés a kód minőségének fokozatos javítására a statikus analizátor figyelmeztetésének megszüntetésével. A lényeg az, hogy a figyelmeztetések száma csak csökkenhet.
A statikus analizátor által kiadott figyelmeztetések száma rögzítésre kerül. A minőségi kapu úgy van konfigurálva, hogy most csak olyan kódot adjon meg, amely nem növeli a műveletek számát. Ennek eredményeként a riasztások számának fokozatos csökkentésének folyamata az analizátor beállításával és a hibák kijavításával kezdődik.
Még akkor sem, ha valaki csalni akar egy kicsit, és úgy dönt, hogy nem a figyelmeztetések kiiktatásával lép át az új kódjában, hanem a régi, harmadik féltől származó kód javításával, ez nem ijesztő. Mindazonáltal a racsnis egy irányba forog, és fokozatosan csökken a hibák száma. Még ha egy személy nem is akarja kijavítani a saját új hibáit, akkor is javítania kell valamit a szomszédos kódban. Egy ponton a figyelmeztetések számának csökkentésének egyszerű módjai véget érnek, és eljön az a pont, amikor a valódi hibákat kijavítják.
Ezt a módszert részletesebben Ivan Ponomarev egy nagyon érdekes cikkében ismerteti.", amelyet ajánlok mindenkinek, aki érdeklődik a kódminőség javítása iránt.
A cikk szerzőjének is van egy beszámolója ebben a témában: "".
Következtetés
Remélem, hogy ezt a cikket követően az olvasók jobban elfogadják a statikus elemzési eszközöket, és be kívánják építeni őket a fejlesztési folyamatba. Ha bármilyen kérdése van, mindig készen állunk PVS-Studio statikus analizátorunk felhasználóit, és segítséget nyújtunk a megvalósításban.
Vannak más tipikus kétségek is azzal kapcsolatban, hogy a statikus elemzés valóban kényelmes és hasznos lehet-e. E kételyek többségét igyekeztem eloszlatni „A PVS-Studio statikus kódelemző fejlesztési folyamatba való bevezetésének okai” című kiadványban.].
Köszönöm a figyelmet és gyere és próbálja ki a PVS-Studio analizátort.
További linkek
- Andrej Karpov.
- Wikipedia. .
- Andrej Karpov, Victoria Khanieva. .
- PVS-stúdió. Dokumentáció. .
- Andrej Karpov. .
- PVS-stúdió. Dokumentáció. .
- Ivan Andryashin. .
- Pavel Eremejev, Szvjatoszlav Razmislov. .
- Andrej Karpov. .
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: Andrey Karpov. .
Forrás: will.com