Τεχνικό χρέος στο λογισμικό: πώς το αξιολογείτε και το μειώνετε

Το τεχνικό χρέος στο λογισμικό είναι το επιπλέον κόστος και ρίσκο που συσσωρεύονται όταν μια εφαρμογή αναπτύσσεται με πρόχειρες λύσεις, παλιές εξαρτήσεις, διπλά δεδομένα ή ελλιπή τεκμηρίωση. Συνήθως δεν φαίνεται την ημέρα της υλοποίησης. Εμφανίζεται αργότερα ως καθυστερήσεις, βλάβες, ευάλωτα σημεία και δυσκολία σε κάθε νέα αλλαγή.

Τι σημαίνει τεχνικό χρέος και γιατί αυξάνεται χωρίς να φαίνεται

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

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

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

Πού κρύβεται το κόστος μιας εφαρμογής που συνεχίζει να λειτουργεί

Η εφαρμογή μπορεί να ανοίγει κάθε πρωί και να εξυπηρετεί τις βασικές ανάγκες της επιχείρησης. Αυτό δεν σημαίνει ότι βρίσκεται σε καλή κατάσταση. Το πραγματικό κόστος φαίνεται όταν ζητηθεί κάτι νέο ή όταν παρουσιαστεί μια αστοχία.

• Πρόχειρες υλοποιήσεις: μια αλλαγή σε ένα σημείο επηρεάζει απρόβλεπτα άλλα σημεία. Η διόρθωση γίνεται αργή και χρειάζεται περισσότερους ελέγχους.
• Παλιές εξαρτήσεις: βιβλιοθήκες, πλαίσια ανάπτυξης ή εκδόσεις λειτουργικών συστημάτων χωρίς ενεργή υποστήριξη αυξάνουν τον κίνδυνο ασφάλειας και δυσκολεύουν την αναβάθμιση.
• Διπλά και ασυνεπή δεδομένα: όταν το ίδιο στοιχείο υπάρχει σε πολλά αρχεία ή συστήματα, οι ομάδες αντιγράφουν πληροφορίες και διορθώνουν χειροκίνητα λάθη. Η ασυνέπεια που συναντάται συχνά σε αρχεία υπολογιστικών φύλλων είναι χαρακτηριστικό παράδειγμα.
• Ελλιπής τεκμηρίωση: η γνώση μεταφέρεται προφορικά. Αν αποχωρήσει ένα βασικό άτομο, η ομάδα δυσκολεύεται να καταλάβει τι κάνει κάθε μέρος της εφαρμογής και γιατί.
• Ασύνδετα συστήματα: χωρίς σωστές διασυνδέσεις εφαρμογών, οι εργαζόμενοι μεταφέρουν δεδομένα με αντιγραφή και επικόλληση. Εκτός από τη σπατάλη χρόνου, αυξάνεται η πιθανότητα λάθους.

Χρειάζεται πάντως μια διάκριση. Το προσωρινό τεχνικό χρέος δεν είναι πάντα κακή απόφαση. Μια ομάδα μπορεί να επιλέξει συνειδητά μια απλούστερη λύση για να δοκιμάσει μια επιχειρηματική υπόθεση, αρκεί να καταγράψει τι πρέπει να διορθωθεί και μέχρι πότε. Το πρόβλημα είναι η συσσωρευμένη αμέλεια: χρέος που κανείς δεν έχει καταγράψει, δεν έχει κοστολογήσει και δεν έχει εντάξει σε πλάνο.

Έτσι, μια εφαρμογή μπορεί να λειτουργεί σήμερα, αλλά κάθε επόμενη αλλαγή να κοστίζει περισσότερο. Η σύνδεση με ένα νέο σύστημα καθυστερεί, μια αναφορά χρειάζεται χειροκίνητη επεξεργασία και μια μικρή αλλαγή στη διαδικασία τιμολόγησης προκαλεί απρόβλεπτες παρενέργειες.

Πώς αξιολογείτε πρακτικά το τεχνικό χρέος;

Η αξιολόγηση τεχνικού χρέους ξεκινά με αποτύπωση, όχι με εικασίες. Μια τεχνική και επιχειρησιακή ομάδα πρέπει να εξετάσει την εφαρμογή μαζί, επειδή ο κώδικας από μόνος του δεν δείχνει πάντα ποιο πρόβλημα κοστίζει περισσότερο στην καθημερινή λειτουργία.

Χρησιμοποιήστε την παρακάτω λίστα ελέγχου σε έναν τεχνικό έλεγχο εφαρμογής:

