Όταν ένα ακόμη feature αλλάζει τα πάντα: το πραγματικό κόστος της πολυπλοκότητας στο software

Ένα σύστημα μπορεί να λειτουργεί άψογα για δέκα διαφορετικές περιπτώσεις. Το ενδέκατο requirement όμως μπορεί να μην προσθέσει απλώς «λίγη ακόμη δουλειά». Μπορεί να αλλάξει σημαντικά την πολυπλοκότητα ολόκληρης της λύσης.

Αυτό είναι ένα από τα πιο συχνά σημεία παρεξήγησης στην ανάπτυξη software.

Από την πλευρά του χρήστη ή της επιχείρησης, μια νέα απαίτηση μπορεί να φαίνεται σαν μια μικρή προσθήκη:

«Να υποστηρίζει και αυτή την περίπτωση.»

«Να γίνεται και αυτόματα.»

«Να υπάρχει και ένας ακόμη κανόνας.»

«Να συνδέεται και με αυτό το σύστημα.»

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

Και κάπου εκεί, η πολυπλοκότητα αρχίζει να επηρεάζει όχι μόνο το κόστος της αρχικής υλοποίησης, αλλά και το κόστος συντήρησης για τα επόμενα χρόνια.

Η πολυπλοκότητα δεν αυξάνεται πάντα γραμμικά

Ας υποθέσουμε ότι έχουμε μια διαδικασία με δέκα ξεκάθαρους κανόνες.

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

Το πρόβλημα ξεκινά όταν οι κανόνες αρχίζουν να αλληλεπιδρούν.

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

Τότε δεν έχουμε απλώς μία ακόμη λειτουργία.

Έχουμε περισσότερους πιθανούς συνδυασμούς συμπεριφοράς.

Και όσο αυξάνονται οι συνδυασμοί, αυξάνονται αντίστοιχα:

• τα σενάρια που πρέπει να ελεγχθούν,

• οι πιθανότητες για edge cases,

• τα σημεία στα οποία μπορεί να υπάρξει λάθος,

• ο χρόνος debugging,

• το κόστος μελλοντικών αλλαγών.

Το πρόβλημα δεν είναι απαραίτητα τα πολλά features

Ένα μεγάλο σύστημα δεν είναι από μόνο του προβληματικό.

Μπορεί να έχει εκατοντάδες λειτουργίες και να παραμένει διαχειρίσιμο, αρκεί αυτές οι λειτουργίες να έχουν σχεδιαστεί σωστά και να είναι οργανωμένες με ξεκάθαρα όρια.

Το πραγματικό πρόβλημα εμφανίζεται όταν κάθε νέα λειτουργία πρέπει να γνωρίζει τι κάνουν όλες οι υπόλοιπες.

Για παράδειγμα, ένα νέο business rule που επηρεάζει ταυτόχρονα:

την τιμολόγηση,

τις παραγγελίες,

τα emails,

το ERP,

τα reports,

τα δικαιώματα χρηστών

και έναν εξωτερικό συνεργάτη,

δεν είναι πλέον ένα μεμονωμένο feature.

Είναι αλλαγή σε ένα ολόκληρο δίκτυο εξαρτήσεων.

Γιατί το «είναι μια μικρή αλλαγή» μπορεί να είναι παραπλανητικό

Στο software, το μέγεθος μιας αλλαγής δεν καθορίζεται μόνο από το πόσες γραμμές κώδικα χρειάζεται.

Μια αλλαγή δέκα γραμμών μπορεί να είναι πολύ πιο επικίνδυνη από μια νέα λειτουργία εκατοντάδων γραμμών.

Η πραγματική ερώτηση είναι:

Σε πόσα διαφορετικά σημεία του συστήματος επηρεάζει αυτή η αλλαγή τη συμπεριφορά;

Αν ένα νέο requirement δημιουργεί πολλές νέες εξαρτήσεις, το κόστος δεν βρίσκεται μόνο στην υλοποίηση.

Βρίσκεται και σε όλα όσα πρέπει να ελεγχθούν γύρω από αυτή.

Το κόστος της πολυπλοκότητας εμφανίζεται κυρίως μετά την παράδοση

Στην αρχή ενός project, το μεγαλύτερο μέρος της συζήτησης αφορά συνήθως το κόστος κατασκευής.

Στην πραγματικότητα όμως, ένα software system μπορεί να χρησιμοποιείται για πέντε, δέκα ή περισσότερα χρόνια.

Αυτό σημαίνει ότι η αρχιτεκτονική του επηρεάζει κάθε αλλαγή που θα γίνει στο μέλλον.

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

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

Ένα bug μπορεί να απαιτεί αρκετές ώρες investigation επειδή δεν είναι ξεκάθαρο ποιο υποσύστημα δημιούργησε το πρόβλημα.

Ένα νέο integration μπορεί να απαιτεί αλλαγές σε πολλά διαφορετικά σημεία της εφαρμογής.

Μεμονωμένα, αυτά τα κόστη φαίνονται μικρά.

Σε βάθος χρόνου όμως συσσωρεύονται.

Η πολυπλοκότητα αυξάνει και το κόστος των tests

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

Δεν αρκεί πλέον να ελέγξουμε ότι το Feature A λειτουργεί.

Πρέπει να ελέγξουμε:

τι γίνεται όταν λειτουργεί μαζί με το Feature B,

τι γίνεται όταν το Feature C είναι απενεργοποιημένο,

τι γίνεται όταν λείπουν δεδομένα,

τι γίνεται όταν αποτύχει ένα εξωτερικό API,

