Άνοιξε ένα repository έξι μήνες αφού κυκλοφόρησε ένα feature και μπορείς να ανασυνθέσεις πολλά. Μπορείς να εντοπίσεις την αρχιτεκτονική, να εξετάσεις το schema, να διαβάσεις τα tests και να δεις ακριβώς ποιες γραμμές άλλαξαν.
Αυτό που συνήθως δεν μπορείς να ανασυνθέσεις είναι η συζήτηση που έκανε αυτές τις γραμμές αναγκαίες.
Ο κώδικας δεν θα σου πει ότι υπάρχει ένας κανόνας επικύρωσης επειδή ένας πελάτης στέλνει κακοσχηματισμένα exports. Δεν θα εξηγήσει ότι μια παράξενη πολιτική επαναπροσπάθειας αποτρέπει διπλές συναλλαγές σε ένα downstream σύστημα. Δεν θα δείξει ότι το πιο καθαρό interface απορρίφθηκε έπειτα από ένα τεστ προσβασιμότητας ή ότι ένα όριο υπηρεσίας αντανακλά έναν συμβατικό περιορισμό και όχι μια προτίμηση μηχανικής.
Το Git είναι εξαιρετικό στο να διατηρεί το ιστορικό του κώδικα. Διατηρεί την πρόθεση μόνο όταν μια ομάδα την καταγράφει σκόπιμα και τη διατηρεί συνδεδεμένη με την υλοποίηση.
Αυτό το κενό ήταν πάντα μέρος της μηχανικής λογισμικού. Τα εργαλεία AI για κώδικα το κάνουν πιο ορατό. Ένα σύστημα μπορεί να διαβάσει κάθε αρχείο σε ένα repository, να ακολουθήσει κάθε σύμβολο και να δημιουργήσει ένα τεχνικά πειστικό patch, ενώ παρ’ όλα αυτά λύνει το λάθος πρόβλημα.
Το πρόβλημα δεν είναι ότι ο κώδικας είναι παραπλανητικός. Ο κώδικας απαντά σε μια πιο στενή ερώτηση.
Πέντε επίπεδα της αλήθειας της μηχανικής
Οι περισσότερες ουσιαστικές αλλαγές στο λογισμικό εξαρτώνται από πέντε διαφορετικά επίπεδα τεκμηρίωσης.
- Πρόθεση — Ποιο αποτέλεσμα ζητά ο χρήστης, ο πελάτης ή η επιχείρηση; Αυτό μπορεί να βρίσκεται σε μια προδιαγραφή, ένα ticket, μια συνομιλία υποστήριξης ή σημειώσεις συνάντησης.
- Περιορισμοί — Τι δεν πρέπει να σπάσει; Υποσχέσεις συμβατότητας, όρια ασφαλείας, κανονισμοί, συμβόλαια, προϋπολογισμοί και προθεσμίες συχνά βρίσκονται έξω από το repository.
- Υλοποίηση — Πώς λειτουργεί το σύστημα σήμερα; Ο κώδικας, τα tests, τα schemas, οι εξαρτήσεις και η διαμόρφωση ανάπτυξης παρέχουν αυτό το επίπεδο.
- Στοιχεία από το runtime — Τι συμβαίνει στο πραγματικό σύστημα; Logs, traces, metrics, δεδομένα παραγωγής και αναφορές συμβάντων μπορούν να αντικρούσουν υποθέσεις που στον κώδικα φαίνονται λογικές.
- Ιστορικό αποφάσεων — Γιατί επιλέχθηκε η τρέχουσα προσέγγιση; Pull requests, συζητήσεις σχεδιασμού, απορριφθείσες εναλλακτικές και προηγούμενα συμβάντα περιέχουν την απάντηση.
Το repository είναι ισχυρότερο στο τρίτο επίπεδο. Περιέχει μέρη από τα υπόλοιπα, αλλά σπάνια αρκετά ώστε να τα εκπροσωπεί πλήρως.
Αυτό έχει σημασία επειδή οι αστοχίες λογισμικού συχνά εμφανίζονται στα όρια μεταξύ των επιπέδων. Η υλοποίηση ταιριάζει με μια ξεπερασμένη προδιαγραφή. Η διόρθωση ικανοποιεί το ticket αλλά παραβιάζει έναν λειτουργικό περιορισμό. Τα tests περνούν επειδή κωδικοποιούν τις παραδοχές του χθες. Ο κώδικας είναι εσωτερικά συνεπής ενώ τα δεδομένα παραγωγής ακολουθούν ένα μοτίβο που κανείς δεν τεκμηρίωσε.
Ένα τοπικά σωστό patch μπορεί και πάλι να είναι η λάθος αλλαγή.
Τι δεν μπορεί να απαντήσει από μόνο του το repository
Σκεφτείτε έναν χρήστη που επεξεργάζεται ένα έγγραφο και έπειτα αναζητά την ενημερωμένη πρόταση, μόνο και μόνο για να δει στα αποτελέσματα την παλιά εκδοχή. Το «κάντε την αναζήτηση να ενημερώνεται αμέσως» ακούγεται σαν ένα σαφές αίτημα. Το repository αποκαλύπτει αρκετά πιθανά σημεία από όπου μπορεί να ξεκινήσει κανείς, αλλά δεν μπορεί από μόνο του να καθορίσει ποια είναι η σωστή διόρθωση.
| Ερώτημα | Πιθανή πηγή |
|---|---|
| Ποια εκδοχή του εγγράφου είναι η έγκυρη; | Πηγαίο έγγραφο και ιστορικό αναθεωρήσεων |
| Πού παραμένει το παλιό κείμενο; | Αρχεία καταγραφής συγχρονισμού, έξοδος εξαγωγής, ευρετήριο αναζήτησης ή cache |
| Τι σημαίνει «αμέσως» για αυτό το προϊόν; | Υπόσχεση του προϊόντος ή στόχος υπηρεσίας |
| Άλλαξαν τα δικαιώματα του εγγράφου μαζί με το περιεχόμενό του; | Δικαιώματα στην πηγή και ιστορικό ελέγχου |
| Το παρωχημένο αποτέλεσμα περιορίζεται σε έναν χρήστη, μία πηγή ή μία περιοχή; | Ίχνη αιτημάτων και μετρικές παραγωγής |
Ο κώδικας της αναζήτησης μπορεί να εξηγεί πώς επιστρέφονται τα αποτελέσματα. Δεν μπορεί να σας πει αν το πραγματικό ελάττωμα είναι καθυστέρηση συγχρονισμού, παρωχημένη εξαγωγή, ακύρωση cache, διάδοση δικαιωμάτων ή μια προσδοκία που το προϊόν δεν όρισε ποτέ.
Αυτή η διάκριση γίνεται ακόμη πιο σημαντική σε ώριμα συστήματα. Ένα πεδίο που φαίνεται παρωχημένο μπορεί να εξακολουθεί να υποστηρίζει έναν legacy client. Μια υπηρεσία που μοιάζει διπλή μπορεί να διαχωρίζει δεδομένα με διαφορετικές απαιτήσεις δικαιωμάτων. Ένας έλεγχος που φαίνεται υπερβολικός μπορεί να είναι το μόνο ίχνος σε επίπεδο κώδικα από ένα περιστατικό παραγωγής που η τωρινή ομάδα δεν είδε ποτέ.
Η αφαίρεση της πολυπλοκότητας έχει αξία. Η αφαίρεση της ιστορίας που μεταμφιέζεται σε πολυπλοκότητα είναι δαπανηρή.
Περισσότερο context μπορεί και πάλι να οδηγήσει σε λάθος απάντηση
Η προφανής λύση είναι να δοθεί στην AI περισσότερο υλικό: ολόκληρο το repository, κάθε ticket, κάθε έγγραφο, κάθε μήνυμα και κάθε log.
Αυτό δημιουργεί πρόσβαση, όχι κατανόηση.
Οι πηγές μπορεί να είναι παρωχημένες, αντιφατικές, υποθετικές ή γραμμένες για διαφορετικά κοινά. Ένα brainstorm δεν πρέπει να υπερισχύει μιας εγκεκριμένης προδιαγραφής. Μια απαίτηση έξι μηνών δεν πρέπει σιωπηρά να παρακάμπτει τη χθεσινή απόφαση προϊόντος. Ένα production log πρέπει να συνδέεται με το release, το environment και το code path που το παρήγαγαν. Ένα αίτημα πελάτη δεν πρέπει να αντιμετωπίζεται ως καθολική απαίτηση χωρίς να ελεγχθεί το scope.
Ένα σοβαρό σύστημα context, επομένως, χρειάζεται κάτι περισσότερο από retrieval. Χρειάζεται έναν τρόπο να συλλογίζεται σχετικά με:
- Authority: Ποια πηγή επιτρέπεται να ορίζει την απαίτηση;
- Recency: Ποια πληροφορία είναι τρέχουσα και ποια έχει αντικατασταθεί;
- Provenance: Από πού προήλθε κάθε ισχυρισμός, περιορισμός ή συμπέρασμα;
- Relationships: Ποιο issue, release, customer, dataset και code path συνδέονται μεταξύ τους;
- Permissions: Ποιες πηγές μπορούν να χρησιμοποιηθούν για αυτή την εργασία και να εμφανιστούν σε αυτό το άτομο;
Το context δεν είναι ένας σωρός από tokens. Είναι ένα γράφημα με χρόνο, authority και όρια.
Περισσότερο context πρέπει να παράγει περισσότερα τεκμήρια, όχι περισσότερη βεβαιότητα χωρίς τεκμήρια.
Η πραγματική μονάδα εργασίας είναι η αλλαγή
Οι editors και τα coding tools είναι οργανωμένα γύρω από αρχεία, επειδή τα αρχεία είναι αυτά που τροποποιούμε. Οι ομάδες μηχανικών οργανώνονται γύρω από αλλαγές.
Μια αλλαγή ξεκινά με έναν λόγο. Γίνεται απαίτηση, αγγίζει κώδικα και δεδομένα, περνά από review, φτάνει στην παραγωγή και δημιουργεί νέα τεκμήρια. Αν αυτά τα στάδια παραμένουν ασύνδετα, κάθε μελλοντική εργασία ξεκινά με έναν ακόμη γύρο αρχαιολογίας.
Ένα σύστημα AI που εργάζεται πάνω σε πραγματικό λογισμικό θα πρέπει να ακολουθεί αυτόν τον κύκλο ζωής.
Πριν από την υλοποίηση, θα πρέπει να εντοπίζει το αίτημα, τους σχετικούς περιορισμούς και τυχόν αντικρουόμενες πηγές. Θα πρέπει να γνωρίζει αν διορθώνει ένα ελάττωμα, αν αλλάζει την αναμενόμενη συμπεριφορά ή αν εισάγει ένα νέο συμβόλαιο.
Κατά την υλοποίηση, θα πρέπει να συνδέει κάθε ουσιαστική επιλογή με τεκμήρια. Γιατί αυτό το module; Γιατί αυτή η στρατηγική migration; Γιατί να διατηρηθεί αυτό το branch; Η εξήγηση θα πρέπει να επιβιώνει πέρα από το chat που παρήγαγε τον κώδικα.
Μετά την υλοποίηση, θα πρέπει να επισυνάπτει στην αλλαγή τα αποτελέσματα επαλήθευσης, τις αποφάσεις ανασκόπησης και τους περιορισμούς που ανακαλύφθηκαν εκ των υστέρων. Διαφορετικά, το επόμενο άτομο —ή η επόμενη συνεδρία AI— θα πρέπει να τα ανακαλύψει ξανά.
Αυτή είναι η διαφορά ανάμεσα σε ένα εργαλείο που μπορεί να επεξεργαστεί ένα repository και σε ένα σύστημα που μπορεί να συμμετέχει στο έργο της μηχανικής.
Η AI πρέπει να μειώνει την ανασύνθεση, όχι να καταργεί την κρίση
Το καλύτερο context παρουσιάζεται μερικές φορές ως δρόμος προς την αυτόνομη ανάπτυξη λογισμικού. Η άμεση αξία του είναι λιγότερο εντυπωσιακή και πιο χρήσιμη: να μειώνει το κόστος της ανασύνθεσης της πραγματικότητας πριν γίνει μια αλλαγή.
Η AI μπορεί να φέρει την αρχική απαίτηση δίπλα στον σχετικό κώδικα. Μπορεί να αναδείξει το περιστατικό που εξηγεί μια ασυνήθιστη δικλίδα ασφαλείας. Μπορεί να συνδέσει μια μετρική που αποτυγχάνει με το release που την άλλαξε. Μπορεί να δείξει ότι δύο έγκυρες πηγές διαφωνούν πριν καν αρχίσει η υλοποίηση.
Αυτές οι δυνατότητες δεν καταργούν τη μηχανική κρίση. Την καθιστούν καλύτερα τεκμηριωμένη.
Ένας άνθρωπος εξακολουθεί να πρέπει να αποφασίσει ποιος συμβιβασμός είναι αποδεκτός, αν μια απαίτηση είναι πλήρης και πόσο ρίσκο μπορεί να φέρει ένα release. Το σύστημα πρέπει να καθιστά ορατά τα τεκμήρια και ελέγξιμη τη συλλογιστική. Δεν πρέπει να κρύβει την αβεβαιότητα πίσω από ένα καλογυαλισμένο patch.
Το κριτήριο δεν είναι «μπορεί να παράγει κώδικα;»
Το κριτήριο είναι «μπορεί να εξηγήσει γιατί αυτή είναι η σωστή αλλαγή τώρα;»
Από repository-aware σε work-aware
Οι βοηθοί προγραμματισμού έγιναν αρχικά χρήσιμοι κατανοώντας το αρχείο που βρίσκεται μπροστά στον προγραμματιστή. Η επίγνωση του repository ήταν το επόμενο μεγάλο βήμα: εντοπισμός σχετικού κώδικα, παρακολούθηση συμβόλων και εφαρμογή αλλαγών σε όλο το project.
Το επόμενο βήμα είναι η επίγνωση της εργασίας γύρω από το repository.
Αυτό σημαίνει σύνδεση του κώδικα με την προδιαγραφή που τον ζήτησε, τη συζήτηση που τον αποσαφήνισε, τα στοιχεία από την παραγωγή που τον αμφισβήτησαν και την απόφαση που πρέπει να θυμόμαστε αργότερα. Σημαίνει επίσης αποκλεισμό context που είναι άσχετο, παρωχημένο ή εκτός των δικαιωμάτων του χρήστη.
Καθώς χτίζουμε το Dvina, αυτή είναι μία από τις ιδέες στις οποίες επιστρέφουμε διαρκώς. Η εργασία δεν συμβαίνει μέσα σε ένα μόνο αρχείο, εφαρμογή ή συζήτηση. Το νόημα βρίσκεται στις συνδέσεις μεταξύ τους και στο πώς αυτές οι συνδέσεις αλλάζουν με τον χρόνο.
Το repository παραμένει ουσιώδες. Είναι η εκτελέσιμη πηγή αλήθειας για τη συμπεριφορά του συστήματος. Απλώς δεν είναι η πλήρης πηγή αλήθειας για την πρόθεση του προϊόντος, τη λειτουργική πραγματικότητα ή την οργανωσιακή μνήμη.
Η πλήρης εικόνα αλλάζει αυτό που τελικά χτίζεται
Με μόνο τον κώδικα, το φυσικό ερώτημα είναι:
Ποια αλλαγή ταιριάζει σε αυτό το σύστημα;
Με το ευρύτερο context, το ερώτημα γίνεται:
Ποια αλλαγή ταιριάζει σε αυτό το σύστημα, σε αυτή την απαίτηση, σε αυτό το ιστορικό και σε αυτή τη χρονική στιγμή;
Αυτή η δεύτερη ερώτηση εντοπίζει τους περιορισμούς πριν εξελιχθούν σε regressions. Δίνει στους reviewers το σκεπτικό πίσω από την υλοποίηση. Βοηθά τα νέα μέλη της ομάδας να καταλάβουν γιατί το σύστημα έχει αυτή τη μορφή. Δίνει στην AI έναν προσγειωμένο ρόλο: όχι ως μάντη μέσα στον editor, αλλά ως συμμετέχοντα που μπορεί να συγκεντρώνει τεκμήρια από όλο το εύρος της δουλειάς.
Το repo σας δεν ήταν ποτέ όλη η ιστορία.
Η ευκαιρία είναι να χτίσουμε συστήματα που μπορούν να διαβάζουν και όλο το υπόλοιπο — και να δείχνουν τη δουλειά τους.
