Na het eindeloze code review of debuggen vraag je je soms af hoe je het leven gemakkelijker kunt maken. En na een beetje zoeken, of misschien gewoon toevallig, kom je de magie woorden tegen: "Statische analyse". Laten we eens kijken wat dit inhoudt en hoe het met jouw project kan samenwerken.
Eigenlijk, als je in een moderne programmeertaal schrijft, dan heb je, zonder het te beseffen, je code door een statische analyser laten lopen. Het punt is dat elke moderne compiler, hoe klein ook, een set waarschuwingen biedt over potentiële problemen in de code. Bijvoorbeeld, als je C++ code compileert in Visual Studio, kun je het volgende zien:
In deze output zien we dat de variabele var ergens in de functie niet is gebruikt. Dus je hebt eigenlijk bijna altijd gebruik gemaakt van een eenvoudige statische code-analyse. Echter, in tegenstelling tot professionele analyzers zoals Coverity, Klocwork of PVS-Studio, kunnen de waarschuwingen van de compiler maar een beperkt spectrum aan problemen aangeven.
Als je niet zeker weet wat statische analyse is en hoe je het kunt implementeren, , om deze methode uitgebreider te leren kennen.
Waarom is statische analyse nodig?
In het kort: versnelling en vereenvoudiging.
Statische analyse helpt een schat aan verschillende problemen in de code te vinden: van verkeerd gebruik van talige constructies tot typfouten. Bijvoorbeeld, in plaats van
auto x = obj.x;
auto y = obj.y;
auto z = obj.z;heb je de volgende code geschreven:
auto x = obj.x;
auto y = obj.y;
auto z = obj.x;Zoals je ziet, is er een typfout in de laatste regel. Bijvoorbeeld, PVS-Studio geeft de volgende waarschuwing:
Overweeg de correctheid van het gebruik van het item 'y' te herzien.
Als je deze fout met je eigen handen wilt uitproberen, probeer dan het voorbeeld op Compiler Explorer: **.
En zoals je begrijpt, is het niet altijd mogelijk om onmiddellijk op dergelijke delen van de code te letten, waardoor je een behoorlijke tijd met debuggen bezig kunt zijn, niet begrijpend waarom alles zo vreemd werkt.
Maar dit is een duidelijke fout. En wat als de ontwikkelaar onoptimale code heeft geschreven omdat hij een bepaalde nuance van de taal is vergeten? Of heeft hij zelfs in de code ? К сожалению, подобные случаи совершенно обыденны и львиная часть времени тратится на то, чтобы отладить специфично работающий код, который содержит опечатки, типичные ошибки или undefined behavior.
Specifiek voor deze situaties is statische analyse ontstaan. Dit is een assistent voor de ontwikkelaar die hem wijst op verschillende problemen in de code en in de documentatie uitlegt waarom hij het zo niet moet schrijven, welke gevolgen dit heeft en hoe hij het kan oplossen. Hier is een voorbeeld van hoe dit eruit kan zien: **.
Meer interessante fouten die de analyser kan ontdekken, vindt u in de artikelen:
Nu, na het lezen van dit materiaal en overtuigd te zijn van de voordelen van statische analyse, wilt u misschien zelf aan de slag. Maar waar te beginnen? Hoe integreert u een nieuw hulpmiddel in uw huidige project? En hoe introduceert u het bij uw team? U vindt antwoorden op deze vragen hieronder.
Note. Statische analyse vervangt of annuleert niet zoiets nuttigs als code reviews. Het completeert dit proces door te helpen typfouten, onnauwkeurigheden en gevaarlijke constructies vroegtijdig op te merken en te corrigeren. Het is veel productiever om bij code reviews te focussen op algoritmes en de begrijpelijkheid van de code, in plaats van het zoeken naar een verkeerd geplaatste haakje of .
0. Kennismaking met het hulpmiddel
Alles begint met een proefversie. Het is inderdaad moeilijk om iets in het ontwikkelingsproces te implementeren als je het hulpmiddel nog nooit in het echt hebt gezien. Daarom is het eerst de moeite waard om te downloaden .
Wat u in deze fase zult leren:
- Welke manieren er zijn om met de analyser te communiceren;
- Of de analyser compatibel is met uw ontwikkelomgeving;
- Welke problemen er momenteel zijn in uw projecten.
Nadat u alles wat nodig is heeft geïnstalleerd, is het belangrijk om als eerste de analyse van het gehele project te starten (, , ). In het geval van PVS-Studio in Visual Studio ziet u een soortgelijke afbeelding (klikbaar):
Het punt is dat statische analyzers meestal een enorme hoeveelheid waarschuwingen geven voor projecten met een grote codebasis. Het is niet nodig om ze allemaal te corrigeren, aangezien uw project al werkt en deze problemen dus niet kritiek zijn. U en ze indien nodig te corrigeren. Hiervoor moet de output gefilterd worden en alleen de meest betrouwbare meldingen overblijven. In de PVS-Studio-plugin voor Visual Studio gebeurt dit door te filteren op fouten niveaus en categorieën. Voor de meest nauwkeurige output, laat alleen geactiveerd: High en Algemeen (ook klikbaar):
Inderdaad, 178 waarschuwingen bekijken is aanzienlijk eenvoudiger dan enkele duizenden...
In de tabbladen Medium en Laag kom je vaak goede waarschuwingen tegen, maar in deze categorieën zijn ook diagnostiek opgenomen die minder nauwkeurig zijn (betrouwbaarheid). Meer informatie over waarschuwingsniveaus en werkmethoden onder Windows kan hier worden bekeken: **.
Nadat je de meest interessante fouten succesvol hebt bekeken (en correcties hebt aangebracht), is het tijd om . Dit is nodig zodat nieuwe waarschuwingen niet verloren gaan tussen oude. Bovendien is de statische analyzer een assistent voor de programmeur, en geen lijst voor bugs. 🙂
1. Automatisering
Na de kennismaking is het tijd voor de instellingen van de plugins en integratie in CI. Dit moet worden gedaan voordat de programmeurs beginnen met het gebruik van de statische analyzer. Het punt is dat een programmeur kan vergeten de analyse in te schakelen of er gewoon niet om geeft. Hiervoor is een laatste controle van alles nodig, zodat niet-geanalyseerde code niet in de hoofdontwikkelingsbranch kan komen.
Wat je in deze fase zult leren:
- Welke automatiseringsmogelijkheden de tool biedt;
- Of de analyzer compatibel is met jouw build-systeem.
Aangezien er geen ideale documentatie bestaat, moet je af en toe schrijven naar . Dat is normaal, en we helpen je graag. 🙂
Laten we nu overgaan op de continue integratieservices (CI). Elke analyzer kan hierin zonder enige serieuze problemen worden geïntegreerd. Hiervoor moet een aparte stap in de pipeline worden gecreëerd, meestal na de build en unit tests. Dit gebeurt met behulp van verschillende consoletools. Bijvoorbeeld, PVS-Studio biedt de volgende tools:
- (analyse van oplossingen, C#, C++ projecten op Windows)
- (monitoring van compilatie)
- (analyse van C++ projecten op Linux / macOS)
- (analyse van oplossingen, C# projecten op Linux / macOS)
- (analyse van Java projecten)
- (bestandsconversie tool voor rapporten)
Voor de integratie van analyse in CI moet je drie dingen doen:
- De analyzer installeren;
- De analyse starten;
- Lever de resultaten.
Bijvoorbeeld, om PVS-Studio op Linux (Debian-gebaseerd) te installeren, moeten de volgende commando's worden uitgevoerd:
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-studioIn systemen die draaien op Windows is het niet mogelijk om de analyzer via de pakketbeheerder te installeren, maar er is de mogelijkheid om de analyzer vanuit de opdrachtregel te installeren:
PVS-Studio_setup.exe /verysilent /suppressmsgboxes
/norestart /nocloseapplicationsMeer informatie over het implementeren van PVS-Studio in Windows-systemen is te vinden in **.
Na de installatie moet de analyse zelf worden gestart. Dit wordt echter aanbevolen pas te doen nadat de compilatie en tests zijn uitgevoerd. Dit komt doordat voor statische analyse meestal twee keer zoveel tijd nodig is als voor compilatie.
Aangezien de manier van starten afhankelijk is van het platform en de kenmerken van het project, laat ik een voorbeeld zien voor C++ (Linux):
pvs-studio-analyzer analyze -j8
-o PVS-Studio.log
plog-converter -t errorfile PVS-Studio.log --cerr -wHet eerste commando voert de analyse uit, en het tweede het rapport naar tekstformaat, geeft het weer op het scherm en retourneert een code die verschilt van 0 in het geval van waarschuwingen. Dit mechanisme kan handig worden gebruikt om de build te blokkeren bij fouten. U kunt echter altijd de vlag -w weghalen en de build met waarschuwingen niet blokkeren.
Note. Het tekstformaat is onhandig. Dit wordt simpelweg als voorbeeld gegeven. Let op het interessantere rapportformaat — FullHtml. Dit maakt navigatie door de code mogelijk.
Meer informatie over het instellen van analyses op CI is te vinden in het artikel "" (Windows) of "" (Linux).
Oké, u heeft de werking van de analyzer op de buildserver ingesteld. Nu, als iemand niet-gecontroleerde code uploadt, zal de controlefase falen, en kunt u het probleem ontdekken, maar dit is niet helemaal handig, omdat het effectiever is om het project te controleren voordat de takken worden samengevoegd, tijdens de fase van de pull request.
In het algemeen verschilt het instellen van analyses voor pull requests niet veel van de gewone analyse bij CI. Behalve dat u een lijst met gewijzigde bestanden moet verkrijgen. Deze kunnen meestal worden verkregen door het verschil tussen de takken op te vragen met behulp van git:
git diff --name-only HEAD origin/$MERGE_BASE > .pvs-pr.listNu is het tijd om deze lijst met bestanden aan de analyzer door te geven. Bijvoorbeeld, in PVS-Studio wordt dit gedaan met behulp van een vlag. -S:
pvs-studio-analyzer analyze -j8
-o PVS-Studio.log
-S .pvs-pr.listMeer informatie over de analyse van pull requests is te vinden ** Zelfs als jouw CI niet in de lijst van vermelde diensten staat, zal de algemene sectie over de theorie van dit type analyse je nuttig zijn.
Door de analyse van pull requests in te stellen, kun je commits die waarschuwingen bevatten blokkeren, waardoor een grens ontstaat die niet-gecontroleerde code niet kan overschrijden.
Dit is zonder twijfel goed, maar ik wil graag de mogelijkheid hebben om alle waarschuwingen op één plek te bekijken. Niet alleen van de statische analyzer, maar ook van unittests of van de dynamische analyzer. Hiervoor bestaan verschillende services en plugins. PVS-Studio heeft bijvoorbeeld een .
2. Integratie op de machines van ontwikkelaars
Nu is het tijd voor de installatie en configuratie van de analyzer voor dagelijks gebruik tijdens de ontwikkeling. Tegen deze tijd ben je al bekend met de meeste werkmethoden, dus dit kan de makkelijkste stap zijn.
Als de meest eenvoudige optie kunnen ontwikkelaars zelf de benodigde analyzer installeren. Dit kost echter veel tijd en zal hen afleiden van de ontwikkeling, daarom kun je dit proces automatiseren met behulp van een installer en de benodigde vlaggen. Voor PVS-Studio zijn er verschillende . Er zijn echter altijd pakketbeheerders, zoals Chocolatey (Windows), Homebrew (macOS) of tientallen opties voor Linux.
Vervolgens moeten de benodigde plugins worden geïnstalleerd, bijvoorbeeld voor , , enz.
3. Dagelijks gebruik
In deze fase is het tijd om een paar woorden te zeggen over manieren om het werk van de analyzer te versnellen tijdens dagelijks gebruik. Een volledige analyse van het hele project kost veel tijd, maar hoe vaak veranderen we de code ineens in het hele project? Het is zeldzaam dat er een zo grote refactoring is die de hele codebasis tegelijkertijd raakt. Het aantal gewijzigde bestanden per keer overstijgt zelden tien, dus het is logisch om alleen die te analyseren. Voor dergelijke situaties bestaat er . Maak je geen zorgen, dit is geen extra tool. Dit is een speciale modus die automatisch alleen de gewijzigde bestanden en hun afhankelijkheden analyseert na de build, op voorwaarde dat je werkt in een IDE met een geïnstalleerde plug-in.
Als de analyzer problemen ontdekt in de recent gewijzigde code, zal hij dit zelfstandig melden. PVS-Studio bijvoorbeeld, zal je hierover informeren via een melding:
Het is natuurlijk niet genoeg om de ontwikkelaars gewoon te zeggen dat ze de tool moeten gebruiken. Je moet ze uitleggen wat het inhoudt en hoe het werkt. Hier zijn bijvoorbeeld artikelen voor een snelle start met PVS-Studio, maar dergelijke tutorials kun je voor elk hulpmiddel dat je verkiest vinden:
Dergelijke artikelen bieden alle benodigde informatie voor dagelijks gebruik en kosten niet veel tijd. 🙂
Tijdens de kennismaking met de tool hebben we veel waarschuwingen onderdrukt tijdens een van de eerste opstartmomenten. Helaas zijn statische analyzers niet perfect, dus af en toe geven ze valse positieven. Het is meestal eenvoudig om ze te onderdrukken; bijvoorbeeld in de PVS-Studio plug-in voor Visual Studio hoef je slechts op één knop te drukken:
Maar je kunt ze niet alleen onderdrukken. Je kunt bijvoorbeeld een probleem melden aan de ondersteuning. Als valse positieven kunnen worden opgelost, kun je in toekomstige updates opmerken dat er met de tijd steeds minder specifieke valse positieven voor jouw codebase zijn.
Na de integratie
Nu hebben we alle stappen doorlopen om statische analyse in het ontwikkelingsproces te integreren. Ondanks het belang van het instellen van dergelijke tools in CI, is de belangrijkste plek voor de uitvoering eigenlijk de computer van de ontwikkelaar. Want de statische analyzer is geen rechter die op afstand zegt dat de code niet goed is. Integendeel, het is een assistent die je helpt als je moe bent en je eraan herinnert als je iets vergeten bent.
Eerlijk gezegd zal statische analyse zonder regelmatig gebruik waarschijnlijk de ontwikkeling niet significant vergemakkelijken. Immers, het grootste voordeel voor de ontwikkelaar ligt niet zozeer in het vinden van complexe en controversiële delen van de code, maar in het vroegtijdig opsporen ervan. U zult het ermee eens zijn dat het ontdekken van een probleem wanneer wijzigingen naar de testfase zijn gestuurd, niet alleen vervelend is, maar ook veel tijd kost. Statische analyse kan echter, bij regelmatig gebruik, elke wijziging op uw computer bekijken en meldt verdachte plekken tijdens het coderen.
En als u of uw collega's nog steeds niet zeker zijn of het de moeite waard is om een analyse-instrument te implementeren, stel ik voor om nu het artikel "" te lezen. Daarin worden de typische bezorgdheden van ontwikkelaars behandeld over het feit dat statische analyse hun tijd zou kosten, en dergelijke.
Als u dit artikel met een Engelstalig publiek wilt delen, gebruik dan alstublieft de link naar de vertaling: Maxim Zvyagintsev. .
Bron: habr.com