τι γίνεται όταν ο χρήστης έχει διαφορετικά permissions,

τι γίνεται όταν η διαδικασία εκτελείται δεύτερη φορά.

Κάθε νέα εξαίρεση δημιουργεί νέες πιθανές διαδρομές μέσα στο σύστημα.

Αυτός είναι και ο λόγος που τα καλά automated tests δεν είναι πολυτέλεια σε ένα σύνθετο project. Είναι μέρος του τρόπου με τον οποίο το software παραμένει αξιόπιστο όσο εξελίσσεται.

«Αν το χτίσεις σωστά, θα κάνει πάντα σωστά αυτό που σχεδιάστηκε να κάνει»

Ένα από τα μεγαλύτερα πλεονεκτήματα του software είναι η συνέπεια.

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

Αυτό είναι ιδιαίτερα σημαντικό σε Automation Workflows, όπου ο στόχος είναι συχνά να αφαιρεθούν χειροκίνητες εργασίες και να μετατραπούν σε προβλέψιμες διαδικασίες.

Το software όμως δεν γνωρίζει από μόνο του όλες τις πιθανές εξαιρέσεις.

Λειτουργεί μέσα στα όρια που έχουμε σχεδιάσει.

Αν έχουμε σχεδιάσει δέκα περιπτώσεις, μπορούμε να δημιουργήσουμε ένα εξαιρετικά αξιόπιστο σύστημα για αυτές τις δέκα περιπτώσεις.

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

Αυτή η διαφορά είναι καθοριστική.

Πώς μπορούμε να περιορίσουμε την πολυπλοκότητα

Δεν μπορούμε πάντα να αποφύγουμε την πολυπλοκότητα.

Μερικές επιχειρηματικές διαδικασίες είναι από τη φύση τους σύνθετες.

Μπορούμε όμως να αποφύγουμε την περιττή πολυπλοκότητα.

1. Ξεκινάμε από τη διαδικασία και όχι από τα features

Πριν ξεκινήσει η ανάπτυξη, πρέπει να είναι ξεκάθαρο ποιο πρόβλημα προσπαθούμε να λύσουμε.

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

Η σωστή ερώτηση δεν είναι:

«Τι άλλο μπορούμε να προσθέσουμε;»

Αλλά:

«Τι χρειάζεται πραγματικά για να λειτουργήσει καλύτερα η διαδικασία;»

2. Χωρίζουμε το σύστημα σε ξεκάθαρες λειτουργικές ενότητες

Όταν οι διαφορετικές λειτουργίες είναι όσο γίνεται ανεξάρτητες μεταξύ τους, οι αλλαγές γίνονται ασφαλέστερες.

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

Αυτό είναι ιδιαίτερα σημαντικό στις custom πλατφόρμες, οι οποίες συνήθως εξελίσσονται μαζί με την επιχείρηση.

Η αρχιτεκτονική δεν πρέπει να σχεδιάζεται μόνο για το τι χρειάζεται η πλατφόρμα σήμερα.

Πρέπει να επιτρέπει και τις αλλαγές που είναι λογικό να εμφανιστούν αύριο.

3. Δεν μετατρέπουμε κάθε εξαίρεση σε νέο κανόνα

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

«Για αυτόν τον πελάτη κάνε αυτό.»

«Εκτός αν είναι αυτή η κατηγορία.»

«Αν όμως προέρχεται από αυτό το κανάλι, κάνε κάτι διαφορετικό.»

«Εκτός από Παρασκευή.»

Κάποια στιγμή το software παύει να ακολουθεί μια καθαρή επιχειρηματική διαδικασία και αρχίζει να αποτελεί συλλογή εξαιρέσεων.

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

4. Αυτοματοποιούμε τους ελέγχους

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

Αυτό γίνεται όλο και πιο σημαντικό όσο μεγαλώνει ένα σύστημα.

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

Με σωστά tests, πολλές από αυτές τις περιπτώσεις μπορούν να ελέγχονται αυτόματα.

5. Παρακολουθούμε τι πραγματικά συμβαίνει στο σύστημα

Ένα σύνθετο σύστημα πρέπει να μπορεί να εξηγεί τι έκανε.

Logs, ιστορικό ενεργειών, monitoring και κατάλληλα reports βοηθούν σημαντικά όταν πρέπει να βρεθεί γιατί μια διαδικασία δεν συμπεριφέρθηκε όπως περιμέναμε.

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

6. Προσθέτουμε πολυπλοκότητα μόνο όταν δημιουργεί αντίστοιχη αξία

Δεν χρειάζεται κάθε πιθανό σενάριο να αυτοματοποιείται.

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

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

Το σωστό software δεν είναι αυτό που αυτοματοποιεί τα πάντα.

Είναι αυτό που αυτοματοποιεί τα σωστά πράγματα.

Η απλότητα είναι αποτέλεσμα σχεδιασμού

Τα συστήματα που φαίνονται απλά στον χρήστη δεν είναι απαραίτητα απλά εσωτερικά.

Συχνά συμβαίνει το αντίθετο.

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

Η καλή αρχιτεκτονική δεν εξαφανίζει την πολυπλοκότητα.

Την οργανώνει.

Τη βάζει σε συγκεκριμένα σημεία και περιορίζει το πόσο εύκολα μπορεί να εξαπλωθεί σε ολόκληρο το σύστημα.

Συμπέρασμα

Στο software, ένα ακόμη feature δεν σημαίνει πάντα ένα ακόμη μικρό κομμάτι δουλειάς.

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

Για αυτό η σωστή ανάπτυξη software δεν αφορά μόνο την υλοποίηση features.

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

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