Εμπνεύστηκα για να γράψω αυτό το άρθρο από ένα μεγάλο αριθμό υλικών στατικής ανάλυσης που έρχονται όλο και περισσότερο. Πρώτον, αυτό , το οποίο προωθείται ενεργά στο Habré με κριτικές σφαλμάτων που εντοπίστηκαν από το εργαλείο τους σε έργα ανοιχτού κώδικα. Το PVS-studio υλοποιήθηκε πρόσφατα και, φυσικά, οι προγραμματιστές του IntelliJ IDEA, του οποίου ο ενσωματωμένος αναλυτής είναι ίσως ο πιο προηγμένος για την Java σήμερα, .
Όταν διαβάζετε τέτοιες κριτικές, έχετε την αίσθηση ότι μιλάμε για ένα μαγικό ελιξίριο: πατήστε το κουμπί και εδώ είναι - μια λίστα με ελαττώματα μπροστά στα μάτια σας. Φαίνεται ότι όσο βελτιώνονται οι αναλυτές, θα υπάρχουν αυτόματα όλο και περισσότερα σφάλματα και τα προϊόντα που σαρώνονται από αυτά τα ρομπότ θα γίνονται όλο και καλύτερα, χωρίς καμία προσπάθεια από μέρους μας.
Αλλά δεν υπάρχουν μαγικά ελιξήρια. Θα ήθελα να μιλήσω για αυτό που συνήθως δεν συζητείται σε αναρτήσεις όπως «εδώ είναι τα πράγματα που μπορεί να βρει το ρομπότ μας»: τι δεν μπορούν να κάνουν οι αναλυτές, ποιος είναι ο πραγματικός ρόλος και η θέση τους στη διαδικασία παράδοσης λογισμικού και πώς να τα εφαρμόσουν σωστά.
Ratchet (πηγή: ).
Τι δεν μπορούν ποτέ να κάνουν οι στατικοί αναλυτές
Τι είναι, από πρακτική άποψη, η ανάλυση πηγαίου κώδικα; Τροφοδοτούμε σε ορισμένες πηγές και σε σύντομο χρονικό διάστημα (πολύ μικρότερο από τις τρέχουσες δοκιμές) λαμβάνουμε κάποιες πληροφορίες για το σύστημά μας. Ο θεμελιώδης και μαθηματικά ανυπέρβλητος περιορισμός είναι ότι μπορούμε έτσι να αποκτήσουμε μόνο μια μάλλον στενή κατηγορία πληροφοριών.
Το πιο διάσημο παράδειγμα ενός προβλήματος που δεν μπορεί να λυθεί με στατική ανάλυση είναι : αυτό είναι ένα θεώρημα που αποδεικνύει ότι είναι αδύνατο να αναπτυχθεί ένας γενικός αλγόριθμος που θα καθόριζε από τον πηγαίο κώδικα του προγράμματος εάν θα βρόχο ή θα τερματίσει σε έναν πεπερασμένο χρόνο. Προέκταση αυτού του θεωρήματος είναι , το οποίο δηλώνει ότι για οποιαδήποτε μη τετριμμένη ιδιότητα υπολογισμών συναρτήσεων, ο καθορισμός του εάν ένα αυθαίρετο πρόγραμμα αξιολογεί μια συνάρτηση με μια τέτοια ιδιότητα είναι ένα αλγοριθμικά άλυτο πρόβλημα. Για παράδειγμα, είναι αδύνατο να γραφτεί ένας αναλυτής που να μπορεί να προσδιορίσει από οποιονδήποτε πηγαίο κώδικα εάν το αναλυόμενο πρόγραμμα είναι μια υλοποίηση ενός αλγορίθμου που υπολογίζει, ας πούμε, τον τετραγωνισμό ενός ακέραιου αριθμού.
Έτσι, η λειτουργικότητα των στατικών αναλυτών έχει ανυπέρβλητους περιορισμούς. Ένας στατικός αναλυτής δεν θα είναι ποτέ σε θέση να προσδιορίσει σε όλες τις περιπτώσεις πράγματα όπως, για παράδειγμα, την εμφάνιση "εξαίρεσης μηδενικού δείκτη" σε μηδενικές γλώσσες ή σε όλες τις περιπτώσεις να προσδιορίσει την εμφάνιση "χαρακτηριστικό που δεν βρέθηκε" σε γλώσσες με δυναμική πληκτρολόγηση. Το μόνο που μπορεί να κάνει ο πιο προηγμένος στατικός αναλυτής είναι να επισημάνει ειδικές περιπτώσεις, ο αριθμός των οποίων, μεταξύ όλων των πιθανών προβλημάτων με τον πηγαίο κώδικα, είναι, χωρίς υπερβολή, μια σταγόνα στον ωκεανό.
Η στατική ανάλυση δεν είναι αναζήτηση σφαλμάτων
Το συμπέρασμα προκύπτει από τα παραπάνω: η στατική ανάλυση δεν είναι ένα μέσο μείωσης του αριθμού των ελαττωμάτων σε ένα πρόγραμμα. Θα τολμήσω να πω ότι όταν εφαρμοστεί για πρώτη φορά στο έργο σας, θα βρει "διασκεδαστικά" σημεία στον κώδικα, αλλά, πιθανότατα, δεν θα βρει ελαττώματα που επηρεάζουν την ποιότητα του προγράμματός σας.
Τα παραδείγματα ελαττωμάτων που εντοπίζονται αυτόματα από τους αναλυτές είναι εντυπωσιακά, αλλά δεν πρέπει να ξεχνάμε ότι αυτά τα παραδείγματα εντοπίστηκαν σαρώνοντας ένα μεγάλο σύνολο μεγάλων βάσεων κωδικών. Με την ίδια αρχή, οι κροτίδες που είναι σε θέση να δοκιμάσουν πολλούς απλούς κωδικούς πρόσβασης σε μεγάλο αριθμό λογαριασμών βρίσκουν τελικά αυτούς τους λογαριασμούς που έχουν έναν απλό κωδικό πρόσβασης.
Αυτό σημαίνει ότι δεν πρέπει να εφαρμόζεται στατική ανάλυση; Φυσικά και όχι! Και ακριβώς για τον ίδιο λόγο για τον οποίο αξίζει να ελέγχετε κάθε νέο κωδικό πρόσβασης για να μπείτε στη λίστα διακοπής των «απλών» κωδικών πρόσβασης.
Η στατική ανάλυση είναι κάτι περισσότερο από την εύρεση σφαλμάτων
Στην πραγματικότητα, τα προβλήματα που επιλύονται πρακτικά με ανάλυση είναι πολύ ευρύτερα. Εξάλλου, γενικά, στατική ανάλυση είναι οποιοσδήποτε έλεγχος των πηγαίων κωδίκων που πραγματοποιείται πριν από την εκτόξευση. Εδώ είναι μερικά πράγματα που μπορείτε να κάνετε:
- Έλεγχος του στυλ κωδικοποίησης με την ευρεία έννοια της λέξης. Αυτό περιλαμβάνει τόσο τον έλεγχο μορφοποίησης όσο και την αναζήτηση χρήσης κενών/επιπλέον παρενθέσεων, τον ορισμό ορίων σε μετρήσεις όπως ο αριθμός γραμμών / η πολυπλοκότητα της κυκλωματικής μεθόδου κ.λπ. - όλα όσα δυνητικά κάνουν τον κώδικα πιο ευανάγνωστο και διατηρήσιμο. Στην Java αυτό το εργαλείο είναι Checkstyle, στην Python είναι flake8. Τα προγράμματα αυτής της κατηγορίας ονομάζονται συνήθως "linters".
- Δεν μπορεί να αναλυθεί μόνο ο εκτελέσιμος κώδικας. Τα αρχεία πόρων όπως τα JSON, YAML, XML, .properties μπορούν (και πρέπει!) να ελεγχθούν αυτόματα για εγκυρότητα. Δεν είναι καλύτερο να ανακαλύψουμε ότι λόγω ορισμένων μη ζευγαρωμένων εισαγωγικών, η δομή JSON έχει σπάσει σε πρώιμο στάδιο της αυτόματης επικύρωσης αιτήματος έλξης παρά κατά την εκτέλεση δοκιμών ή την ώρα εκτέλεσης; Διατίθενται κατάλληλα εργαλεία: για παράδειγμα, , .
- Η μεταγλώττιση (ή η ανάλυση για δυναμικές γλώσσες προγραμματισμού) είναι επίσης ένα είδος στατικής ανάλυσης. Κατά κανόνα, οι μεταγλωττιστές είναι σε θέση να εκδίδουν προειδοποιήσεις που υποδεικνύουν προβλήματα με την ποιότητα του πηγαίου κώδικα και δεν πρέπει να αγνοούνται.
- Μερικές φορές η μεταγλώττιση δεν αφορά μόνο τη μεταγλώττιση εκτελέσιμου κώδικα. Για παράδειγμα, εάν έχετε τεκμηρίωση σε μορφή , τότε τη στιγμή της μετατροπής του σε πρόγραμμα χειρισμού HTML/PDF AsciiDoctor () μπορεί να εκδίδει προειδοποιήσεις, για παράδειγμα, για κατεστραμμένους εσωτερικούς συνδέσμους. Και αυτός είναι ένας καλός λόγος για να μην αποδεχτείτε το αίτημα έλξης με αλλαγές τεκμηρίωσης.
- Ο ορθογραφικός έλεγχος είναι επίσης ένας τύπος στατικής ανάλυσης. Χρησιμότητα είναι σε θέση να ελέγχει την ορθογραφία όχι μόνο στην τεκμηρίωση, αλλά και στους πηγαίους κώδικες προγραμμάτων (σχόλια και κυριολεκτικά) σε διάφορες γλώσσες προγραμματισμού, συμπεριλαμβανομένων των C/C++, Java και Python. Ένα ορθογραφικό λάθος στη διεπαφή χρήστη ή στην τεκμηρίωση είναι επίσης ελάττωμα!
- Δοκιμές διαμόρφωσης (για το τι είναι, βλ и αναφορές), παρόλο που εκτελούνται σε χρόνο εκτέλεσης δοκιμής μονάδας όπως το pytest, στην πραγματικότητα αποτελούν επίσης ένα είδος στατικής ανάλυσης, καθώς δεν εκτελούν πηγαίους κώδικες κατά την εκτέλεσή τους.
Όπως μπορείτε να δείτε, η εύρεση σφαλμάτων σε αυτήν τη λίστα παίζει τον λιγότερο σημαντικό ρόλο και οτιδήποτε άλλο είναι διαθέσιμο μέσω της χρήσης δωρεάν εργαλείων ανοιχτού κώδικα.
Ποιος από αυτούς τους τύπους στατικής ανάλυσης θα πρέπει να χρησιμοποιηθεί στο έργο σας; Φυσικά, όσο περισσότερα, τόσο το καλύτερο! Το κύριο πράγμα είναι να το εφαρμόσετε σωστά, το οποίο θα συζητηθεί περαιτέρω.
Σωλήνας παράδοσης ως φίλτρο πολλαπλών σταδίων και στατική ανάλυση ως πρώτος καταρράκτης
Η κλασική μεταφορά για τη συνεχή ολοκλήρωση είναι ο αγωγός (pipeline) μέσω του οποίου ρέουν οι αλλαγές - από την αλλαγή του πηγαίου κώδικα έως την παράδοση στην παραγωγή. Η τυπική ακολουθία σταδίων αυτού του αγωγού μοιάζει με αυτό:
- στατική ανάλυση
- συλλογή
- δοκιμές μονάδας
- δοκιμές ολοκλήρωσης
- Δοκιμές διεπαφής χρήστη
- χειροκίνητος έλεγχος
Οι αλλαγές που απορρίφθηκαν στο Νο στάδιο του αγωγού δεν διαδίδονται στο στάδιο Ν+1.
Γιατί ακριβώς έτσι και όχι αλλιώς; Στο τμήμα δοκιμής του αγωγού, οι δοκιμαστές θα αναγνωρίσουν τη γνωστή δοκιμαστική πυραμίδα.
Δοκιμαστική πυραμίδα. Πηγή: Μάρτιν Φάουλερ.
Στο κάτω μέρος αυτής της πυραμίδας υπάρχουν τεστ που είναι πιο εύκολο να γραφτούν, τρέχουν πιο γρήγορα και δεν τείνουν να είναι ψευδώς θετικά. Επομένως, θα πρέπει να υπάρχουν περισσότερα από αυτά, θα πρέπει να καλύπτουν περισσότερο κώδικα και να εκτελούνται πρώτα. Στην κορυφή της πυραμίδας, ισχύει το αντίθετο, επομένως ο αριθμός των δοκιμών ενοποίησης και διεπαφής χρήστη θα πρέπει να μειωθεί στο απαραίτητο ελάχιστο. Το άτομο σε αυτήν την αλυσίδα είναι ο πιο ακριβός, πιο αργός και αναξιόπιστος πόρος, επομένως βρίσκεται στο τέλος και εκτελεί εργασία μόνο εάν τα προηγούμενα στάδια δεν βρήκαν ελαττώματα. Ωστόσο, σύμφωνα με τις ίδιες αρχές, ο αγωγός είναι κατασκευασμένος σε μέρη που δεν σχετίζονται άμεσα με τη δοκιμή!
Θα ήθελα να προσφέρω μια αναλογία με τη μορφή ενός συστήματος φιλτραρίσματος νερού πολλαπλών σταδίων. Στην είσοδο παρέχεται βρώμικο νερό (αλλάζει με ελαττώματα), στην έξοδο πρέπει να έχουμε καθαρό νερό, στο οποίο εξαλείφονται όλοι οι ανεπιθύμητοι ρύποι.
Φίλτρο πολλαπλών σταδίων. Πηγή:
Όπως γνωρίζετε, τα φίλτρα καθαρισμού έχουν σχεδιαστεί με τέτοιο τρόπο ώστε κάθε επόμενος καταρράκτης να μπορεί να φιλτράρει ένα όλο και μικρότερο κλάσμα ρύπων. Ταυτόχρονα, οι καταρράκτες πιο χονδροειδών καθαρισμού έχουν υψηλότερη απόδοση και χαμηλότερο κόστος. Στην αναλογία μας, αυτό σημαίνει ότι οι πύλες ποιότητας εισόδου είναι πιο γρήγορες, απαιτούν λιγότερη προσπάθεια για την εκκίνηση και είναι οι ίδιες πιο ανεπιτήδευτες στη λειτουργία - και αυτή είναι ακριβώς η σειρά με την οποία είναι ενσωματωμένες. Ο ρόλος της στατικής ανάλυσης, η οποία, όπως καταλαβαίνουμε τώρα, είναι ικανή να εξαλείψει μόνο τα πιο σοβαρά ελαττώματα, είναι ο ρόλος της σχάρας-«λάσπης» στην αρχή του καταρράκτη του φίλτρου.
Η στατική ανάλυση από μόνη της δεν βελτιώνει την ποιότητα του τελικού προϊόντος, όπως μια «παγίδα λάσπης» δεν κάνει το νερό πόσιμο. Και όμως, από κοινού με άλλα στοιχεία του μεταφορέα, η σημασία του είναι προφανής. Αν και σε ένα φίλτρο πολλαπλών σταδίων, τα στάδια εξόδου είναι δυνητικά ικανά να συλλάβουν τα πάντα όπως τα στάδια εισόδου, είναι σαφές σε ποιες συνέπειες θα έχει μια προσπάθεια να τα βγάλουμε πέρα με μόνο λεπτά στάδια καθαρισμού, χωρίς στάδια εισόδου.
Ο σκοπός του "συλλέκτη λάσπης" είναι να ξεφορτώσει τους επόμενους καταρράκτες από τη σύλληψη πολύ χονδροειδών ελαττωμάτων. Για παράδειγμα, τουλάχιστον, ένας αναθεωρητής κώδικα δεν πρέπει να αποσπάται από λάθος μορφοποιημένο κώδικα και παραβίαση καθιερωμένων κανόνων κωδικοποίησης (όπως επιπλέον παρενθέσεις ή πολύ βαθιά ένθετα κλαδιά). Σφάλματα όπως το NPE θα πρέπει να εντοπιστούν από δοκιμές μονάδας, αλλά εάν ακόμη και πριν από τη δοκιμή ο αναλυτής μας υποδείξει ότι το σφάλμα πρέπει αναπόφευκτα να συμβεί, αυτό θα επιταχύνει σημαντικά τη διόρθωσή του.
Νομίζω ότι είναι πλέον ξεκάθαρο γιατί η στατική ανάλυση δεν βελτιώνει την ποιότητα ενός προϊόντος εάν χρησιμοποιείται περιστασιακά και θα πρέπει να χρησιμοποιείται συνεχώς για να φιλτράρει τις αλλαγές με σοβαρά ελαττώματα. Το να ρωτάτε εάν η χρήση στατικού αναλυτή θα βελτιώσει την ποιότητα του προϊόντος σας είναι περίπου ισοδύναμο με το ερώτημα "Θα βελτιωθεί η ποιότητα του πόσιμου νερού που λαμβάνεται από μια βρώμικη λίμνη εάν περάσει από ένα σουρωτήρι;"
Υλοποίηση σε έργο παλαιού τύπου
Ένα σημαντικό πρακτικό ερώτημα: πώς να εισαγάγετε τη στατική ανάλυση στη διαδικασία της συνεχούς ολοκλήρωσης ως «πύλη ποιότητας»; Στην περίπτωση των αυτόματων δοκιμών, όλα είναι προφανή: υπάρχει ένα σύνολο δοκιμών, η αποτυχία οποιουδήποτε από αυτά είναι επαρκής λόγος για να πιστεύουμε ότι το συγκρότημα δεν πέρασε την πύλη ποιότητας. Μια προσπάθεια εγκατάστασης μιας πύλης με τον ίδιο τρόπο που βασίζεται στα αποτελέσματα της στατικής ανάλυσης αποτυγχάνει: υπάρχουν πάρα πολλές προειδοποιήσεις ανάλυσης στον κώδικα παλαιού τύπου, δεν θέλετε να τις αγνοήσετε εντελώς, αλλά είναι επίσης αδύνατο να σταματήσετε την παράδοση ενός προϊόν μόνο και μόνο επειδή περιέχει προειδοποιήσεις αναλυτή.
Όταν χρησιμοποιείται για πρώτη φορά, ο αναλυτής δημιουργεί έναν τεράστιο αριθμό προειδοποιήσεων για οποιοδήποτε έργο, η συντριπτική πλειονότητα των οποίων δεν σχετίζεται με τη σωστή λειτουργία του προϊόντος. Είναι αδύνατο να διορθωθούν όλα αυτά τα σχόλια ταυτόχρονα και πολλά από αυτά δεν είναι απαραίτητα. Εξάλλου, γνωρίζουμε ότι το προϊόν μας στο σύνολό του λειτουργεί, ακόμη και πριν από την εισαγωγή της στατικής ανάλυσης!
Ως αποτέλεσμα, πολλοί άνθρωποι περιορίζονται στην επεισοδιακή χρήση στατικής ανάλυσης ή τη χρησιμοποιούν μόνο σε λειτουργία ενημέρωσης, όταν η αναφορά του αναλυτή απλώς εκδίδεται κατά τη συναρμολόγηση. Αυτό ισοδυναμεί με την απουσία οποιασδήποτε ανάλυσης, γιατί αν έχουμε ήδη πολλές προειδοποιήσεις, τότε η εμφάνιση άλλης (όσο σοβαρή κι αν είναι) όταν αλλάζει ο κωδικός περνά απαρατήρητη.
Είναι γνωστοί οι ακόλουθοι τρόποι εισαγωγής ποιοτικών πυλών:
- Ορίζει ένα όριο στον συνολικό αριθμό προειδοποιήσεων ή τον αριθμό των προειδοποιήσεων διαιρεμένο με τον αριθμό των γραμμών κώδικα. Αυτό δεν λειτουργεί καλά, επειδή μια τέτοια πύλη παραλείπει ελεύθερα αλλαγές με νέα ελαττώματα μέχρι να ξεπεραστεί το όριο τους.
- Διορθώστε, σε κάποιο σημείο, όλες τις παλιές προειδοποιήσεις στον κώδικα ως αγνοημένες και αποτυχία της κατασκευής όταν εμφανίζονται νέες προειδοποιήσεις. Αυτή η λειτουργία παρέχεται από το PVS-studio και ορισμένους διαδικτυακούς πόρους, όπως το Codacy. Δεν είχα την ευκαιρία να δουλέψω στο PVS-studio, όσον αφορά την εμπειρία μου με την Codacy, το κύριο πρόβλημα τους είναι ότι ο ορισμός του τι είναι "παλιό" και τι είναι "νέο" είναι ένας αρκετά περίπλοκος αλγόριθμος που δεν λειτουργεί πάντα σωστά, ειδικά εάν τα αρχεία έχουν τροποποιηθεί ή μετονομαστεί σε μεγάλο βαθμό. Στη μνήμη μου, η Codacy μπορούσε να παραλείψει νέες προειδοποιήσεις σε ένα αίτημα έλξης και ταυτόχρονα να μην παρακάμψει ένα αίτημα έλξης λόγω προειδοποιήσεων που δεν σχετίζονταν με αλλαγές στον κώδικα αυτού του PR.
- Κατά τη γνώμη μου, η πιο αποτελεσματική λύση περιγράφεται στο βιβλίο μέθοδος «καστάνιας». Η κύρια ιδέα είναι ότι μια ιδιότητα κάθε έκδοσης είναι ο αριθμός των προειδοποιήσεων στατικής ανάλυσης και επιτρέπονται μόνο αλλαγές που δεν αυξάνουν τον συνολικό αριθμό προειδοποιήσεων.
Αναστολεύς
Δουλεύει κάπως έτσι:
- Στο αρχικό στάδιο, υλοποιείται μια εγγραφή στα μεταδεδομένα απελευθέρωσης του αριθμού των προειδοποιήσεων στον κώδικα που βρέθηκαν από τους αναλυτές. Έτσι, όταν δημιουργείτε upstream, ο διαχειριστής του αποθετηρίου σας γράφεται όχι απλώς "έκδοση 7.0.2", αλλά "έκδοση 7.0.2 που περιέχει 100500 προειδοποιήσεις στυλ ελέγχου". Εάν χρησιμοποιείτε έναν προηγμένο διαχειριστή αποθετηρίου (όπως το Artifactory), είναι εύκολο να αποθηκεύσετε τέτοια μεταδεδομένα σχετικά με την κυκλοφορία σας.
- Τώρα κάθε αίτημα έλξης κατά την κατασκευή συγκρίνει τον αριθμό των προειδοποιήσεων που λαμβάνει με τον αριθμό στην τρέχουσα έκδοση. Εάν το PR οδηγεί σε αύξηση αυτού του αριθμού, τότε ο κωδικός δεν περνά την πύλη ποιότητας στη στατική ανάλυση. Εάν ο αριθμός των προειδοποιήσεων μειωθεί ή δεν αλλάξει, τότε περνάει.
- Στην επόμενη έκδοση, ο επανυπολογισμένος αριθμός προειδοποιήσεων θα επανέλθει στα μεταδεδομένα κυκλοφορίας.
Έτσι σιγά σιγά, αλλά σταθερά (όπως με μια καστάνια), ο αριθμός των προειδοποιήσεων θα τείνει στο μηδέν. Φυσικά, το σύστημα μπορεί να ξεγελαστεί εισάγοντας μια νέα προειδοποίηση, αλλά διορθώνοντας την προειδοποίηση κάποιου άλλου. Αυτό είναι φυσιολογικό, γιατί μακροπρόθεσμα δίνει το αποτέλεσμα: οι προειδοποιήσεις διορθώνονται, κατά κανόνα, όχι μία προς μία, αλλά αμέσως από μια ομάδα συγκεκριμένου τύπου και όλες οι προειδοποιήσεις που εξαλείφονται εύκολα εξαλείφονται γρήγορα.
Αυτό το γράφημα δείχνει τον συνολικό αριθμό των προειδοποιήσεων Checkstyle για έξι μήνες λειτουργίας μιας τέτοιας "καστάνιας". . Ο αριθμός των προειδοποιήσεων έχει μειωθεί κατά μια τάξη μεγέθους, και αυτό συνέβη φυσικά, παράλληλα με την ανάπτυξη του προϊόντος!
Χρησιμοποιώ μια τροποποιημένη έκδοση αυτής της μεθόδου, μετρώντας ξεχωριστά τις προειδοποιήσεις ανά ενότητα έργου και εργαλείο ανάλυσης, καταλήγοντας σε ένα αρχείο YAML με μεταδεδομένα συναρμολόγησης που μοιάζει κάπως έτσι:
celesta-sql:
checkstyle: 434
spotbugs: 45
celesta-core:
checkstyle: 206
spotbugs: 13
celesta-maven-plugin:
checkstyle: 19
spotbugs: 0
celesta-unit:
checkstyle: 0
spotbugs: 0
Σε οποιοδήποτε προηγμένο σύστημα CI, μια καστάνια μπορεί να εφαρμοστεί για οποιαδήποτε εργαλεία στατικής ανάλυσης χωρίς να βασίζεται σε πρόσθετα και εργαλεία τρίτων. Κάθε ένας από τους αναλυτές παράγει την αναφορά του σε ένα απλό κείμενο ή μορφή XML που είναι εύκολο να αναλυθεί. Απομένει να καταχωρήσετε μόνο την απαραίτητη λογική στο σενάριο CI. Μπορείτε να δείτε πώς εφαρμόζεται αυτό στα έργα ανοιχτού κώδικα που βασίζονται στο Jenkins και το Artifactory, μπορείτε ή . Και τα δύο παραδείγματα εξαρτώνται από τη βιβλιοθήκη : μέθοδος countWarnings() μετράει ετικέτες xml σε αρχεία που δημιουργούνται από Checkstyle και Spotbugs με τον συνηθισμένο τρόπο και compareWarningMaps() εφαρμόζει την ίδια καστάνια, ρίχνοντας ένα σφάλμα όταν αυξάνεται ο αριθμός των προειδοποιήσεων σε οποιαδήποτε από τις κατηγορίες.
Μια ενδιαφέρουσα εφαρμογή καστάνιας είναι δυνατή για ορθογραφική ανάλυση σχολίων, κυριολεκτικά κειμένου και τεκμηρίωση χρησιμοποιώντας aspell. Όπως γνωρίζετε, κατά τον ορθογραφικό έλεγχο, δεν είναι όλες οι άγνωστες λέξεις στο τυπικό λεξικό λανθασμένες, μπορούν να προστεθούν στο λεξικό χρήστη. Εάν κάνετε το λεξικό χρήστη μέρος του πηγαίου κώδικα του έργου, τότε η πύλη ποιότητας ορθογραφίας μπορεί να διαμορφωθεί ως εξής: εκτέλεση aspell με το τυπικό και λεξικό χρήστη δεν βρείτε ορθογραφικά λάθη.
Σχετικά με τη σημασία της επιδιόρθωσης της έκδοσης του αναλυτή
Συμπερασματικά, θα πρέπει να σημειωθεί το εξής: ανεξάρτητα από το πώς εφαρμόζετε την ανάλυση στον αγωγό παράδοσης, η έκδοση του αναλυτή πρέπει να διορθωθεί. Εάν επιτρέψετε στον αναλυτή να ενημερώνεται αυθόρμητα, τότε κατά τη δημιουργία του επόμενου αιτήματος έλξης, μπορεί να "προκύψουν" νέα ελαττώματα, τα οποία δεν σχετίζονται με αλλαγές κώδικα, αλλά σχετίζονται με το γεγονός ότι ο νέος αναλυτής είναι απλώς σε θέση να βρει περισσότερα ελαττώματα - και αυτό θα διακόψει τη διαδικασία αποδοχής των αιτημάτων έλξης. Η αναβάθμιση του αναλυτή πρέπει να είναι μια συνειδητή ενέργεια. Ωστόσο, η σκληρή επιδιόρθωση της έκδοσης κάθε εξαρτήματος συναρμολόγησης είναι μια απαραίτητη προϋπόθεση γενικά και ένα θέμα για ξεχωριστή συζήτηση.
Ευρήματα
- Η στατική ανάλυση δεν θα βρει σφάλματα για εσάς και δεν θα βελτιώσει την ποιότητα του προϊόντος σας ως αποτέλεσμα μιας μόνο εφαρμογής. Το μόνο θετικό αποτέλεσμα στην ποιότητα είναι η συνεχής χρήση του κατά τη διαδικασία παράδοσης.
- Η εύρεση σφαλμάτων δεν είναι καθόλου το κύριο καθήκον της ανάλυσης, η συντριπτική πλειονότητα των χρήσιμων λειτουργιών είναι διαθέσιμες σε εργαλεία ανοιχτού κώδικα.
- Εφαρμόστε πύλες ποιότητας με βάση τα αποτελέσματα της στατικής ανάλυσης στο πρώτο κιόλας στάδιο του αγωγού παράδοσης, χρησιμοποιώντας μια καστάνια για κωδικό παλαιού τύπου.
παραπομπές
- αναφορά για διαφορετικές μεθόδους ανάλυσης κώδικα (όχι μόνο στατικές!)
Πηγή: www.habr.com