• Κώδικας: Ποια μέρη δεν μπορούν να αλλάξουν με ασφάλεια; Υπάρχουν επαναλαμβανόμενες λύσεις, πολύπλοκες συναρτήσεις ή τμήματα που κανείς δεν τολμά να αγγίξει;
• Αρχιτεκτονική: Είναι ξεκάθαρο πώς συνδέονται τα βασικά τμήματα; Υπάρχουν σημεία όπου μια αστοχία σταματά ολόκληρη τη λειτουργία;
• Εξαρτήσεις: Ποιες βιβλιοθήκες και εκδόσεις χρησιμοποιούνται; Υποστηρίζονται ακόμη; Υπάρχει διαδικασία για ενημερώσεις και έλεγχο ευπαθειών;
• Βάση δεδομένων: Ποια στοιχεία επαναλαμβάνονται; Υπάρχουν διαφορετικές τιμές για τον ίδιο πελάτη ή προϊόν; Μπορεί η ομάδα να εντοπίσει την πραγματική πηγή κάθε δεδομένου;
• Διασυνδέσεις: Ποια συστήματα επικοινωνούν μεταξύ τους; Καταγράφονται οι αποτυχίες συγχρονισμού; Υπάρχουν χειροκίνητα βήματα που θα μπορούσαν να αυτοματοποιηθούν;
• Ασφάλεια: Ποιος έχει πρόσβαση σε δεδομένα και λειτουργίες; Υπάρχουν παλιοί λογαριασμοί, κοινόχρηστοι κωδικοί ή εξαρτήσεις με γνωστά προβλήματα;
• Δοκιμές: Υπάρχουν αυτοματοποιημένοι έλεγχοι για τις πιο σημαντικές λειτουργίες; Ποια αλλαγή δεν μπορεί να γίνει χωρίς φόβο ότι θα διακοπεί κάτι άλλο;
• Παρακολούθηση: Πώς μαθαίνει η ομάδα ότι μια λειτουργία απέτυχε; Υπάρχουν αρχεία συμβάντων και ειδοποιήσεις που οδηγούν σε χρήσιμη διάγνωση;
• Τεκμηρίωση: Μπορεί ένας νέος συνεργάτης να καταλάβει τη ροή μιας βασικής διαδικασίας; Είναι γραμμένες οι εξαιρέσεις και οι κρίσιμες επιχειρησιακές παραδοχές;
• Διαδικασία ανάπτυξης: Υπάρχουν έλεγχοι πριν από τη δημοσίευση; Η ομάδα μπορεί να επιστρέψει γρήγορα σε προηγούμενη έκδοση αν κάτι πάει στραβά;

Οι απαντήσεις πρέπει να συνοδεύονται από παραδείγματα. Το «η ασφάλεια χρειάζεται βελτίωση» δεν αρκεί. Χρειάζεται να ξέρουμε ποια πρόσβαση είναι προβληματική, ποιο δεδομένο κινδυνεύει και ποια διαδικασία επηρεάζεται.

Πώς μετριέται η σοβαρότητα κάθε προβλήματος

Η ηλικία του κώδικα και η αισθητική του δεν αρκούν για την ιεράρχηση. Ένα παλιό αλλά σταθερό τμήμα μπορεί να περιμένει, ενώ μια μικρή καινούργια εξάρτηση μπορεί να δημιουργεί άμεσο κίνδυνο.

Καταγράψτε κάθε εύρημα σε έναν πίνακα με τα εξής πεδία:

• πρόβλημα και πιθανή αιτία,
• επιχειρησιακή επίπτωση,
• πιθανότητα αστοχίας,
• επίδραση σε ασφάλεια, δεδομένα και πελάτες,
• εκτιμώμενη προσπάθεια διόρθωσης,
• εξαρτήσεις από άλλα συστήματα ή ομάδες,
• προτεινόμενο επόμενο βήμα.

Προηγούνται συνήθως η πιθανή απώλεια δεδομένων, μια ευάλωτη εξάρτηση, η αδυναμία ανάκτησης μετά από βλάβη και ένα σημείο που μπορεί να σταματήσει κρίσιμη επιχειρησιακή διαδικασία. Μπορούν να περιμένουν ζητήματα μορφοποίησης, μικρές ενοχλήσεις στη διαχείριση ή τμήματα κώδικα που είναι δυσάρεστα στην ανάγνωση αλλά δεν δημιουργούν άμεσο κίνδυνο.

Μια πρακτική σειρά είναι: υψηλός κίνδυνος και μικρή προσπάθεια πρώτα, υψηλός κίνδυνος και μεγάλη προσπάθεια με ξεχωριστό σχέδιο, και τέλος χαμηλής επίπτωσης βελτιώσεις μέσα στη συνηθισμένη ανάπτυξη. Έτσι το κόστος τεχνικού χρέους συνδέεται με πραγματικές αποφάσεις και όχι με μια γενική λίστα παραπόνων.

