Από πρωτότυπο σε επεκτάσιμη εφαρμογή παραγωγής

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

Πότε ένα πρωτότυπο είναι έτοιμο να γίνει εφαρμογή παραγωγής;

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

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

Ξεκινήστε από τις αποφάσεις, όχι από το πλαίσιο προγραμματισμού

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

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

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

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

Πώς συνεργάζονται το περιβάλλον χρήστη, ο διακομιστής και οι διεπαφές;

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

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

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

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

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

Δεδομένα, λογαριασμοί και δικαιώματα: εκεί δοκιμάζεται η αξιοπιστία

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

Κατά τη μετάβαση από το πρωτότυπο στην παραγωγή χρειάζονται επίσης:

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

Η ταυτοποίηση απαντά στην ερώτηση «ποιος είναι ο χρήστης;». Η εξουσιοδότηση απαντά στην ερώτηση «τι επιτρέπεται να κάνει;». Ένας χρήστης μπορεί να έχει συνδεθεί σωστά και παρ’ όλα αυτά να μην επιτρέπεται να δει μισθοδοσία, να διαγράψει παραγγελίες ή να αλλάξει ρυθμίσεις. Οι ρόλοι και τα δικαιώματα πρέπει να περιγράφονται πριν από την υλοποίηση, όχι όταν παρουσιαστεί το πρώτο παράπονο.

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

Τι χρειάζεται για να λειτουργεί σωστά μετά την πρώτη κυκλοφορία;

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

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

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

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

Σταδιακή παράδοση χωρίς να χτιστεί περισσότερο σύστημα από όσο χρειάζεται

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

1. Ιεραρχήστε τις ροές με βάση την επιχειρησιακή αξία και τον κίνδυνο.
2. Ορίστε ένα πρώτο παραδοτέο που μπορεί να χρησιμοποιηθεί στην πράξη.
3. Ελέγξτε τις βασικές και τις λανθασμένες περιπτώσεις πριν από κάθε κυκλοφορία.
4. Συλλέξτε παρατηρήσεις από πραγματικούς χρήστες και όχι μόνο από την ομάδα ανάπτυξης.
5. Προσθέστε δυνατότητες όταν λύνουν συγκεκριμένο πρόβλημα, όχι επειδή είναι διαθέσιμες.

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

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

Το πρακτικό συμπέρασμα για τη μετάβαση από το πρωτότυπο στην παραγωγή

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