Ανάπτυξη εφαρμογών, ιστοσελίδων και καταστημάτων: σχεδιάζοντας τη λειτουργία πριν τον κώδικα
Ένα σύγχρονο ηλεκτρονικό κατάστημα ή μια διαδικτυακή εφαρμογή δεν είναι απλώς σύνολο οθονών. Είναι μια αλληλουχία επιχειρησιακών ενεργειών: κάποιος βλέπει δεδομένα, κάνει μια επιλογή, υποβάλλει πληροφορίες, δημιουργείται μια παραγγελία ή εργασία, αλλάζει μια κατάσταση και κάποιο άλλο σύστημα ή άνθρωπος πρέπει να αντιδράσει. Αν αυτή η ροή δεν αποτυπωθεί πριν αρχίσει η υλοποίηση, η ανάπτυξη κινδυνεύει να μεταφέρει στον κώδικα ασάφειες της επιχείρησης. Η σωστή λύση ξεκινά από μοντέλο δεδομένων, ρόλους, καταστάσεις και κανόνες αποτυχίας και μετά αποφασίζει πώς θα παρουσιαστούν στον χρήστη.
Η εφαρμογή πρέπει να καθρεφτίζει μια πραγματική επιχειρησιακή ροή
Το πρώτο βήμα είναι να περιγραφεί τι συμβαίνει από την αρχή μέχρι το τέλος χωρίς τεχνικούς όρους. Σε ένα κατάστημα, για παράδειγμα, ο πελάτης βρίσκει προϊόν, επιλέγει παραλλαγή, βλέπει διαθεσιμότητα, δημιουργεί καλάθι, δηλώνει στοιχεία, επιλέγει τρόπο παραλαβής και ολοκληρώνει την παραγγελία. Μετά ξεκινά μια εσωτερική ροή: επιβεβαίωση, προετοιμασία, αποστολή, ακύρωση ή επιστροφή. Κάθε βήμα πρέπει να έχει σαφή ιδιοκτήτη και αποτέλεσμα.
Η ανάπτυξη εφαρμογών γίνεται πιο σταθερή όταν οι ροές σχεδιάζονται πριν από τις οθόνες. Έτσι φαίνεται ποια δεδομένα χρειάζονται πραγματικά, ποια κατάσταση πρέπει να αποθηκεύεται και ποια ενέργεια δεν πρέπει να επιτρέπεται σε κάθε σημείο.
Ο κατάλογος προϊόντων είναι μοντέλο δεδομένων, όχι μόνο σελίδα
Ένα προϊόν μπορεί να έχει τίτλο, περιγραφή, κωδικό, κατηγορία, τιμή, εικόνες, παραλλαγές, διαθεσιμότητα και άλλα χαρακτηριστικά. Αν δεν οριστεί ποια πεδία είναι υποχρεωτικά και πώς σχετίζονται, η καταχώριση γίνεται ασυνεπής και η αναζήτηση ή τα φίλτρα δυσκολεύουν. Το μοντέλο πρέπει να υποστηρίζει τις πραγματικές διαφοροποιήσεις χωρίς να απαιτεί ειδική εξαίρεση για κάθε νέο προϊόν.
Χρειάζεται επίσης να αποφασιστεί ποια πληροφορία είναι πηγή αλήθειας. Αν η τιμή ή το απόθεμα ενημερώνονται αλλού, το κατάστημα δεν πρέπει να δημιουργεί δεύτερη ανεξάρτητη πραγματικότητα. Η αρχιτεκτονική οφείλει να δηλώνει ποιο σύστημα είναι υπεύθυνο για κάθε κρίσιμο δεδομένο και πώς αντιμετωπίζεται μια αποτυχημένη ενημέρωση.
Η παραγγελία χρειάζεται σαφείς καταστάσεις και επιτρεπτές μεταβάσεις
Η παραγγελία δεν είναι απλώς «νέα» ή «ολοκληρωμένη». Συνήθως περνά από ενδιάμεσες καταστάσεις που έχουν λειτουργική σημασία. Το σημαντικό είναι να οριστούν οι επιτρεπτές μεταβάσεις και ποιος μπορεί να τις προκαλέσει. Δεν πρέπει, για παράδειγμα, μια ενέργεια χρήστη να παρακάμπτει στάδιο που απαιτεί έλεγχο από την επιχείρηση ή να δημιουργείται αποστολή όταν η παραγγελία έχει ήδη ακυρωθεί.
Οι καταστάσεις πρέπει να είναι αρκετές για να περιγράφουν τη λειτουργία αλλά όχι τόσο πολλές ώστε κανείς να μην ξέρει ποια χρησιμοποιείται. Κάθε αλλαγή καλό είναι να αφήνει ίχνος χρόνου και ενέργειας. Έτσι μπορεί να εντοπιστεί τι συνέβη όταν ο πελάτης ή η ομάδα υποστήριξης αναζητά μια συγκεκριμένη παραγγελία.
Η πληρωμή πρέπει να απομονώνεται από την υπόλοιπη ροή
Η διαδικασία πληρωμής χρειάζεται σαφή όρια. Η εφαρμογή στέλνει τα απαραίτητα στοιχεία στον πάροχο, λαμβάνει αποτέλεσμα και ενημερώνει την παραγγελία μόνο με βάση επιβεβαιωμένο γεγονός. Δεν πρέπει η επιστροφή του χρήστη σε μια σελίδα να θεωρείται από μόνη της απόδειξη επιτυχίας. Εξίσου σημαντικό είναι να αντιμετωπίζονται καθυστερήσεις, ακυρώσεις ή επαναλαμβανόμενες ειδοποιήσεις χωρίς να δημιουργούνται διπλές παραγγελίες ή χρεώσεις.
Η λεπτομερής τεχνική μέθοδος εξαρτάται από τον πάροχο και τη λύση, όμως η επιχειρησιακή απαίτηση είναι σταθερή: μία παραγγελία πρέπει να έχει συνεπή κατάσταση ακόμη και όταν η πληρωμή δεν ακολουθεί την ιδανική διαδρομή.
Το απόθεμα χρειάζεται ξεκάθαρη πηγή και κανόνες συγχρονισμού
Όταν προϊόντα πωλούνται ταυτόχρονα από φυσικό κατάστημα, τηλεφωνικά και ηλεκτρονικά, η διαθεσιμότητα μπορεί να αλλάζει από πολλά σημεία. Πριν αναπτυχθεί ο συγχρονισμός, πρέπει να αποφασιστεί ποιο σύστημα έχει τον τελικό λόγο και πότε δεσμεύεται ποσότητα. Αν η κράτηση γίνεται πολύ νωρίς, μπορεί να μπλοκάρει προϊόν χωρίς πραγματική αγορά. Αν γίνεται πολύ αργά, δύο πελάτες μπορεί να θεωρούν διαθέσιμο το ίδιο τελευταίο τεμάχιο.
Η λύση πρέπει επίσης να προβλέπει τι θα συμβεί όταν η σύνδεση μεταξύ συστημάτων διακοπεί. Θα επιτραπούν νέες παραγγελίες; Θα εμφανιστεί τελευταία γνωστή κατάσταση; Θα ζητηθεί χειροκίνητη επιβεβαίωση; Αυτές οι αποφάσεις είναι επιχειρησιακές και πρέπει να ληφθούν πριν μετατραπούν σε τεχνικό κανόνα.
Οι διασυνδέσεις χρειάζονται σχέδιο και για την αποτυχία
Κάθε εξωτερικό σύστημα προσθέτει δυνατότητα αλλά και εξάρτηση. Μια διασύνδεση με αποστολές, λογιστική, αποθήκη ή άλλο εργαλείο πρέπει να περιγράφει ποια δεδομένα στέλνονται, ποια επιστρέφουν και ποια είναι η συμπεριφορά όταν η άλλη πλευρά δεν απαντά. Η επιτυχής περίπτωση είναι μόνο η μισή σχεδίαση. Η άλλη μισή είναι η ασφαλής επανάληψη, η καταγραφή σφάλματος και η δυνατότητα ανθρώπινης παρέμβασης.
Στην ανάπτυξη διαδικτυακών εφαρμογών, η ορατότητα των αποτυχιών είναι κρίσιμη. Ένα σφάλμα που καταγράφεται και μπορεί να διορθωθεί είναι διαχειρίσιμο. Ένα σφάλμα που χάνεται σιωπηλά δημιουργεί ανακολουθίες οι οποίες εμφανίζονται αργότερα σε παραγγελίες, αποθέματα ή στοιχεία πελατών.
Ρόλοι και δικαιώματα πρέπει να ακολουθούν τις πραγματικές ευθύνες
Δεν χρειάζονται όλοι οι χρήστες πρόσβαση σε όλα. Ο πελάτης, ο υπάλληλος παραγγελιών, ο διαχειριστής καταλόγου και ο τεχνικός μπορεί να χρειάζονται διαφορετικές ενέργειες. Ο σχεδιασμός των ρόλων πρέπει να βασίζεται στο ελάχιστο απαραίτητο δικαίωμα για κάθε εργασία. Αυτό μειώνει τυχαίες αλλαγές και κάνει πιο καθαρό ποιος μπορεί να δει ή να τροποποιήσει κρίσιμα δεδομένα.
Οι ειδικές εξαιρέσεις πρέπει να είναι λίγες και τεκμηριωμένες. Αν κάθε χρήστης καταλήγει να έχει μοναδικό συνδυασμό δικαιωμάτων, η διαχείριση γίνεται δύσκολη και ο έλεγχος ασαφής. Καλύτερα να υπάρχουν καθαροί ρόλοι που αντιστοιχούν σε πραγματικές ευθύνες μέσα στην επιχείρηση.
Η απόδοση μετριέται στις πραγματικές διαδρομές του χρήστη
Μια γρήγορη αρχική σελίδα δεν αρκεί αν η αναζήτηση προϊόντων, το άνοιγμα κατηγορίας ή το καλάθι καθυστερούν. Ο έλεγχος απόδοσης πρέπει να καλύπτει τις διαδρομές που δημιουργούν αξία: εύρεση προϊόντος, εφαρμογή φίλτρων, προσθήκη στο καλάθι, υποβολή φόρμας και διαχείριση παραγγελίας. Η ποσότητα δεδομένων στις δοκιμές πρέπει να πλησιάζει τη ρεαλιστική χρήση ώστε να μην κρύβονται προβλήματα που εμφανίζονται μόνο όταν ο κατάλογος μεγαλώσει.
Η ανάπτυξη ιστοσελίδων και καταστημάτων πρέπει να λαμβάνει υπόψη και τη συντήρηση της απόδοσης. Νέα πρόσθετα, μεγαλύτερες εικόνες ή πολύπλοκες αναζητήσεις μπορούν να αλλάξουν τη συμπεριφορά με τον χρόνο, άρα χρειάζεται δυνατότητα μέτρησης και σύγκρισης μετά από σημαντικές αλλαγές.
Οι δοκιμές πρέπει να περιλαμβάνουν αποτυχίες και επαναλήψεις
Ένα έργο που δοκιμάζει μόνο την ιδανική διαδρομή δεν έχει ελεγχθεί αρκετά. Χρειάζονται σενάρια όπου η πληρωμή αποτυγχάνει, ο χρήστης πατά δύο φορές, η διασύνδεση καθυστερεί, ένα προϊόν εξαντλείται ανάμεσα σε δύο βήματα ή μια φόρμα περιέχει λανθασμένα δεδομένα. Το σύστημα πρέπει να επιστρέφει σε συνεπή κατάσταση και να δίνει κατανοητό μήνυμα, χωρίς να χάνει την παραγγελία ή να δημιουργεί διπλό αποτέλεσμα.
Οι δοκιμές πρέπει να συνδέονται με τις επιχειρησιακές απαιτήσεις. Αν μια απαίτηση είναι «δεν επιτρέπεται αποστολή χωρίς επιβεβαιωμένη παραγγελία», πρέπει να υπάρχει σενάριο που αποδεικνύει ότι ο κανόνας τηρείται ακόμη και σε ασυνήθιστη σειρά ενεργειών.
Η εξέλιξη γίνεται ασφαλέστερα με μικρές ελεγχόμενες αλλαγές
Μετά την πρώτη έκδοση θα εμφανιστούν νέες ανάγκες. Το ζητούμενο είναι να μην μετατρέπεται κάθε ιδέα σε άμεση παρέμβαση στον πυρήνα. Καταγράφεται η ανάγκη, προσδιορίζεται ποιον χρήστη εξυπηρετεί, εξετάζεται η επίδραση στα δεδομένα και στις υπάρχουσες ροές και μετά σχεδιάζεται η μικρότερη αλλαγή που λύνει το πρόβλημα. Αυτό κρατά το σύστημα κατανοητό και περιορίζει παρενέργειες.
Μια ώριμη λύση δεν είναι εκείνη που έχει τις περισσότερες λειτουργίες. Είναι εκείνη στην οποία τα δεδομένα έχουν σαφή ιδιοκτησία, οι καταστάσεις έχουν νόημα, τα σφάλματα γίνονται ορατά, οι ρόλοι είναι καθαροί και οι νέες δυνατότητες μπορούν να προστεθούν χωρίς να ακυρώνουν την αξιοπιστία των υπαρχουσών.
Αρχιτεκτονική σημαίνει καθαρούς κανόνες πριν από περισσότερες δυνατότητες
Η ανάπτυξη εφαρμογών, ιστοσελίδων και καταστημάτων γίνεται πιο βιώσιμη όταν πρώτα αποσαφηνίζονται οι ροές, τα δεδομένα, οι καταστάσεις, οι ρόλοι και οι συμπεριφορές σε αποτυχία. Οι οθόνες και ο κώδικας έρχονται για να υλοποιήσουν αυτούς τους κανόνες, όχι για να τους ανακαλύψουν εκ των υστέρων. Έτσι το ηλεκτρονικό κατάστημα ή η εφαρμογή μπορεί να εξυπηρετεί την πραγματική λειτουργία της επιχείρησης και να εξελίσσεται χωρίς να συσσωρεύει αόρατες αντιφάσεις.