Αναθεώρηση κώδικα — τι είναι, πώς λειτουργεί το code review και ο έλεγχος PR

Τι είναι το code review

Code review — είναι η συστηματική εξέταση του κώδικα από συναδέλφους πριν από την ενσωμάτωσή του. Στο πλαίσιο του Git αυτό σημαίνει: ο προγραμματιστής δημιουργεί ένα pull request με αλλαγές, ορίζει αναθεωρητές και αυτοί μελετούν το diff, αφήνουν σχόλια και εκδίδουν ετυμηγορία. Ο αναθεωρητής μπορεί να ζητήσει αλλαγές (Request Changes), να εγκρίνει το PR (Approve) ή να αφήσει ένα γενικό σχόλιο.

Το code review έχει πέντε στόχους: βελτίωση της ποιότητας του κώδικα (εντοπισμός ελαττωμάτων πριν φτάσουν στην παραγωγή), διάδοση γνώσεων (ο αναθεωρητής μαθαίνει νέες προσεγγίσεις, ο συγγραφέας λαμβάνει ανατροφοδότηση), τήρηση προτύπων (έλεγχος συμμόρφωσης με το code style και αρχιτεκτονικές αποφάσεις), μείωση του bus factor (ο κώδικας δεν είναι γνωστός μόνο σε έναν προγραμματιστή) και οικοδόμηση κουλτούρας υπευθυνότητας (ο συγγραφέας γράφει πιο προσεκτικά, γνωρίζοντας ότι ο κώδικας θα ελεγχθεί).

Το αντίθετο του code review είναι το blind commit: ο προγραμματιστής ωθεί αλλαγές στον κοινό κλάδο χωρίς review. Αυτή η προσέγγιση επιτρέπεται μόνο σε έργα ενός χρήστη ή για επείγοντα hotfix με μεταγενέστερο review. Στην επαγγελματική ομαδική ανάπτυξη, το code review είναι υποχρεωτικό στάδιο για κάθε αλλαγή, συμπεριλαμβανομένων διορθώσεων τεκμηρίωσης και διαμόρφωσης.

Τι ελέγχεται στο code review

Το code review πρέπει να είναι συστηματικό, όχι χαοτικό. Οι έμπειροι αναθεωρητές ελέγχουν τον κώδικα με συγκεκριμένη σειρά: πρώτα αρχιτεκτονική και λογική, μετά δοκιμές, στη συνέχεια ασφάλεια και απόδοση, και στο τέλος — στυλ και ονομασία. Αυτή η σειρά εγγυάται ότι τα κρίσιμα προβλήματα θα παρατηρηθούν πριν κουραστεί ο αναθεωρητής.

Αρχιτεκτονική και λογική: λύνει ο κώδικας το πρόβλημα, υπάρχουν περιττές αφαιρέσεις, τηρούνται οι αρχές SOLID και DRY. Ο περίπλοκος κώδικας που είναι δύσκολο να κατανοηθεί με την πρώτη ανάγνωση — σήμα ότι απαιτεί αναδιάρθρωση. Ο αναθεωρητής πρέπει να βεβαιωθεί ότι ο κώδικας κάνει ακριβώς αυτό που καθορίζεται στην εργασία και δεν έχει παρενέργειες εκτός του πεδίου ευθύνης του.

Δοκιμές: καλύπτουν οι νέες δοκιμές όλα τα σενάρια — θετικά, αρνητικά, οριακές περιπτώσεις. Περνούν οι υπάρχουσες δοκιμές μετά τις αλλαγές. Υπάρχουν flaky δοκιμές που αποτυγχάνουν ασταθώς. Ασφάλεια: απουσία SQL injection, XSS, διαρροής ευαίσθητων δεδομένων μέσω αρχείων καταγραφής ή απαντήσεων API. Απόδοση: αποτελεσματικότητα αλγορίθμων, περιττά ερωτήματα βάσης δεδομένων, διαρροή πόρων.

• Αρχιτεκτονική — ορθότητα λύσης, τήρηση SOLID, απουσία υπερβολικής μηχανικής.
• Λογική — διαχείριση όλων των σεναρίων, συμπεριλαμβανομένων σφαλμάτων και οριακών περιπτώσεων.
• Δοκιμές — κάλυψη νέων αλλαγών, απουσία σπασμένων παλαιών δοκιμών.
• Ασφάλεια — ενέσεις, XSS, CSRF, διαρροή δεδομένων μέσω αρχείων καταγραφής.
• Απόδοση — πολυπλοκότητα αλγορίθμων, ερωτήματα N+1, διαρροή μνήμης.

Μέγεθος review: γιατί 400 γραμμές είναι το μέγιστο

