Ως κατώτερος μηχανικός λογισμικού, πάντα παρακολούθησα σχόλια κώδικα που έλαβα για να μάθω πώς να γίνω καλύτερος κωδικοποιητής. Αλλά όταν ήρθε η ώρα να επιχειρήσω την πρώτη μου αναθεώρηση κώδικα, συνειδητοποίησα ότι η εμπειρία μου δεν είχε προετοιμάσει να είμαι στην άλλη πλευρά.
Έχω αναπτύξει μια σοβαρή περίπτωση συνδρόμου απατεώνας, που στρέφεται προς τα κάτω με ερωτήσεις: Πρέπει να σχολιάσω αυτή τη γραμμή κώδικα ή δεν αξίζει τον κόπο; Πρέπει να βρω άρθρα για να υποστηρίξω κάθε σχόλιο; Θα συντρίψω την τοποθεσία εγκρίνοντας αυτό; Θα με μισούν; Εντάξει, παραδέχομαι ότι έχω σπείρα πολύ γρήγορα. Αλλά αφού μίλησα σε μερικούς συναδέλφους, ήξερα ότι δεν ήμουν μόνος μου στις ανησυχίες μου.
Οι κατώτεροι μηχανικοί λογισμικού μπορούν να ριχτούν σε ανασκόπηση κώδικα με μια υπόθεση ανάλογη με την "ξέρετε πώς να διαβάσετε ένα βιβλίο για να ξέρετε πώς να γράψετε ένα βιβλίο, κάτι που δεν είναι αλήθεια", λέει ο Jessica Rudder, μηχανικός εμπειρίας στο GitHub.
Υπάρχουν προσδοκίες που έρχονται με την αναθεώρηση του κώδικα και η διαδικασία μπορεί να είναι γεμάτη νεύρα. Έτσι, συνέντευξη από επτά άλλους μηχανικούς λογισμικού για τη συλλογή συμβουλών για το πώς να οικοδομήσουμε μια νοοτροπία αναθεώρησης.
1. Σκεφτείτε για το συνολικό αντίκτυπο
Γενικά, ένα καλό αίτημα έλξης (PR) θα πρέπει να επηρεάζει μόνο ένα περιορισμένο μέρος του codebase. Ωστόσο, το περιορισμένο πεδίο δεν πρέπει να σας εμποδίζει να σκεφτείτε την αλλαγή κώδικα στο πλαίσιο του μεγαλύτερου κώδικα.
Ο Nigel Munoz, ένας πρώην μηχανικός πλήρους στοίβας στο The Muse και ένας τρέχων ανεξάρτητος μηχανικός λογισμικού, ενθαρρύνει τον κριτικό να σκεφτεί "πώς η αλλαγή αυτή επηρεάζει τη μεγαλύτερη και μικρότερη εικόνα." Λαμβάνοντας υπόψη τη μεγαλύτερη εικόνα περιλαμβάνει την εύρεση οποιουδήποτε τεχνικού χρέους - που επαναλαμβάνεται, δεν είναι αρθρωτή ή δεν τηρεί τις πιο πρόσφατες τυπικές συμβάσεις-καθώς και την ανάλυση τροποποιήσεων στην αρχιτεκτονική του κώδικα.
Ο Sam Donow, βασικός προγραμματιστής στο Hudson River Trading, πιστεύει ότι "δεν υπάρχει τίποτα πάρα πολύ μεγάλο ή πολύ μικρό για να σχολιάσει. Οι προτάσεις για μικρές βελτιώσεις θα μπορούσαν να οδηγήσουν σε μεγαλύτερες βελτιώσεις σε πολλά μέρη του κώδικα. "
Μπορείτε να χρησιμοποιήσετε ένα σχόλιο PR στο GitHub για να δώσετε θετικά σχόλια καθώς και να επισημάνετε πού ο κωδικός μπορεί να διαφέρει από τις τυπικές συμβάσεις του πλαισίου React.
Για παράδειγμα, κατά τη διάρκεια μιας από τις δικές μου αναθεωρήσεις κώδικα, έλαβα ένα σχόλιο ότι ορισμένες ιδιότητες σε ένα στοιχείο React ήταν συγκεχυμένες, γεγονός που προκάλεσε ευρύτερες ερωτήσεις σχετικά με τον τρόπο με τον οποίο χρησιμοποιήθηκε το στοιχείο. Τελικά, αφαιρέσα τις ιδιότητες από το αρχικό στοιχείο και δημιούργησα ξεχωριστό στοιχείο για να διευκρινίσω τη συμπεριφορά του καθενός και να εξασφαλίσω ότι και οι δύο θα μπορούσαν να χρησιμοποιηθούν σε περισσότερα μέρη.
2. Εξετάστε την ασφάλεια
Μην ξεχνάτε ότι κάποιες αλλαγές θα μπορούσαν να έχουν αντίκτυπο περισσότερο από το βασικό κώδικα. Το Rudder συνιστά να αξιολογηθεί εάν ένας χρήστης "θα μπορούσε να χρησιμοποιήσει αυτήν τη λειτουργία για να παρενοχλήσει κάποιον ή να καταχραστεί το σύστημα." Για παράδειγμα, εάν η νέα δυνατότητα στην αίτηση αναζήτησης περιλαμβάνει την καταχώρηση χρήστη, αναζητήστε SQL injection, πρόσβαση σε δεδομένα, scripting cross- άλλα ευπάθειες ασφαλείας.
3. Εστίαση στα σφάλματα
Οι συντρόφιστές σας, ανεξάρτητα από τον ρομποτικό τρόπο που φαίνονται, είναι ανθρώπινοι και οι άνθρωποι μπορούν να σπάσουν ή να ξεχάσουν λειτουργίες. Βεβαιωθείτε λοιπόν ότι "εξετάζετε τις δοκιμές με την ίδια σημασία με τον υπόλοιπο κώδικα", συμβουλεύει ο Abhishek Pillai, ένας τεχνολόγος στο Teachers Pay Teachers. "Θα αποτρέψουν νέα σφάλματα και θα χρησιμεύσουν ως μορφή τεκμηρίωσης σε οποιονδήποτε άλλον που εργάζεται σε αυτό στο μέλλον".
Η ανάγνωση των δοκιμών μπορεί να σας βοηθήσει να κατανοήσετε τη λειτουργικότητα μιας νέας λειτουργίας και να δείτε τις διάφορες περιπτώσεις που θα εισαγάγει, ενώ η ανάλυση των δοκιμών μπορεί να σας βοηθήσει να επισημάνετε τις περιπτώσεις που λείπουν και να βρείτε λειτουργίες που δεν περιέχονται σε αυτό το PR. Εάν δεν υπάρχουν δοκιμές που περιλαμβάνονται στην αλλαγή κώδικα και φαίνονται σχετικές, είναι σκόπιμο να τους ζητήσετε κατά την επανεξέταση.
Αλλά οι δοκιμές δεν είναι τα πάντα. «Μην βάζετε υπερβολική πίστη στο σύστημα», προειδοποιεί ο Donow. "Ακριβώς επειδή οι δοκιμές έτρεξαν δεν σημαίνει ότι δεν υπάρχουν σφάλματα."
Μπορεί επίσης να θέλετε να "τρέξετε την εφαρμογή τοπικά για να τη δοκιμάσετε λειτουργικά και να βεβαιωθείτε ότι λειτουργεί. Αν δεν λειτουργήσει, τότε δεν έχει νόημα να αναθεωρήσουμε περαιτέρω ", λέει ο Ryan Verner, προγραμματιστής λογισμικού στο 8ο φως. Αν και ορισμένοι αναθεωρητές δεν πιστεύουν ότι οι δοκιμές με μη αυτόματο έλεγχο θα πρέπει να αποτελούν μέρος της διαδικασίας αναθεώρησης του κώδικα - εν μέρει λόγω του χρόνου που χρειάζεται - ο Verner πιστεύει ότι είναι ένας γρήγορος τρόπος να προσδιορίσετε αν πρέπει να επενδύσετε περισσότερο χρόνο ανασκόπησης καθώς και μια στρατηγική για να μειώσετε την ανάπτυξη ενός συσσωρευμένου σφάλματος.
4. Να είσαι Team Player
Το κλισέ αποκτά νέα σημασία όταν πρόκειται να αναθεωρήσει τον κώδικα. "Πάρτε το χρόνο να αναθεωρήσετε γιατί είναι ο κώδικας βάσης του καθενός", λέει ο Verner, ο οποίος υποστηρίζει την αίσθηση της "συλλογικής ιδιοκτησίας". Εσείς, ως κριτής, θα πρέπει να εργαστείτε για να προστατεύσετε το συσσωρευμένο σφάλμα από το να μεγαλώνει με στόχο ομάδα λιγότερο εργασία κάτω από τη γραμμή.
Ο Pillai χρησιμοποιεί gifs για να γιορτάσει τις εγκεκριμένες και έτοιμες για συγχώνευση συμμαθητές του.
Την ίδια στιγμή, ο Charles Luxton, ένας τεχνολόγος στο The Muse, ενθαρρύνει τον κριτικό να κατανοήσει και να θυμάται τις προτεραιότητες της ομάδας. Με γρήγορες προσεγγίσεις προθεσμίες και διαφωνίες αφθονούν, μερικές φορές δημιουργώντας ένα στοιχείο για να κάνει για το backlog που εξασφαλίζει βελτιώσεις θα γίνουν στο μέλλον και να σχολιάσει τον εν λόγω κώδικα εντωμεταξύ είναι το Band-Aid που χρειάζεστε για να κρατήστε την ομάδα σας ευτυχισμένη.
Τέλος, αναρωτιέμαι αν ο κώδικας θα είχε νόημα σε κάποιον που μόλις προσχώρησε στην ομάδα και το διάβαζε μέσα στις πρώτες εβδομάδες θα βοηθήσει να κρατήσει τον κώδικα σας ευανάγνωστο και κατανοητό.
5. Χρησιμοποιήστε τη διαδικασία για τη μάθηση και την ανταλλαγή γνώσεων
Η διαδικασία επανεξέτασης δίνει σε όλους τους ενδιαφερόμενους τη δυνατότητα να αποκτήσουν περισσότερες γνώσεις σχετικά με τον κώδικα βάσης, τις γλώσσες, τα πλαίσια και τις βέλτιστες πρακτικές.
Ο Matt Jeffery, ένας επικεφαλής της τεχνολογίας στο The Muse, συμβουλεύει τον κριτή να "κατανοήσει τις αλλαγές αρχιτεκτονικά.Ένας τρόπος είναι να διαβάσετε τα ονόματα των αρχείων δεδομένου ότι βοηθούν να δώσουν ένα πλαίσιο.Για παράδειγμα, εάν κοιτάζετε μια αλλαγή στο στρώμα πρόσβασης δεδομένων ξέρετε ότι δεν έχετε σχέση με την επιχειρησιακή λογική ή το UI. "
Μπορείτε να χρησιμοποιήσετε ένα σχόλιο PR στο GitHub για να μοιραστείτε την τεκμηρίωση.
Όταν μαθαίνετε από τις αλλαγές κώδικα, έχετε επίσης την ευκαιρία να μοιραστείτε τη γνώση. "Είναι καλύτερο να εξηγήσετε τη γνώμη σας και να την υποστηρίξετε με την τεκμηρίωση", λέει ο Luxton. Οι σύνδεσμοι που παρέχετε σε αποδεικτικά στοιχεία και αξιόπιστα άρθρα όχι μόνο βοηθούν τον εξεταστή και τον συγγραφέα κώδικα να διερευνήσουν διαφορετικές προσεγγίσεις καθώς λαμβάνουν τελική απόφαση αλλά και να ενισχύσουν τις γνώσεις τους στον προγραμματισμό.
Ενώ κρατάτε υπόψη αυτές τις συμβουλές, θυμηθείτε ότι η αναθεώρηση είναι η κατάλληλη στιγμή για να ασκήσετε τις δεξιότητές σας. "Δώστε στους ανθρώπους το πλεονέκτημα της αμφιβολίας ότι σκέφτηκαν την προσέγγισή τους και να επισημάνουν διαφορετικές δυνατότητες προσπαθώντας να διαλύσουν την άμυνα", λέει ο Rudder. "Αφήνω τα σχόλιά μου σε ολόκληρο το κείμενο και ολοκληρώστε το σχόλιό σας - εδώ είναι αυτό που είναι υπέροχο, εδώ τι μπορεί να βελτιωθεί, εδώ πρέπει να αλλάξει πριν συγχωνευθεί".
Με αυτή την προσέγγιση, όχι μόνο θα προστατεύετε τη βάση δεδομένων σας από το χρέος τεχνολογίας, τις απειλές ασφαλείας και τα σφάλματα, αλλά θα χτίζετε επίσης την ομάδα σας.
