Υπάρχουν πολλές συζητήσεις, άρθρα και ιστολόγια σχετικά με το θέμα της ποιότητας του κώδικα. Λένε οι άνθρωποι - χρησιμοποιήστε τεχνικές βάσει δοκιμής! Οι δοκιμές είναι «πρέπει να έχουν» για να ξεκινήσουν οποιαδήποτε αναδιαμόρφωση! Όλα αυτά είναι ωραία, αλλά είναι το 2016 και υπάρχει ακόμα ένας τεράστιος όγκος προϊόντων και βάσεων κώδικα που βρίσκονται ακόμη σε παραγωγή που δημιουργήθηκαν πριν από δέκα, δεκαπέντε ή και είκοσι χρόνια. Δεν είναι μυστικό ότι πολλοί από αυτούς διαθέτουν παλαιού κώδικα με χαμηλή δοκιμαστική κάλυψη.

Ενώ θα ήθελα να είμαι πάντα στην κορυφή, ή ακόμα και στην αιμορραγία, στην άκρη του τεχνολογικού κόσμου - που ασχολούνται με νέα δροσερά έργα και τεχνολογίες - δυστυχώς δεν είναι πάντα δυνατό και συχνά πρέπει να ασχοληθώ με παλιά συστήματα. Μου αρέσει να λέω ότι όταν αναπτύσσετε από το μηδέν, ενεργείτε ως δημιουργός, κυριαρχώντας σε νέο θέμα. Όμως, όταν εργάζεστε στον κώδικα παλαιού τύπου, είστε περισσότερο σαν χειρουργός - ξέρετε πώς λειτουργεί το σύστημα γενικά, αλλά ποτέ δεν ξέρετε με βεβαιότητα εάν ο ασθενής θα επιβιώσει από την 'επέμβαση' σας. Και δεδομένου ότι είναι ο παλαιός κώδικας, δεν υπάρχουν πολλές ενημερωμένες δοκιμές για τις οποίες μπορείτε να βασιστείτε. Αυτό σημαίνει ότι πολύ συχνά ένα από τα πρώτα βήματα είναι να το καλύψετε με δοκιμές. Πιο συγκεκριμένα, όχι μόνο για την παροχή κάλυψης, αλλά για την ανάπτυξη στρατηγικής δοκιμαστικής κάλυψης.

Ξεχάστε την κάλυψη 100%. Δοκιμάστε πιο έξυπνα προσδιορίζοντας τάξεις που είναι πιο πιθανό να σπάσουν. Τιτίβισμα

Βασικά, αυτό που χρειαζόμουν για να προσδιορίσω ήταν ποια μέρη (τάξεις / πακέτα) του συστήματος χρειαζόμασταν να καλύψουμε με δοκιμές πρώτα, όπου χρειαζόμασταν δοκιμές μονάδας, όπου οι δοκιμές ολοκλήρωσης θα ήταν πιο χρήσιμες κ.λπ. Υπάρχουν βεβαίως πολλοί τρόποι να Προσεγγίστε αυτόν τον τύπο ανάλυσης και αυτό που έχω χρησιμοποιήσει μπορεί να μην είναι το καλύτερο, αλλά είναι ένα είδος αυτόματης προσέγγισης. Μόλις εφαρμοστεί η προσέγγισή μου, χρειάζεται ελάχιστος χρόνος για να γίνει η ίδια η ανάλυση και, το πιο σημαντικό, φέρνει κάποια διασκέδαση στην ανάλυση κώδικα παλαιού τύπου.

Η βασική ιδέα εδώ είναι να αναλύσουμε δύο μετρήσεις - σύζευξη (δηλ. Σύζευξη προσαγωγής ή CA) και πολυπλοκότητα (δηλ. Κυκλική πολυπλοκότητα).

Η πρώτη μετρά πόσες τάξεις χρησιμοποιούν την τάξη μας, οπότε μας λέει ουσιαστικά πόσο κοντά είναι μια συγκεκριμένη τάξη στην καρδιά του συστήματος. Όσο περισσότερα μαθήματα υπάρχουν που χρησιμοποιούν την τάξη μας, τόσο πιο σημαντικό είναι να το καλύψουμε με δοκιμές.