Περιορισμός μεγέθους PR — η πιο σημαντική μετρική αποτελεσματικότητας του code review. Η έρευνα της Cisco (2015) και τα επακόλουθα πειράματα των SmartBear και Google έδειξαν: σε όγκο review άνω των 400 γραμμών, η ικανότητα του αναθεωρητή να εντοπίζει ελαττώματα μειώνεται δραστικά. Εάν το PR υπερβαίνει τις 400 γραμμές, τα σφάλματα εντοπίζονται με πιθανότητα όχι μεγαλύτερη από την τυχαία.

Βέλτιστο μέγεθος: 200-400 γραμμές για ένα PR. Αυτός ο όγκος μπορεί να ελεγχθεί από τον αναθεωρητή σε 30-60 λεπτά, διατηρώντας τη συγκέντρωση. Η Google συνιστά όχι περισσότερες από 200 γραμμές για έναν γύρο review με πλήρη συγκέντρωση. Εάν οι αλλαγές είναι περισσότερες — η εργασία πρέπει να αναλυθεί σε πολλά διαδοχικά PR, καθένα από τα οποία φέρνει μια λογικά ολοκληρωμένη αλλαγή.

Χρόνος review: εντός 24 ωρών από τη στιγμή δημιουργίας του PR. Εάν το review καθυστερήσει για αρκετές ημέρες, το πλαίσιο της εργασίας χάνεται και ο συγγραφέας πρέπει να ξοδέψει χρόνο για την αποκατάσταση του πλαισίου κατά την απάντηση σε σχόλια. Οι ομάδες με υψηλή κουλτούρα code review ορίζουν SLA για το review: για παράδειγμα, 4 ώρες για κρίσιμες αλλαγές και 24 ώρες για συνηθισμένες.

Πώς να γράφετε σωστά σχόλια για το review

Ο τόνος των σχολίων — είναι κρίσιμος για την αποτελεσματικότητα του code review. Το σχόλιο "Αυτό είναι λάθος" προκαλεί αμυντική αντίδραση και δεν δίνει χρήσιμες πληροφορίες στον συγγραφέα. Η καλύτερη διατύπωση είναι ερώτηση-πρόταση: "Τι πιστεύεις για αυτήν την προσέγγιση;", "Εδώ μπορεί να προκύψει NPE αν user == nil. Μήπως να προσθέσουμε guard;". Οι ερωτήσεις ασκούν λιγότερη πίεση και διεγείρουν τη συζήτηση.

Η δομή ενός καλού σχολίου περιλαμβάνει τρία μέρη: τι είναι λάθος, γιατί είναι πρόβλημα και πώς να διορθωθεί. Παράδειγμα: "Σε αυτόν τον βρόχο χρησιμοποιείται O(n²) λόγω του ένθετου contains, το οποίο μπορεί να επιβραδύνει σε 10k+ εγγραφές. Δοκίμασε να αντικαταστήσεις με Set για αναζήτηση O(1)". Μια τέτοια διατύπωση ταυτόχρονα υποδεικνύει το πρόβλημα, εξηγεί τη σημασία του και προτείνει λύση — ο συγγραφέας δεν χρειάζεται να μαντεύει.

Το GitHub και το GitLab υποστηρίζουν suggestions — ενσωματωμένες προτάσεις αλλαγών κώδικα. Ο αναθεωρητής μπορεί να γράψει: "```suggestion Φιλτράρισμα κενών γραμμών πριν από την επεξεργασία```" — και ο συγγραφέας εφαρμόζει την αλλαγή με ένα κλικ. Αυτό επιταχύνει μικρές διορθώσεις και μειώνει τον αριθμό των γύρων review. Για μεγάλες διορθώσεις, είναι καλύτερο να γράψετε ένα γενικό σχόλιο παρά να τοποθετήσετε μεγάλα μπλοκ στο suggestion.

# Πρότυπο για καλό σχόλιο code review

# ΚΑΚΟ: "Αυτός ο κώδικας είναι λάθος"
# ΚΑΛΟ: "Μπορεί να χάσουμε δεδομένα σε κενή απόκριση.
#         If response.data == nil, the guard returns nil,
#         and user sees empty screen without error.
#         Maybe add a fallback error message?"

# Σύνταξη πρότασης GitHub:
# ```suggestion
# let result = try? parse(response, fallback: .defaultValue)
# ```

Workflow code review στην ομάδα

Ένα αποτελεσματικό workflow review βασίζεται σε τέσσερα στάδια. Πρώτο — ο συγγραφέας προετοιμάζει το PR: γράφει ένα κατανοητό όνομα (π.χ., "feat: add password reset screen"), προσθέτει περιγραφή αλλαγών, συνδέσμους προς την εργασία στον tracker και οδηγίες δοκιμής. Δεύτερο — ο συγγραφέας ορίζει αναθεωρητές μέσω auto-assign (βάσει CODEOWNERS) ή χειροκίνητα.