Πώς μειώνετε το χρέος χωρίς να σταματήσετε τη λειτουργία

Η μείωση του τεχνικού χρέους δεν απαιτεί απαραίτητα πλήρη αντικατάσταση. Συνήθως χρειάζεται σειρά μικρών, ελεγχόμενων παρεμβάσεων που προστατεύουν πρώτα τη λειτουργία της επιχείρησης.

1. Αποτυπώστε την τρέχουσα κατάσταση. Καταγράψτε εφαρμογές, βάσεις δεδομένων, διασυνδέσεις, εξαρτήσεις και βασικές επιχειρησιακές ροές. Μην ξεκινήσετε με αλλαγές σε σύστημα που δεν έχει κατανοηθεί.
2. Προστατεύστε τα κρίσιμα σημεία. Ελέγξτε αντίγραφα ασφαλείας και διαδικασία επαναφοράς. Προσθέστε βασικές δοκιμές στις λειτουργίες που δεν επιτρέπεται να αποτύχουν.
3. Επιλέξτε μικρές αλλαγές με μετρήσιμο αποτέλεσμα. Για παράδειγμα, μειώστε μια χειροκίνητη μεταφορά δεδομένων ή απομονώστε μια επικίνδυνη εξάρτηση. Μετρήστε χρόνο, σφάλματα και περιστατικά πριν και μετά.
4. Ανανεώστε σταδιακά τις εξαρτήσεις. Κάθε ενημέρωση χρειάζεται έλεγχο συμβατότητας και σχέδιο επιστροφής. Η μαζική αναβάθμιση πολλών στοιχείων μαζί αυξάνει την αβεβαιότητα.
5. Καθαρίστε τα δεδομένα με κανόνες. Συμφωνήστε ποια εγγραφή είναι η σωστή, ποιος επιτρέπεται να αλλάζει δεδομένα και πώς ελέγχονται οι διπλές καταχωρίσεις.
6. Τεκμηριώστε παράλληλα με την ανάπτυξη. Μια σύντομη περιγραφή ροής, μια απόφαση αρχιτεκτονικής και οδηγίες ανάκτησης είναι πιο χρήσιμες όταν γράφονται τη στιγμή που γίνεται η αλλαγή.

Σε παλιά συστήματα, η προοδευτική αντικατάσταση ταιριάζει όταν υπάρχουν σαφή τμήματα που μπορούν να απομονωθούν. Η απομόνωση είναι προτιμότερη όταν το σύστημα παραμένει αναγκαίο, αλλά δεν πρέπει να επεκτείνεται συνεχώς. Μια νέα εξατομικευμένη διαδικτυακή εφαρμογή έχει νόημα όταν οι επιχειρησιακές ανάγκες έχουν αλλάξει τόσο, ώστε οι παλιές παραδοχές εμποδίζουν κάθε ασφαλή εξέλιξη. Δείτε τη λύση για εξατομικευμένες διαδικτυακές εφαρμογές.

Η συντήρηση λογισμικού δεν είναι εργασία που γίνεται μόνο μετά από βλάβη. Περιλαμβάνει ενημερώσεις, ελέγχους, παρακολούθηση, διορθώσεις και τακτική επανεξέταση των κινδύνων. Για τα παλιά συστήματα, αυτή η πειθαρχία βοηθά να αποφασιστεί αν χρειάζεται διατήρηση, περιορισμός ή εκσυγχρονισμός.

Ένα ρεαλιστικό πλάνο για τις επόμενες αποφάσεις

Ξεκινήστε με έναν σύντομο τεχνικό έλεγχο που θα συνδέσει τα τεχνικά ευρήματα με τις επιχειρησιακές επιπτώσεις. Καταγράψτε το χρέος, βαθμολογήστε τον κίνδυνο, επιλέξτε λίγες διορθώσεις και επανεξετάστε την πρόοδο σε σταθερό κύκλο.

Το ζητούμενο δεν είναι να γίνει ο κώδικας τέλειος. Είναι να μειωθούν πρώτα οι κίνδυνοι που μπορούν να κοστίσουν δεδομένα, χρόνο, πελάτες ή τη συνέχεια της λειτουργίας. Η Saikō μπορεί να συμβάλει στην αξιολόγηση, στη συντήρηση ή στον σχεδιασμό μιας νέας λύσης όταν τα στοιχεία δείχνουν ότι η σταδιακή διόρθωση δεν επαρκεί.