Από την άλλη πλευρά, εάν μια τάξη είναι πολύ απλή (π.χ. περιέχει μόνο σταθερές), τότε ακόμα κι αν χρησιμοποιείται από πολλά άλλα μέρη του συστήματος, δεν είναι σχεδόν τόσο σημαντικό να δημιουργήσετε μια δοκιμή για. Εδώ μπορεί να βοηθήσει η δεύτερη μέτρηση. Εάν μια τάξη περιέχει πολλή λογική, η κυκλωματική πολυπλοκότητα θα είναι υψηλή.

Η ίδια λογική μπορεί επίσης να εφαρμοστεί αντίστροφα. δηλαδή, ακόμη και αν μια κλάση δεν χρησιμοποιείται από πολλές κατηγορίες και αντιπροσωπεύει μόνο μία συγκεκριμένη περίπτωση χρήσης, εξακολουθεί να έχει νόημα να την καλύψουμε με δοκιμές εάν η εσωτερική λογική της είναι περίπλοκη.

Υπάρχει όμως μια προειδοποίηση: ας πούμε ότι έχουμε δύο κατηγορίες - μία με την CA 100 και την πολυπλοκότητα 2 και την άλλη με την CA 60 και την πολυπλοκότητα 20. Ακόμα κι αν το άθροισμα των μετρήσεων είναι υψηλότερο για το πρώτο πρέπει σίγουρα να καλύψουμε το δεύτερο πρώτο. Αυτό συμβαίνει επειδή η πρώτη τάξη χρησιμοποιείται από πολλές άλλες τάξεις, αλλά δεν είναι πολύ περίπλοκη. Από την άλλη πλευρά, η δεύτερη τάξη χρησιμοποιείται επίσης από πολλές άλλες κατηγορίες, αλλά είναι σχετικά πιο περίπλοκη από την πρώτη τάξη.

Συνοπτικά: πρέπει να προσδιορίσουμε τάξεις με υψηλή πολυπλοκότητα CA και Cyclomatic. Σε μαθηματικούς όρους, απαιτείται μια λειτουργία φυσικής κατάστασης που μπορεί να χρησιμοποιηθεί ως βαθμολογία - f (CA, Complexity) - των οποίων οι τιμές αυξάνονται μαζί με την CA και την πολυπλοκότητα.

Σε γενικές γραμμές, οι τάξεις με τις μικρότερες διαφορές μεταξύ των δύο μετρήσεων θα πρέπει να έχουν την υψηλότερη προτεραιότητα για κάλυψη δοκιμών.

Η εύρεση εργαλείων για τον υπολογισμό της CA και της πολυπλοκότητας για ολόκληρη τη βάση κώδικα, και η παροχή ενός απλού τρόπου εξαγωγής αυτών των πληροφοριών σε μορφή CSV, αποδείχθηκε πρόκληση. Κατά την αναζήτησή μου, συνάντησα δύο δωρεάν εργαλεία, οπότε θα ήταν άδικο να μην τα αναφέρω:

• Μετρήσεις ζεύξης: www.spinellis.gr/sw/ckjm/
• Περίπλοκο: cyvis.sourceforge.net/

Λίγο μαθηματικά

Το κύριο πρόβλημα εδώ είναι ότι έχουμε δύο κριτήρια - CA και Cyclomatic πολυπλοκότητα - γι 'αυτό πρέπει να τα συνδυάσουμε και να μετατρέψουμε σε μία βαθμίδα. Εάν είχαμε μια ελαφρώς διαφορετική εργασία - π.χ. να βρούμε μια τάξη με το χειρότερο συνδυασμό των κριτηρίων μας - θα είχαμε ένα κλασικό πρόβλημα βελτιστοποίησης πολλαπλών στόχων:

