Είναι εύκολο να δοκιμάσετε έναν αναλυτή στατικού κώδικα. Αλλά για να το εφαρμόσεις, ειδικά στην ανάπτυξη ενός μεγάλου παλιού έργου, απαιτεί δεξιότητα. Εάν γίνει λανθασμένα, ο αναλυτής μπορεί να προσθέσει δουλειά, να επιβραδύνει την ανάπτυξη και να αποθαρρύνει την ομάδα. Ας μιλήσουμε εν συντομία για το πώς να προσεγγίσουμε σωστά την ενσωμάτωση της στατικής ανάλυσης στη διαδικασία ανάπτυξης και να αρχίσουμε να τη χρησιμοποιούμε ως μέρος του CI/CD.
Εισαγωγή
Πρόσφατα τράβηξε την προσοχή μου η δημοσίευση "". Αφενός, αυτό είναι ένα καλό άρθρο που αξίζει να το γνωρίσετε. Από την άλλη, μου φαίνεται ότι εξακολουθεί να μην δίνει μια πλήρη απάντηση για το πώς να εφαρμόσετε ανώδυνα στατική ανάλυση σε ένα έργο με πολλά του κώδικα παλαιού τύπου Το άρθρο λέει ότι μπορείτε να αποδεχτείτε τεχνικό χρέος και να εργαστείτε μόνο σε νέο κωδικό, αλλά δεν υπάρχει απάντηση στο τι να κάνετε με αυτό το τεχνικό χρέος αργότερα.
Η ομάδα μας PVS-Studio προσφέρει την άποψή της για αυτό το θέμα. Ας δούμε πώς προκύπτει αρχικά το πρόβλημα της υλοποίησης ενός αναλυτή στατικού κώδικα, πώς να ξεπεραστεί αυτό το πρόβλημα και πώς να εξαλειφθεί ανώδυνα σταδιακά το τεχνικό χρέος.
Θέματα
Συνήθως δεν είναι δύσκολο να ξεκινήσεις και να δεις πώς λειτουργεί ένας στατικός αναλυτής []. Μπορεί να δείτε ενδιαφέροντα σφάλματα ή ακόμη και τρομακτικά πιθανά τρωτά σημεία στον κώδικα. Μπορείτε ακόμη και να διορθώσετε κάτι, αλλά τότε πολλοί προγραμματιστές εγκαταλείπουν.
Όλοι οι στατικοί αναλυτές παράγουν ψευδώς θετικά αποτελέσματα. Αυτό είναι ένα χαρακτηριστικό της μεθοδολογίας ανάλυσης στατικού κώδικα και δεν μπορεί να γίνει τίποτα γι' αυτό. Στη γενική περίπτωση, αυτό είναι ένα άλυτο πρόβλημα, όπως επιβεβαιώνεται από το θεώρημα του Rice []. Ούτε οι αλγόριθμοι μηχανικής μάθησης θα βοηθήσουν []. Ακόμα κι αν ένα άτομο δεν μπορεί πάντα να πει αν αυτός ή αυτός ο κωδικός είναι λάθος, τότε δεν πρέπει να το περιμένετε από το πρόγραμμα :).
Τα ψευδώς θετικά δεν αποτελούν πρόβλημα εάν ο στατικός αναλυτής έχει ήδη διαμορφωθεί:
- Απενεργοποιήθηκαν άσχετα σύνολα κανόνων.
- Ορισμένα άσχετα διαγνωστικά έχουν απενεργοποιηθεί.
- Αν μιλάμε για C ή C++, τότε επισημαίνονται μακροεντολές που περιέχουν συγκεκριμένες δομές που προκαλούν την εμφάνιση άχρηστων προειδοποιήσεων σε κάθε μέρος όπου χρησιμοποιούνται τέτοιες μακροεντολές.
- Επισημαίνονται οι δικές του λειτουργίες που εκτελούν ενέργειες παρόμοιες με τις λειτουργίες του συστήματος (το δικό του ανάλογο memcpy ή Printf) [];
- Τα ψευδώς θετικά απενεργοποιούνται ειδικά χρησιμοποιώντας σχόλια.
- Και ούτω καθεξής.
Σε αυτή την περίπτωση, μπορούμε να περιμένουμε ένα χαμηλό ποσοστό ψευδώς θετικών περίπου 10-15% []. Με άλλα λόγια, 9 στις 10 προειδοποιήσεις αναλυτή θα υποδεικνύουν ένα πραγματικό πρόβλημα στον κώδικα ή τουλάχιστον «κώδικα με έντονη μυρωδιά». Συμφωνώ, αυτό το σενάριο είναι εξαιρετικά ευχάριστο και ο αναλυτής είναι πραγματικός φίλος του προγραμματιστή.
Στην πραγματικότητα, σε ένα μεγάλο έργο, η αρχική εικόνα θα είναι εντελώς διαφορετική. Ο αναλυτής εκδίδει εκατοντάδες ή χιλιάδες προειδοποιήσεις για κώδικα παλαιού τύπου. Είναι αδύνατο να κατανοήσουμε γρήγορα ποιες από αυτές τις προειδοποιήσεις είναι σχετικές και ποιες όχι. Είναι παράλογο να καθίσουμε και να αρχίσουμε να ασχολούμαστε με όλες αυτές τις προειδοποιήσεις, αφού η κύρια εργασία σε αυτή την περίπτωση θα σταματήσει για μέρες ή εβδομάδες. Τυπικά, μια ομάδα δεν μπορεί να αντέξει οικονομικά ένα τέτοιο σενάριο. Θα υπάρχει επίσης ένας τεράστιος αριθμός διαφορών που θα χαλάσουν το ιστορικό αλλαγών. Και η γρήγορη μαζική επεξεργασία τόσων πολλών θραυσμάτων στον κώδικα θα οδηγήσει αναπόφευκτα σε νέα τυπογραφικά λάθη και λάθη.
Και το πιο σημαντικό, ένα τέτοιο κατόρθωμα στον αγώνα κατά των προειδοποιήσεων δεν έχει νόημα. Συμφωνείτε ότι δεδομένου ότι το έργο εκτελείται με επιτυχία εδώ και πολλά χρόνια, τα περισσότερα από τα κρίσιμα λάθη σε αυτό έχουν ήδη διορθωθεί. Ναι, αυτές οι επιδιορθώσεις ήταν πολύ ακριβές, έπρεπε να διορθωθούν, έλαβαν αρνητικά σχόλια από τους χρήστες σχετικά με σφάλματα και ούτω καθεξής. Ένας στατικός αναλυτής θα βοηθούσε να διορθωθούν πολλά από αυτά τα σφάλματα στο στάδιο της κωδικοποίησης, γρήγορα και φθηνά. Αλλά αυτή τη στιγμή, με τον ένα ή τον άλλο τρόπο, αυτά τα σφάλματα έχουν διορθωθεί και ο αναλυτής εντοπίζει κυρίως μη κρίσιμα σφάλματα στον παλιό κώδικα. Αυτός ο κωδικός μπορεί να μην χρησιμοποιείται, μπορεί να χρησιμοποιείται πολύ σπάνια και ένα σφάλμα σε αυτόν μπορεί να μην έχει αξιοσημείωτες συνέπειες. Ίσως κάπου η σκιά από το κουμπί να έχει λάθος χρώμα, αλλά αυτό δεν παρεμβαίνει στη χρήση του προϊόντος από κανέναν.
Φυσικά, ακόμη και τα μικρά λάθη εξακολουθούν να είναι λάθη. Και μερικές φορές ένα λάθος μπορεί να κρύβει μια πραγματική ευπάθεια. Ωστόσο, το να εγκαταλείψετε τα πάντα και να αφιερώνετε μέρες/εβδομάδες ασχολούμενοι με ελαττώματα που μόλις και μετά βίας εκδηλώνονται μοιάζει με αμφίβολη ιδέα.
Οι προγραμματιστές κοιτούν, κοιτούν, κοιτούν όλες αυτές τις προειδοποιήσεις για τον παλιό κώδικα εργασίας... Και σκέφτονται: μπορούμε να κάνουμε χωρίς στατική ανάλυση. Ας γράψουμε μερικές νέες χρήσιμες λειτουργίες.
Με τον τρόπο τους έχουν δίκιο. Θεωρούν ότι πρώτα πρέπει να απαλλαγούν με κάποιο τρόπο από όλες αυτές τις προειδοποιήσεις. Μόνο τότε θα μπορούν να επωφεληθούν από την τακτική χρήση του αναλυτή κώδικα. Διαφορετικά, οι νέες προειδοποιήσεις απλώς θα πνιγούν στις παλιές και κανείς δεν θα τους δώσει σημασία.
Αυτή είναι η ίδια αναλογία με τις προειδοποιήσεις μεταγλωττιστή. Δεν είναι αδικαιολόγητο ότι συνιστούν να διατηρείται ο αριθμός των προειδοποιήσεων μεταγλωττιστή στο 0. Εάν υπάρχουν 1000 προειδοποιήσεις, τότε όταν υπάρχουν 1001, κανείς δεν θα δώσει σημασία σε αυτό και δεν είναι σαφές πού να αναζητήσετε αυτήν την νεότερη προειδοποίηση.
Το χειρότερο πράγμα σε αυτήν την ιστορία είναι αν κάποιος από ψηλά σε αναγκάσει αυτή τη στιγμή να χρησιμοποιήσεις στατική ανάλυση κώδικα. Αυτό μόνο θα αποθαρρύνει την ομάδα, αφού από την άποψή τους θα υπάρχει πρόσθετη γραφειοκρατική πολυπλοκότητα που απλώς παρεμποδίζει. Κανείς δεν θα κοιτάξει τις αναφορές του αναλυτή και όλη η χρήση θα γίνεται μόνο «στα χαρτιά». Εκείνοι. Επίσημα, η ανάλυση είναι ενσωματωμένη στη διαδικασία DevOps, αλλά στην πράξη αυτό δεν ωφελεί κανέναν. Ακούσαμε λεπτομερείς ιστορίες σε περίπτερα από τους συμμετέχοντες στο συνέδριο. Μια τέτοια εμπειρία μπορεί να αποθαρρύνει τους προγραμματιστές από τη χρήση εργαλείων στατικής ανάλυσης για μεγάλο χρονικό διάστημα, αν όχι για πάντα.
Εφαρμογή και εξάλειψη τεχνικού χρέους
Στην πραγματικότητα, δεν υπάρχει τίποτα δύσκολο ή τρομακτικό για την εισαγωγή στατικής ανάλυσης ακόμη και σε ένα μεγάλο παλιό έργο.
CI / CD
Επιπλέον, ο αναλυτής μπορεί να γίνει αμέσως μέρος της διαδικασίας συνεχούς ανάπτυξης. Για παράδειγμα, η διανομή PVS-Studio περιέχει βοηθητικά προγράμματα για την εύκολη προβολή της αναφοράς στη μορφή που χρειάζεστε και ειδοποιήσεις σε προγραμματιστές που έγραψαν προβληματικές ενότητες του κώδικα. Για όσους ενδιαφέρονται περισσότερο να λανσάρουν το PVS-Studio από συστήματα CI/CD, συνιστώ να εξοικειωθείτε με τα αντίστοιχα τεκμηρίωση και μια σειρά άρθρων:
Αλλά ας επιστρέψουμε στο ζήτημα του μεγάλου αριθμού ψευδώς θετικών στα πρώτα στάδια της εφαρμογής εργαλείων ανάλυσης κώδικα.
Διόρθωση υπάρχοντος τεχνικού χρέους και αντιμετώπιση νέων προειδοποιήσεων
Οι σύγχρονοι εμπορικοί στατικοί αναλυτές σάς επιτρέπουν να μελετάτε μόνο νέες προειδοποιήσεις που εμφανίζονται σε νέο ή αλλαγμένο κώδικα. Η εφαρμογή αυτού του μηχανισμού ποικίλλει, αλλά η ουσία είναι η ίδια. Στον στατικό αναλυτή PVS-Studio, αυτή η λειτουργία υλοποιείται ως εξής.
Για να ξεκινήσετε γρήγορα τη χρήση στατικής ανάλυσης, προτείνουμε στους χρήστες του PVS-Studio να χρησιμοποιούν τον μηχανισμό μαζικής καταστολής των προειδοποιήσεων []. Η γενική ιδέα είναι η εξής. Ο χρήστης εκτόξευσε τον αναλυτή και έλαβε πολλές προειδοποιήσεις. Δεδομένου ότι ένα έργο που βρίσκεται σε ανάπτυξη για πολλά χρόνια είναι ζωντανό, αναπτύσσεται και κερδίζει χρήματα, τότε πιθανότατα δεν θα υπάρχουν πολλές προειδοποιήσεις στην αναφορά που να υποδεικνύουν κρίσιμα ελαττώματα. Με άλλα λόγια, τα κρίσιμα σφάλματα έχουν ήδη διορθωθεί με τον ένα ή τον άλλο τρόπο χρησιμοποιώντας πιο ακριβές μεθόδους ή χάρη σε σχόλια από τους πελάτες. Κατά συνέπεια, όλα όσα βρίσκει επί του παρόντος ο αναλυτής μπορούν να θεωρηθούν τεχνικό χρέος, το οποίο δεν είναι πρακτικό να προσπαθήσουμε να εξαλείψουμε αμέσως.
Μπορείτε να πείτε στο PVS-Studio να θεωρήσει αυτές τις προειδοποιήσεις άσχετες προς το παρόν (εξοικονομήστε τεχνικό χρέος για αργότερα) και δεν θα τις εμφανίζει πλέον. Ο αναλυτής δημιουργεί ένα ειδικό αρχείο όπου αποθηκεύει πληροφορίες σχετικά με σφάλματα που δεν είναι ακόμη ενδιαφέροντα. Και τώρα το PVS-Studio θα εκδίδει προειδοποιήσεις μόνο για νέο ή αλλαγμένο κωδικό. Επιπλέον, όλα αυτά υλοποιούνται έξυπνα. Εάν, για παράδειγμα, προστεθεί μια κενή γραμμή στην αρχή του αρχείου πηγαίου κώδικα, τότε ο αναλυτής κατανοεί ότι, στην πραγματικότητα, τίποτα δεν έχει αλλάξει και θα συνεχίσει να είναι σιωπηλός. Αυτό το αρχείο σήμανσης μπορεί να τοποθετηθεί σε ένα σύστημα ελέγχου έκδοσης. Το αρχείο είναι μεγάλο, αλλά αυτό δεν είναι πρόβλημα, καθώς δεν έχει νόημα να το αποθηκεύετε συχνά.
Τώρα όλοι οι προγραμματιστές θα βλέπουν προειδοποιήσεις που σχετίζονται μόνο με νέο ή αλλαγμένο κώδικα. Έτσι, μπορείτε να αρχίσετε να χρησιμοποιείτε τον αναλυτή, όπως λένε, από την επόμενη μέρα. Και μπορείτε να επιστρέψετε στο τεχνικό χρέος αργότερα και να διορθώσετε σταδιακά τα σφάλματα και να διαμορφώσετε τον αναλυτή.
Έτσι, το πρώτο πρόβλημα με την εφαρμογή του αναλυτή σε ένα μεγάλο παλιό έργο έχει λυθεί. Τώρα ας καταλάβουμε τι να κάνουμε με το τεχνικό χρέος.
Διορθώσεις σφαλμάτων και ανακατασκευές
Το απλούστερο και πιο φυσικό πράγμα είναι να αφιερώσετε λίγο χρόνο για να αναλύσετε τις μαζικά κατασταλμένες προειδοποιήσεις του αναλυτή και να τις αντιμετωπίσετε σταδιακά. Κάπου θα πρέπει να διορθώσετε σφάλματα στον κώδικα, κάπου θα πρέπει να κάνετε αναδιαμόρφωση για να πείτε στον αναλυτή ότι ο κώδικας δεν είναι προβληματικός. Απλό παράδειγμα:
if (a = b)Οι περισσότεροι μεταγλωττιστές και αναλυτές C++ παραπονιούνται για τέτοιο κώδικα, καθώς υπάρχει μεγάλη πιθανότητα να ήθελαν πραγματικά να γράψουν (α == β). Αλλά υπάρχει μια άρρητη συμφωνία, και αυτό συνήθως σημειώνεται στην τεκμηρίωση, ότι εάν υπάρχουν πρόσθετες παρενθέσεις, τότε θεωρείται ότι ο προγραμματιστής έγραψε σκόπιμα τέτοιο κώδικα και δεν χρειάζεται να βρίζεις. Για παράδειγμα, στην τεκμηρίωση PVS-Studio για διαγνωστικά είναι ξεκάθαρα γραμμένο ότι η παρακάτω γραμμή θα θεωρηθεί σωστή και ασφαλής:
if ((a = b))Ενα άλλο παράδειγμα. Ξεχάστηκε σε αυτόν τον κώδικα C++; σπάσει ή όχι?
case A:
foo();
case B:
bar();
break;Ο αναλυτής PVS-Studio θα εκδώσει μια προειδοποίηση εδώ . Αυτό μπορεί να μην είναι σφάλμα, οπότε θα πρέπει να δώσετε στον αναλυτή μια υπόδειξη προσθέτοντας το χαρακτηριστικό ή για παράδειγμα __χαρακτηριστικό__((fallthrough)):
case A:
foo();
[[fallthrough]];
case B:
bar();
break;Μπορούμε να πούμε ότι τέτοιες αλλαγές κώδικα δεν διορθώνουν το σφάλμα. Ναι, αυτό είναι αλήθεια, αλλά κάνει δύο χρήσιμα πράγματα. Πρώτον, η αναφορά του αναλυτή απαλλαγεί από τα ψευδώς θετικά. Δεύτερον, ο κώδικας γίνεται πιο κατανοητός για τους ανθρώπους που εμπλέκονται στη συντήρησή του. Και αυτό είναι πολύ σημαντικό! Για αυτό και μόνο, αξίζει να πραγματοποιήσετε μικρές ανακατασκευές για να γίνει ο κώδικας σαφέστερος και ευκολότερος στη συντήρηση. Εφόσον ο αναλυτής δεν καταλαβαίνει εάν χρειάζεται ή όχι "σπάσιμο", θα είναι επίσης ασαφές στους συναδέλφους προγραμματιστές.
Εκτός από τις διορθώσεις σφαλμάτων και τις ανακατασκευές, μπορείτε να καταστείλετε συγκεκριμένα προφανώς ψευδείς προειδοποιήσεις αναλυτών. Μερικά άσχετα διαγνωστικά μπορούν να απενεργοποιηθούν. Για παράδειγμα, κάποιος πιστεύει ότι οι προειδοποιήσεις είναι άσκοπες σχετικά με τη σύγκριση τιμών float/διπλών τιμών. Και κάποιοι τα κατατάσσουν ως σημαντικά και άξια μελέτης []. Ποιες προειδοποιήσεις θεωρούνται σχετικές και ποιες όχι, εναπόκειται στην ομάδα ανάπτυξης να αποφασίσει.
Υπάρχουν άλλοι τρόποι για την καταστολή των ψευδών ειδοποιήσεων. Για παράδειγμα, η σήμανση μακροεντολών αναφέρθηκε νωρίτερα. Όλα αυτά περιγράφονται λεπτομερέστερα στην τεκμηρίωση. Το πιο σημαντικό πράγμα είναι να καταλάβετε ότι αν σταδιακά και συστηματικά προσεγγίζετε τη δουλειά με ψευδώς θετικά, δεν υπάρχει τίποτα κακό με αυτά. Η συντριπτική πλειονότητα των μη ενδιαφέρουσες προειδοποιήσεις εξαφανίζονται μετά τη διαμόρφωση και παραμένουν μόνο μέρη που απαιτούν πραγματικά προσεκτική μελέτη και ορισμένες αλλαγές στον κώδικα.
Επίσης, βοηθάμε πάντα τους πελάτες μας να δημιουργήσουν το PVS-Studio σε περίπτωση που προκύψουν δυσκολίες. Επιπλέον, υπήρξαν περιπτώσεις που εμείς οι ίδιοι εξαλείψαμε ψευδείς προειδοποιήσεις και διορθώσαμε λάθη []. Για κάθε ενδεχόμενο, αποφάσισα να αναφέρω ότι αυτή η επιλογή για εκτεταμένη συνεργασία είναι επίσης δυνατή :).
Μέθοδος καστάνιας
Υπάρχει μια άλλη ενδιαφέρουσα προσέγγιση για τη σταδιακή βελτίωση της ποιότητας του κώδικα εξαλείφοντας την προειδοποίηση του στατικού αναλυτή. Η ουσία είναι ότι ο αριθμός των προειδοποιήσεων μπορεί μόνο να μειωθεί.
Καταγράφεται ο αριθμός των προειδοποιήσεων που εκδίδονται από τον στατικό αναλυτή. Η πύλη ποιότητας έχει ρυθμιστεί με τέτοιο τρόπο ώστε τώρα μπορείτε να εισάγετε μόνο έναν κωδικό που δεν αυξάνει τον αριθμό των λειτουργιών. Ως αποτέλεσμα, η διαδικασία της σταδιακής μείωσης του αριθμού των συναγερμών ξεκινά με τη ρύθμιση του αναλυτή και τη διόρθωση σφαλμάτων.
Ακόμα κι αν ένα άτομο θέλει να εξαπατήσει λίγο και αποφασίσει να περάσει την πύλη ποιότητας όχι εξαλείφοντας τις προειδοποιήσεις στον νέο κωδικό του, αλλά βελτιώνοντας τον παλιό κωδικό τρίτων, αυτό δεν είναι τρομακτικό. Παρόλα αυτά, η καστάνια περιστρέφεται προς μία κατεύθυνση και σταδιακά ο αριθμός των ελαττωμάτων θα μειωθεί. Ακόμα κι αν ένα άτομο δεν θέλει να διορθώσει τα δικά του νέα ελαττώματα, θα πρέπει να βελτιώσει κάτι στον γειτονικό κώδικα. Κάποια στιγμή, οι εύκολοι τρόποι μείωσης του αριθμού των προειδοποιήσεων τελειώνουν και έρχεται ένα σημείο που θα διορθωθούν τα πραγματικά σφάλματα.
Αυτή η μεθοδολογία περιγράφεται με περισσότερες λεπτομέρειες σε ένα πολύ ενδιαφέρον άρθρο του Ivan Ponomarev "", το οποίο συνιστώ να διαβάσει σε όποιον ενδιαφέρεται να βελτιώσει την ποιότητα του κώδικα.
Ο συγγραφέας του άρθρου έχει επίσης μια αναφορά για αυτό το θέμα: "".
Συμπέρασμα
Ελπίζω ότι μετά από αυτό το άρθρο, οι αναγνώστες θα αποδεχτούν περισσότερο τα εργαλεία στατικής ανάλυσης και θα θελήσουν να τα εφαρμόσουν στη διαδικασία ανάπτυξης. Εάν έχετε οποιεσδήποτε ερωτήσεις, είμαστε πάντα έτοιμοι χρήστες του στατικού μας αναλυτή PVS-Studio και βοηθούν στην υλοποίησή του.
Υπάρχουν άλλες τυπικές αμφιβολίες σχετικά με το εάν η στατική ανάλυση μπορεί πραγματικά να είναι βολική και χρήσιμη. Προσπάθησα να διαλύσω τις περισσότερες από αυτές τις αμφιβολίες στη δημοσίευση «Λόγοι για την εισαγωγή του αναλυτή στατικού κώδικα PVS-Studio στη διαδικασία ανάπτυξης» [].
Ευχαριστώ για την προσοχή σας και ελάτε και δοκιμάστε τον αναλυτή PVS-Studio.
Πρόσθετοι σύνδεσμοι
- Αντρέι Καρπόφ.
- Wikipedia. .
- Andrey Karpov, Victoria Khanieva. .
- PVS-Studio. Τεκμηρίωση. .
- Αντρέι Καρπόφ. .
- PVS-Studio. Τεκμηρίωση. .
- Ivan Andryashin. .
- Pavel Eremeev, Svyatoslav Razmyslov. .
- Αντρέι Καρπόφ. .
Εάν θέλετε να μοιραστείτε αυτό το άρθρο με ένα αγγλόφωνο κοινό, χρησιμοποιήστε τον σύνδεσμο μετάφρασης: Andrey Karpov. .
Πηγή: www.habr.com