Στον κόσμο του λογισμικού, πέντε χρόνια μπορεί να σημαίνουν είτε ένα σύστημα που εξακολουθεί να είναι πολύ καλά προετοιμασμένο για περαιτέρω ανάπτυξη, είτε ένα τεχνολογικό πρόβλημα που κάθε επόμενος μήνας θα το κάνει ακριβότερο.
Η ίδια η ηλικία της εφαρμογής, όμως, δεν είναι λόγος για την αντικατάστασή της.
Αυτό είναι ένα από τα σημαντικότερα πράγματα που αξίζει να ειπωθούν από την αρχή.
Δεν υπάρχει καθολικό όριο μετά το οποίο μια εφαρμογή πρέπει να ξαναγραφτεί από την αρχή. Υπάρχουν συστήματα που λειτουργούν εδώ και πάνω από δέκα χρόνια και εξακολουθούν να έχουν λογική αρχιτεκτονική, ενημερωμένες εξαρτήσεις, καλή τεκμηρίωση και δοκιμασμένη διαδικασία αναπτύξεων. Υπάρχουν επίσης πολύ νεότερες εφαρμογές, των οποίων η ανάπτυξη δυσκολεύτηκε από λανθασμένες αρχιτεκτονικές αποφάσεις, έλλειψη δοκιμών, ανεξέλεγκτες εξαρτήσεις ή διαδοχικές γρήγορες διορθώσεις.
Το πρόβλημα λοιπόν δεν είναι ο αριθμός των ετών.
Το πρόβλημα είναι η ικανότητα του συστήματος να αλλάζει περαιτέρω.
Το πιο σημαντικό ερώτημα δεν είναι: "Είναι η εφαρμογή παλιά;"
Καλύτερο ερώτημα είναι: "Πόσο κοστίζει η επόμενη αλλαγή;"
Αν η προσθήκη μιας νέας λειτουργίας απαιτεί όλο και περισσότερες ώρες, τη συμμετοχή πολλών ομάδων, χειροκίνητες δοκιμές και παράκαμψη των περιορισμών της παλιάς αρχιτεκτονικής, το σύστημα αρχίζει να δημιουργεί κόστος που δεν φαίνεται στον ίδιο τον κώδικα.
Αυτό είναι ένα από τα πρακτικά σημάδια του αυξανόμενου τεχνικού χρέους.
Το technical debt μπορεί να θεωρηθεί ως το κόστος των μελλοντικών αλλαγών που προκύπτει από προηγούμενες τεχνικές αποφάσεις. Ο Martin Fowler το περιγράφει ως την πρόσθετη προσπάθεια που πρέπει να καταβάλλεται κατά την τροποποίηση του συστήματος, όταν η εσωτερική του ποιότητα δυσκολεύει την ανάπτυξη.
Και ακριβώς γι' αυτό μια εφαρμογή μπορεί να συνεχίζει να λειτουργεί σωστά, και ταυτόχρονα να γίνεται όλο και πιο δύσκολη στην εξέλιξη.
10 λειτουργίες αργότερα, το σύστημα μοιάζει εντελώς διαφορετικό
Η αρχή ενός έργου είναι συχνά απλή.
Δημιουργείται ένα MVP.
Έπειτα προστίθενται νέες απαιτήσεις:
- ενσωμάτωση με CRM,
- online πληρωμές,
- διαχειριστικός πίνακας,
- κινητή εφαρμογή,
- νέοι ρόλοι χρηστών,
- αναφορές,
- αυτοματισμοί,
- API,
- ενσωματώσεις με εξωτερικές υπηρεσίες,
- επόμενες γλωσσικές εκδόσεις.
Κάθε αλλαγή από μόνη της μπορεί να είναι δικαιολογημένη.
Το πρόβλημα εμφανίζεται όταν η αρχιτεκτονική δεν σχεδιάστηκε με αυτόν τον αναπτυξιακό προσανατολισμό στο μυαλό.
Τότε οι επόμενες λειτουργίες δεν προστίθενται πλέον σε μια σταθερή κατασκευή.
Προστίθενται πάνω σε προηγούμενες εξαιρέσεις, παρακάμψεις και συμβιβασμούς.
Πώς καταλαβαίνετε ότι το σύστημα αρχίζει να γερνάει;
Δεν χρειάζεται να περιμένετε την πλήρη βλάβη.
Τα προειδοποιητικά σημάδια εμφανίζονται πολύ νωρίτερα.
1. Η νέα λειτουργία διαρκεί όλο και περισσότερο
Κάποτε μια λειτουργία απαιτούσε μερικές ημέρες. Σήμερα μια παρόμοια αλλαγή χρειάζεται μερικές εβδομάδες.
Αυτό δεν σημαίνει απαραίτητα πιο αργή ομάδα.
Μπορεί να σημαίνει ότι όλο και περισσότερος χρόνος καταναλώνεται για την κατανόηση του υπάρχοντος συστήματος και την προστασία του από τις συνέπειες της αλλαγής.
2. Κάθε αλλαγή προκαλεί ντόμινο επιδράσεων
Η τροποποίηση ενός module δημιουργεί προβλήματα σε αρκετά άλλα σημεία.
Αυτό είναι σημάδι ότι τα components είναι υπερβολικά στενά συνδεδεμένα ή ότι τα όρια ευθύνης μεταξύ τους έχουν οριστεί λανθασμένα.
3. Οι δοκιμές είναι κυρίως χειροκίνητες
Αν κάθε μεγαλύτερη αλλαγή απαιτεί χειροκίνητο έλεγχο δεκάδων λειτουργιών, το κόστος της διάθεσης σε παραγωγή αυξάνεται.
Το πρόβλημα δεν είναι η ίδια η έλλειψη αυτοματοποίησης.
Το πρόβλημα είναι η έλλειψη δυνατότητας γρήγορης απόκτησης αξιόπιστης πληροφορίας για το αν κάτι χάλασε λόγω της αλλαγής.
4. Η ομάδα φοβάται να αγγίξει συγκεκριμένα τμήματα του συστήματος
Αυτό είναι ένας πολύ πρακτικός δείκτης.
Αν υπάρχουν modules που οι προγραμματιστές αποφεύγουν, επειδή "κανείς δεν ξέρει ακριβώς τι θα συμβεί μετά την αλλαγή", ο τεχνικός κίνδυνος έχει ήδη γίνει πραγματικό επιχειρηματικό κόστος.
5. Το σύστημα εξαρτάται από παρωχημένες τεχνολογίες
Ένα παλιό framework από μόνο του δεν σημαίνει πρόβλημα.
Το πρόβλημα εμφανίζεται όταν:
- δεν υποστηρίζεται πλέον,
- είναι δύσκολο να βρεθούν ειδικοί,
- οι εξαρτήσεις δεν μπορούν να ενημερωθούν με ασφάλεια,
- το runtime περιβάλλον είναι προβληματικό,
- η ενσωμάτωση με νέες λύσεις είναι δύσκολη.
Τότε η τεχνολογία αρχίζει να περιορίζει τις επιχειρηματικές δυνατότητες.
Χρειάζεται πάντα να ξαναγράφετε μια εφαρμογή από την αρχή;
Όχι.
Αυτό είναι ένα από τα πιο συχνά λάθη στην προσέγγιση του legacy software.
Το πλήρες rewrite μπορεί να δικαιολογείται, αλλά είναι εγχείρημα υψηλού ρίσκου.
Ένα παλιό σύστημα συχνά περιέχει δεκάδες ή εκατοντάδες επιχειρηματικούς κανόνες, εξαιρέσεις και συμπεριφορές που δεν υπάρχουν στην τεκμηρίωση. Ξαναγράφοντάς το από το μηδέν, μπορεί πολύ εύκολα να δημιουργηθεί ένα σύστημα τεχνολογικά νέο, αλλά επιχειρηματικά ελλιπές.
Γι' αυτό σε πολλές περιπτώσεις καλύτερη λύση είναι ο σταδιακός εκσυγχρονισμός.
Ένα μέρος του συστήματος παραμένει ενεργό, ενώ οι επόμενοι τομείς αντικαθίστανται σταδιακά από νέα components.
Αυτή η προσέγγιση είναι γνωστή, μεταξύ άλλων, ως pattern Strangler Fig. Επιτρέπει τον εκσυγχρονισμό του συστήματος βήμα προς βήμα, την παροχή αξίας νωρίτερα και τον περιορισμό του ρίσκου μιας εφάπαξ μετάβασης ολόκληρης της λύσης.
Πότε έχει νόημα ο εκσυγχρονισμός;
Αξίζει να τον εξετάσετε, όταν:
- το σύστημα εξακολουθεί να υποστηρίζει σημαντικές επιχειρηματικές διαδικασίες,
- η αρχιτεκτονική επιτρέπει τον διαχωρισμό τουλάχιστον μέρους της λειτουργικότητας,
- τα δεδομένα μπορούν να μεταναστευθούν ή να ενσωματωθούν με ασφάλεια,
- το πρόβλημα αφορά συγκεκριμένους τομείς και όχι ολόκληρη την κατασκευή,
- η εφαρμογή παράγει αξία και η πλήρης αντικατάστασή της θα ήταν ριψοκίνδυνη,
- το σύστημα μπορεί να εκσυγχρονιστεί σταδιακά.
Αυτή είναι ιδιαίτερα καλή λύση για συστήματα που δεν μπορούν απλώς να κλείσουν για μερικούς μήνες.
Πότε μπορεί ο εκσυγχρονισμός να μην έχει νόημα;
Υπάρχουν επίσης περιπτώσεις στις οποίες η περαιτέρω διάσωση του παλιού συστήματος παύει να είναι οικονομικά συμφέρουσα.
Για παράδειγμα όταν:
- η αρχιτεκτονική είναι θεμελιωδώς ασύμβατη με τις τρέχουσες απαιτήσεις,
- οι βασικές τεχνολογίες δεν υποστηρίζονται,
- το σύστημα δεν έχει αξιόπιστες δοκιμές ούτε τεκμηρίωση,
- η ασφάλεια απαιτεί ριζική αναδόμηση,
- κάθε μεγαλύτερη αλλαγή απαιτεί παρέμβαση σε σχεδόν ολόκληρο το σύστημα,
- λείπουν άνθρωποι που κατανοούν τη λειτουργία του,
- το κόστος συντήρησης και ανάπτυξης υπερβαίνει την αξία της περαιτέρω χρήσης.
Τότε αξίζει να υπολογίσετε όχι μόνο το κόστος του εκσυγχρονισμού.
Πρέπει να υπολογίσετε επίσης το κόστος της παραμονής στην τρέχουσα λύση.
Η ακριβότερη εφαρμογή δεν είναι πάντα αυτή που κοστίζει περισσότερο στη συντήρηση
Μπορεί να έχετε ένα σύστημα του οποίου η μηνιαία συντήρηση κοστίζει σχετικά λίγο.
Και ταυτόχρονα κάθε νέα λειτουργία κοστίζει πολλαπλάσια από όσο θα έπρεπε.
Γι' αυτό και μόνο το τιμολόγιο για hosting, server ή support δεν λέει ακόμα πόσο κοστίζει η τεχνολογία.
Το πραγματικό κόστος του συστήματος περιλαμβάνει επίσης:
- χρόνο ανάπτυξης,
- χρόνο δοκιμών,
- κόστος σφαλμάτων,
- χρόνο διάθεσης σε παραγωγή,
- κόστος διακοπών,
- δυσκολία πρόσληψης,
- κίνδυνος ασφάλειας,
- κόστος απώλειας γνώσης,
- καθυστέρηση νέων λειτουργιών,
- περιορισμοί της επιχείρησης που προκύπτουν από την τεχνολογία.
Σε κάποιο σημείο η τεχνολογία παύει να είναι εργαλείο που στηρίζει την επιχείρηση.
Αρχίζει να αποτελεί περιορισμό για την επιχείρηση.
Πώς να προσεγγίσετε την απόφαση;
Πριν ληφθεί η απόφαση «το ξαναγράφουμε από την αρχή», αξίζει να γίνει ένας τεχνικός έλεγχος.
Θα πρέπει να περιλαμβάνει τουλάχιστον:
Αρχιτεκτονική - πώς είναι χωρισμένο το σύστημα και πώς επικοινωνούν τα στοιχεία του.
Κώδικα - ποιότητα, πολυπλοκότητα, επαναληψιμότητα και σημεία ιδιαίτερα δύσκολα στη συντήρηση.
Εξαρτήσεις - frameworks, βιβλιοθήκες, εκδόσεις και η υποστήριξή τους.
Ασφάλεια - ευπάθειες, τρόπος διαχείρισης της πρόσβασης και κίνδυνοι που προκύπτουν από παρωχημένα στοιχεία.
Δοκιμές - εύρος αυτοματοποίησης και δυνατότητα ασφαλούς εισαγωγής αλλαγών.
CI/CD - τρόπος δημιουργίας, δοκιμής και ανάπτυξης της εφαρμογής.
Δεδομένα - δομή της βάσης, μεταναστεύσεις, ενσωματώσεις και εξαρτήσεις.
Παρακολούθηση - αν είναι γνωστό τι συμβαίνει με το σύστημα μετά την ανάπτυξη.
Διαδικασία ανάπτυξης - πόσο πραγματικά κοστίζει η παράδοση της επόμενης λειτουργίας.
Μόνο με βάση αυτά μπορεί κανείς να εξετάσει ρεαλιστικά τρία σενάρια:
- το διατηρούμε και το εξελίσσουμε,
- το εκσυγχρονίζουμε σταδιακά,
- χτίζουμε ένα νέο σύστημα.
Δεν υπάρχει μία σωστή απάντηση. Υπάρχει όμως ο σωστός τρόπος να φτάσουμε στην απάντηση.
Η τεχνολογία πρέπει να επιτρέπει την ανάπτυξη, όχι να την μπλοκάρει
Η καλή αρχιτεκτονική δεν σημαίνει ότι το σύστημα φαίνεται σύγχρονο.
Σημαίνει ότι μπορεί να αλλάζει όταν το απαιτεί η επιχείρηση.
Γι’ αυτό αξίζει να βλέπουμε την εφαρμογή όχι μόνο μέσα από το πρίσμα του αν λειτουργεί σήμερα.
Πρέπει επίσης να ελέγξουμε, πόσο θα κοστίσει η προσθήκη επιπλέον λειτουργιών σε ένα, δύο ή πέντε χρόνια.
Γιατί ένα σύστημα που λειτουργεί, αλλά εμποδίζει την ομαλή ανάπτυξη, μπορεί να είναι πολύ μεγαλύτερο πρόβλημα από ένα σύστημα που απλώς χρειάζεται εκσυγχρονισμό.