Θα πρέπει να βρούμε ένα σημείο στο λεγόμενο μέτωπο Pareto (κόκκινο στην παραπάνω εικόνα). Αυτό που είναι ενδιαφέρον για το σύνολο Pareto είναι ότι κάθε σημείο στο σετ είναι μια λύση για την εργασία βελτιστοποίησης. Κάθε φορά που κινούμαστε κατά μήκος της κόκκινης γραμμής πρέπει να κάνουμε συμβιβασμό μεταξύ των κριτηρίων μας - εάν κάποιος γίνει καλύτερος ο άλλος χειροτερεύει. Αυτό ονομάζεται Scalarization και το τελικό αποτέλεσμα εξαρτάται από το πώς το κάνουμε.

Υπάρχουν πολλές τεχνικές που μπορούμε να χρησιμοποιήσουμε εδώ. Κάθε ένα έχει τα δικά του πλεονεκτήματα και μειονεκτήματα. Ωστόσο, τα πιο δημοφιλή είναι γραμμική αποφλοίωση και αυτό που βασίζεται σε ένα σημείο αναφοράς . Το γραμμικό είναι το πιο εύκολο. Η λειτουργία φυσικής κατάστασης θα μοιάζει με γραμμικό συνδυασμό CA και Complexity:

f (CA, Πολυπλοκότητα) = A × CA + B × Πολυπλοκότητα

όπου τα Α και Β είναι μερικοί συντελεστές.

Το σημείο που αντιπροσωπεύει μια λύση στο πρόβλημα βελτιστοποίησης θα βρίσκεται στη γραμμή (μπλε στην παρακάτω εικόνα). Πιο συγκεκριμένα, θα βρίσκεται στη διασταύρωση της μπλε γραμμής και του κόκκινου εμπρός Pareto. Το αρχικό μας πρόβλημα δεν είναι ακριβώς ένα πρόβλημα βελτιστοποίησης. Αντίθετα, πρέπει να δημιουργήσουμε μια συνάρτηση κατάταξης. Ας εξετάσουμε δύο τιμές της συνάρτησης κατάταξής μας, βασικά δύο τιμές στη στήλη Κατάταξη:

R1 = A ∗ CA + B ∗ Πολυπλοκότητα και R2 = A ∗ CA + B ∗ Πολυπλοκότητα

Και οι δύο τύποι που γράφτηκαν παραπάνω είναι εξισώσεις γραμμών, επιπλέον αυτές οι γραμμές είναι παράλληλες. Λαμβάνοντας υπόψη περισσότερες τιμές κατάταξης, θα λάβουμε περισσότερες γραμμές και συνεπώς περισσότερα σημεία όπου η γραμμή Pareto τέμνει με τις (διακεκομμένες) μπλε γραμμές. Αυτά τα σημεία θα είναι τάξεις που αντιστοιχούν σε μια συγκεκριμένη τιμή κατάταξης.

Δυστυχώς, υπάρχει ένα πρόβλημα με αυτήν την προσέγγιση. Για οποιαδήποτε γραμμή (τιμή κατάταξης), θα έχουμε βαθμούς με πολύ μικρή CA και πολύ μεγάλη πολυπλοκότητα (και αντίστροφα). Αυτό βάζει αμέσως σημεία με μεγάλη διαφορά μεταξύ των μετρικών τιμών στην κορυφή της λίστας που είναι ακριβώς αυτό που θέλαμε να αποφύγουμε.

Ο άλλος τρόπος για να γίνει η scalarizing βασίζεται στο σημείο αναφοράς. Το σημείο αναφοράς είναι ένα σημείο με τις μέγιστες τιμές και των δύο κριτηρίων:

(μέγιστο (CA), max (πολυπλοκότητα))

Η λειτουργία φυσικής κατάστασης θα είναι η απόσταση μεταξύ του σημείου αναφοράς και των σημείων δεδομένων:

f (CA, Πολυπλοκότητα) = √ ((CA - CA)²+ (Πολυπλοκότητα − Πολυπλοκότητα)²)

