Μόλις πριν από δύο χρόνια, η ΤΝ που γεννά κώδικα αντιμετωπιζόταν περισσότερο ως μια περιέργεια παρά ως πραγματικό εργαλείο για developers. Σήμερα η κατάσταση είναι εντελώς διαφορετική. Τα μοντέλα μπορούν να δημιουργούν components, να γράφουν endpoints, να παράγουν tests, να αναλύουν σφάλματα και ακόμη και να βοηθούν στη refactorάρισμα μεγάλων τμημάτων εφαρμογών.
Και ακριβώς γι’ αυτό όλο και πιο συχνά εμφανίζεται το ερώτημα: θα γράφει η ΤΝ κώδικα καλύτερα από τους προγραμματιστές?
Το πρόβλημα είναι ότι οι περισσότερες συζητήσεις πάνω στο θέμα είναι ακραίες. Από τη μία έχουμε τη γραμμή «η ΤΝ θα αντικαταστήσει τους developers», από την άλλη - την πλήρη απαξίωση της αξίας αυτών των εργαλείων.
Η αλήθεια, όπως συνήθως, βρίσκεται πολύ βαθύτερα.
Η ΤΝ γράφει εξαιρετικά κώδικα. Καταλαβαίνει όμως χειρότερα το σύστημα
Αυτή είναι η κρίσιμη διαφορά.
Τα σύγχρονα μοντέλα τα καταφέρνουν πολύ καλά με:
- επαναλαμβανόμενο κώδικα,
- boilerplate,
- απλή επιχειρησιακή λογική,
- δημιουργία CRUD,
- σύνταξη tests,
- βασικό refactoring,
- τεχνική τεκμηρίωση.
Και στην πράξη πραγματικά επιταχύνουν τη δουλειά των ομάδων ανάπτυξης.
Το πρόβλημα ξεκινά όταν ο κώδικας παύει να είναι μεμονωμένο κομμάτι και γίνεται μέρος ενός μεγαλύτερου συστήματος.
Διότι το καλό λογισμικό δεν είναι «γράψιμο κώδικα». Είναι σχεδιασμός εξαρτήσεων, κλιμακωσιμότητας, ασφάλειας και δυνατότητας συντήρησης για χρόνια. Κι εδώ η ΤΝ εξακολουθεί να έχει πολύ σαφείς περιορισμούς.
Το μεγαλύτερο πρόβλημα: η ΤΝ δεν «νιώθει» τις αρχιτεκτονικές συνέπειες
Ο developer που γράφει παραγωγικό σύστημα πρέπει να σκέφτεται πράγματα που το μοντέλο ΤΝ απλώς δεν «αισθάνεται»:
- κόστος συντήρησης,
- μελλοντική κλιμακωσιμότητα,
- απόδοση υπό φόρτο,
- ασφάλεια,
- ενσωματώσεις,
- τεχνικό χρέος (technical debt),
- επίδραση των αλλαγών σε άλλα modules.
Η ΤΝ τις περισσότερες φορές βελτιστοποιεί τοπικά - για τη συγκεκριμένη εργασία. Κι αυτό είναι πολύ επικίνδυνο.
Γιατί μπορείς να παράγεις κώδικα που:
- λειτουργεί,
- περνά τα tests,
- φαίνεται σωστός,
και ταυτόχρονα μακροπρόθεσμα αποσταθεροποιεί ολόκληρο το σύστημα.
Γι’ αυτό ακριβώς οι ομάδες που χρησιμοποιούν ΤΝ χωρίς έλεγχο συχνά μετά από λίγους μήνες αρχίζουν να βιώνουν απότομη αύξηση του technical debt.
Πού η ΤΝ δίνει πραγματικά τεράστιο πλεονέκτημα
Παρά τους περιορισμούς, υπάρχουν τομείς στους οποίους η ΤΝ ήδη σήμερα αποτελεί πολύ ισχυρή υποστήριξη για τους developers.
- Debugging και ανάλυση σφαλμάτων
Από τις πιο υποτιμημένες περιπτώσεις χρήσης.
Η ΤΝ μπορεί:
- να αναλύει stack trace,
- να υποδεικνύει πιθανές αιτίες σφαλμάτων,
- να εντοπίζει λογικά προβλήματα,
- να προτείνει διορθώσεις,
- να εξηγεί σύνθετες εξαρτήσεις στον κώδικα.
Σε πολλές περιπτώσεις μειώνει τον χρόνο διάγνωσης από ώρες σε λεπτά.
Λειτουργεί ιδιαίτερα καλά σε μεγάλα συστήματα, όπου ο εντοπισμός της πηγής του σφάλματος είναι περισσότερο αναλυτικό παρά προγραμματιστικό πρόβλημα. - Refactoring
Η ΤΝ τα καταφέρνει πολύ καλά με:
- απλοποίηση κώδικα,
- αφαίρεση διπλοτύπων,
- εκσυγχρονισμό παλαιότερων τμημάτων,
- ξαναγράψιμο components,
- μεταφορές μεταξύ frameworks.
Αλλά με μια προϋπόθεση: οι αρχιτεκτονικές αποφάσεις πρέπει να παραμένουν στον άνθρωπο.
Η ΤΝ μπορεί να είναι εξαιρετικός «εκτελεστής refactoring», αλλά δεν θα έπρεπε αυτόνομα να ορίζει την κατεύθυνση των συστημικών αλλαγών. - Code review
Ένας τομέας που θα αναπτυχθεί εξαιρετικά γρήγορα.
Η ΤΝ ήδη σήμερα μπορεί:
- να εντοπίζει πιθανά bugs,
- να υποδεικνύει ζητήματα ασφάλειας,
- να αναλύει συμμόρφωση με πρότυπα,
- να προτείνει βελτιστοποιήσεις,
- να «πιάνει» anti-patterns.
Και το σημαντικό - το κάνει άμεσα. Αλλά εξακολουθεί να υπάρχει τεράστια διαφορά μεταξύ:
«αυτό το κομμάτι μπορεί να προκαλεί memory leak»
και
«αυτή η απόφαση είναι λανθασμένη επιχειρηματικά και αρχιτεκτονικά».
Το δεύτερο εξακολουθεί να απαιτεί την εμπειρία senior developers και αρχιτεκτόνων.
Ο μεγαλύτερος κίνδυνος: η ψευδαίσθηση παραγωγικότητας
Αυτό είναι ένα πρόβλημα που φαίνεται ολοένα και πιο έντονα στον κλάδο.
Η ΤΝ κάνει τον κώδικα να παράγεται πιο γρήγορα. Αλλά η ταχύτητα παραγωγής κώδικα δεν είναι το ίδιο με την ταχύτητα οικοδόμησης ενός καλού συστήματος.
Σε πολλές ομάδες εμφανίζεται το φαινόμενο: περισσότερος κώδικας, γρηγορότερα, αλλά χαμηλότερης συστημικής ποιότητας.
Αυτό είναι ιδιαίτερα επικίνδυνο σε έργα όπου:
- λείπει ισχυρή αρχιτεκτονική,
- δεν υπάρχουν πρότυπα,
- το review είναι επιφανειακό,
- η πίεση για παράδοση είναι υψηλή.
Αποτέλεσμα;
Βραχυπρόθεσμη αύξηση παραγωγικότητας και μακροπρόθεσμο τεχνολογικό χάος.
Είναι οι junior οι πιο απειλούμενοι?
Παραδόξως - όχι μόνο οι junior. Η ΤΝ αλλάζει πιο πολύ τον ρόλο των mid-level προγραμματιστών, που ασχολούνται με μεγάλο όγκο επαναλαμβανόμενης υλοποίησης.
Όλο και μεγαλύτερη αξία θα έχουν δεξιότητες που σχετίζονται με:
- αρχιτεκτονική,
- ανάλυση συστημάτων,
- ενσωματώσεις,
- ασφάλεια,
- βελτιστοποίηση,
- σχεδιασμό διαδικασιών,
- εποπτεία κώδικα που παράγεται από ΤΝ.
Ο προγραμματιστής του μέλλοντος θα είναι λιγότερο «συγγραφέας κώδικα» και περισσότερο operator και σχεδιαστής συστημάτων.
Τι θα γίνει σε 3–5 χρόνια?
Είναι πολύ πιθανό ότι το μεγαλύτερο μέρος του τυπικού κώδικα εφαρμογών θα παράγεται εν μέρει από ΤΝ. Αλλά αυτό δεν σημαίνει το τέλος των προγραμματιστών. Σημαίνει αλλαγή του επιπέδου αφαίρεσης της δουλειάς ανάπτυξης.
Λιγότερος χρόνος για:
- boilerplate,
- επαναλαμβανόμενες υλοποιήσεις,
- χειροκίνητο ξαναγράψιμο λογικής.
Περισσότερος χρόνος για:
- αρχιτεκτονική,
- συστημικές αποφάσεις,
- βελτιστοποίηση,
- ασφάλεια,
- σχεδιασμό οικοσυστημάτων πρακτόρων.
Και ακριβώς γι’ αυτό οι τεχνολογικές εταιρείες που ήδη σήμερα μαθαίνουν συνειδητή δουλειά με την ΤΝ θα έχουν τεράστιο πλεονέκτημα έναντι εκείνων που αντιμετωπίζουν την ΤΝ αποκλειστικά ως generator κώδικα.