Τρίτο στάδιο — ο αναθεωρητής ελέγχει τον κώδικα και αφήνει σχόλια. Τέταρτο — ο συγγραφέας κάνει διορθώσεις, απαντά στα σχόλια και ζητά επαναληπτικό review. Ο κύκλος επαναλαμβάνεται μέχρι να ληφθεί έγκριση. Μετά την έγκριση, ο συγγραφέας εκτελεί τη συγχώνευση (ή τη συγχώνευση εκτελεί το bot). Η αυτοματοποίηση μέσω Mergify ή GitHub Auto-merge επιταχύνει το τελικό στάδιο.

Σημαντικό στοιχείο του workflow — διαχείριση παλαιών PR. Εάν ένα PR παραμένει χωρίς review για περισσότερες από 3 ημέρες, η διαδικασία μπλοκάρεται. Λύσεις: εναλλαγή αναθεωρητών (εάν ο ορισμένος αναθεωρητής δεν είναι διαθέσιμος), ειδοποιήσεις μέσω Slack/Teams, χρονικό όριο για review (SLA). Σε ορισμένες ομάδες, το PR χωρίς review για περισσότερες από 7 ημέρες κλείνει αυτόματα και ο συγγραφέας δημιουργεί νέο μετά τον συγχρονισμό με το main.

• Δημιουργία PR — κατανοητό όνομα, περιγραφή, σύνδεσμοι προς εργασία, στιγμιότυπα οθόνης για αλλαγές UI.
• Ορισμός — auto-assign μέσω CODEOWNERS ή χειροκίνητη επιλογή 1-2 αναθεωρητών.
• Review — έλεγχος με σειρά: αρχιτεκτονική → λογική → δοκιμές → ασφάλεια → στυλ.
• Διορθώσεις — ο συγγραφέας απαντά σε όλα τα σχόλια, διορθώνει blocking issues, ζητά re-review.
• Συγχώνευση — μετά την έγκριση και πράσινο CI, ο συγγραφέας ή το bot εκτελεί τη συγχώνευση.

Συνηθισμένα λάθη στο code review

Πρώτο λάθος — επιφανειακό review. Ο αναθεωρητής κοιτάζει βιαστικά το diff, χωρίς να εμβαθύνει στη λογική, και πατάει Approve. Αιτίες: μεγάλο PR, deadline, κόπωση. Συνέπειες: σφάλματα φτάνουν στην παραγωγή. Λύση: εάν δεν υπάρχει χρόνος για ποιοτικό review — γράψτε ειλικρινά "Δεν μπορώ να ελέγξω σήμερα, αναβάλετε για αύριο" αντί για επίσημη έγκριση.

Δεύτερο λάθος — υπερβολική κριτική (nitpicking). Ο αναθεωρητής αφήνει δεκάδες σχόλια σχετικά με το στυλ μορφοποίησης, την ονομασία μεταβλητών, τετριμμένες λεπτομέρειες. Αυτό αποκινητοποιεί τον συγγραφέα και παρατείνει το review. Λύση: το StyleGuide και οι linters πρέπει να ελέγχουν το στυλ αυτόματα. Ο άνθρωπος στο review ελέγχει λογική, αρχιτεκτονική και ασφάλεια.

Τρίτο λάθος — review χωρίς ερωτήσεις. Εάν ο αναθεωρητής βάζει μόνο Request Changes και Approve, αλλά δεν κάνει ερωτήσεις, χάνει την ευκαιρία να μάθει κάτι νέο. Ο καλύτερος δείκτης υγείας του code review είναι η ύπαρξη συζητήσεων στις οποίες και οι δύο πλευρές μαθαίνουν κάτι νέο. Εάν το review είναι μονόλογος ενός από τους συμμετέχοντες — η διαδικασία είναι χαλασμένη.

• Επιφανειακό review — Approve χωρίς εμβάθυνση. Λύση: μην κάνετε review αν δεν έχετε χρόνο.
• Nitpicking — κριτική στυλ που ελέγχεται από linter. Λύση: αυτοματοποιήστε τους style checks.
• Προσωπική αντίληψη — "εγώ θα το έγραφα διαφορετικά". Λύση: ο κώδικας πρέπει να λειτουργεί, όχι να αρέσει στον αναθεωρητή.
• Καθυστέρηση — review πάνω από 24 ώρες. Λύση: SLA για review, κλιμάκωση σε περίπτωση παραβίασης.
• Αγνόηση πλαισίου — review κώδικα χωρίς κατανόηση της εργασίας. Λύση: διαβάστε την περιγραφή PR πριν από το diff.