Μπορούμε να σκεφτούμε αυτήν τη λειτουργία γυμναστικής ως κύκλο με το κέντρο στο σημείο αναφοράς. Η ακτίνα σε αυτήν την περίπτωση είναι η τιμή της κατάταξης. Η λύση στο πρόβλημα βελτιστοποίησης θα είναι το σημείο όπου ο κύκλος αγγίζει το μέτωπο του Pareto. Η λύση στο αρχικό πρόβλημα θα είναι σύνολα σημείων που αντιστοιχούν στις διαφορετικές ακτίνες κύκλου, όπως φαίνεται στην παρακάτω εικόνα (τμήματα κύκλων για διαφορετικές τάξεις εμφανίζονται ως μπλε καμπύλες).

Αυτή η προσέγγιση ασχολείται καλύτερα με ακραίες τιμές, αλλά εξακολουθούν να υπάρχουν δύο ζητήματα: Πρώτον - Θα ήθελα να έχω περισσότερα σημεία κοντά στα σημεία αναφοράς για να ξεπεράσουμε καλύτερα το πρόβλημα που έχουμε αντιμετωπίσει με τον γραμμικό συνδυασμό. Δεύτερον - Η πολυπλοκότητα CA και Cyclomatic είναι εγγενώς διαφορετική και έχει καθοριστεί διαφορετικές τιμές, οπότε πρέπει να τις ομαλοποιήσουμε (π.χ. έτσι ώστε όλες οι τιμές και των δύο μετρήσεων να είναι από 1 έως 100).

Εδώ είναι ένα μικρό τέχνασμα που μπορούμε να εφαρμόσουμε για την επίλυση του πρώτου ζητήματος - αντί να κοιτάμε την ΑΠ και την Κυκλωματική Πολυπλοκότητα, μπορούμε να δούμε τις ανεστραμμένες τιμές τους. Το σημείο αναφοράς σε αυτήν την περίπτωση θα είναι (0,0). Για να λύσουμε το δεύτερο ζήτημα, μπορούμε απλώς να ομαλοποιήσουμε τις μετρήσεις χρησιμοποιώντας την ελάχιστη τιμή. Δείτε πώς φαίνεται:

Ανεστραμμένη και κανονικοποιημένη πολυπλοκότητα - NormComplexity:

(1 + λεπτό (πολυπλοκότητα)) / (1 + πολυπλοκότητα) ∗ 100

Ανεστραμμένη και κανονικοποιημένη ΑΠ - NormCA:

(1 + λεπτό (CA)) / (1 + CA) ∗ 100

Σημείωση: Πρόσθεσα 1 για να βεβαιωθώ ότι δεν υπάρχει διαίρεση με 0.

Η παρακάτω εικόνα δείχνει ένα διάγραμμα με τις ανεστραμμένες τιμές:

Τελική κατάταξη

Ερχόμαστε τώρα στο τελευταίο βήμα - υπολογίζοντας την κατάταξη. Όπως αναφέρθηκε, χρησιμοποιώ τη μέθοδο σημείου αναφοράς, οπότε το μόνο που πρέπει να κάνουμε είναι να υπολογίσουμε το μήκος του διανύσματος, να το ομαλοποιήσουμε και να το κάνουμε να ανέβει με τη σημασία μιας δημιουργίας δοκιμής μονάδας για μια τάξη. Εδώ είναι ο τελικός τύπος:

Κατάταξη (NormComplexity, NormCA) = 100 - √ (NormComplexity²+ NormCA²) / √2

Περισσότερες στατιστικές

Υπάρχει μια ακόμη σκέψη που θα ήθελα να προσθέσω, αλλά ας ρίξουμε μια πρώτη ματιά σε ορισμένα στατιστικά στοιχεία. Ακολουθεί ένα ιστόγραμμα των μετρήσεων ζεύξης:

Αυτό που είναι ενδιαφέρον για αυτήν την εικόνα είναι ο αριθμός των τάξεων με χαμηλό CA (0-2). Τα μαθήματα με CA 0 είτε δεν χρησιμοποιούνται καθόλου είτε είναι υπηρεσίες ανώτατου επιπέδου. Αυτά αντιπροσωπεύουν ΦΩΤΙΑ τελικά σημεία, οπότε είναι ωραίο να έχουμε πολλά από αυτά. Όμως, οι τάξεις με CA 1 είναι αυτές που χρησιμοποιούνται άμεσα από τα τελικά σημεία και έχουμε περισσότερες από αυτές τις τάξεις από τα τελικά σημεία. Τι σημαίνει αυτό από την άποψη της αρχιτεκτονικής / του σχεδιασμού;

Σε γενικές γραμμές, σημαίνει ότι έχουμε ένα είδος προσέγγισης προσανατολισμένου στο σενάριο - γράφουμε κάθε επιχειρηματική περίπτωση ξεχωριστά (δεν μπορούμε πραγματικά να επαναχρησιμοποιήσουμε τον κώδικα καθώς οι επιχειρηματικές περιπτώσεις είναι πολύ διαφορετικές). Εάν συμβαίνει αυτό, τότε είναι σίγουρα ένα μυρωδιά κώδικα και πρέπει να κάνουμε επαναπροσδιορισμό. Διαφορετικά, αυτό σημαίνει ότι η συνοχή του συστήματός μας είναι χαμηλή, οπότε χρειαζόμαστε επίσης αναδιαμόρφωση, αλλά αρχιτεκτονική αναδιαμόρφωση αυτή τη φορά.

πλαισίου πλήρους στοίβας node js

Πρόσθετες χρήσιμες πληροφορίες που μπορούμε να λάβουμε από το παραπάνω ιστόγραμμα είναι ότι μπορούμε να φιλτράρουμε εντελώς τις τάξεις με χαμηλή σύζευξη (CA στο {0,1}) από τη λίστα των τάξεων που είναι κατάλληλες για κάλυψη με δοκιμές μονάδας. Τα ίδια μαθήματα, ωστόσο, είναι καλοί υποψήφιοι για την ολοκλήρωση / λειτουργικές δοκιμές.

Μπορείτε να βρείτε όλα τα σενάρια και τους πόρους που έχω χρησιμοποιήσει σε αυτό το αποθετήριο GitHub: ashalitkin / code-base-stats .

Λειτουργεί πάντα;

Οχι απαραίτητα. Πρώτα απ 'όλα αφορά στατική ανάλυση και όχι χρόνο εκτέλεσης. Εάν μια τάξη συνδέεται από πολλές άλλες τάξεις, μπορεί να είναι ένδειξη ότι χρησιμοποιείται σε μεγάλο βαθμό, αλλά δεν είναι πάντα αλήθεια. Για παράδειγμα, δεν γνωρίζουμε εάν η λειτουργικότητα χρησιμοποιείται πολύ από τους τελικούς χρήστες. Δεύτερον, εάν ο σχεδιασμός και η ποιότητα του συστήματος είναι αρκετά καλές, τότε πιθανότατα διαφορετικά μέρη / στρώματα του αποσυνδέονται μέσω διεπαφών, οπότε η στατική ανάλυση της ΑΠ δεν θα μας δώσει μια πραγματική εικόνα. Υποθέτω ότι είναι ένας από τους κύριους λόγους για τους οποίους η CA δεν είναι τόσο δημοφιλής σε εργαλεία όπως το Sonar. Ευτυχώς, είναι εντάξει για εμάς αφού, αν θυμάστε, μας ενδιαφέρει να το εφαρμόσουμε ειδικά σε παλιές άσχημες βάσεις κώδικα.

Γενικά, θα έλεγα ότι η ανάλυση χρόνου εκτέλεσης θα έδινε πολύ καλύτερα αποτελέσματα, αλλά δυστυχώς είναι πολύ πιο δαπανηρή, χρονοβόρα και περίπλοκη, επομένως η προσέγγισή μας είναι μια δυνητικά χρήσιμη και εναλλακτική λύση χαμηλότερου κόστους.

Σχετίζεται με: Αρχή της ενιαίας ευθύνης: Μια συνταγή για εξαιρετικό κώδικα