Δυναμικές ιστοσελίδες: τι πρέπει να ορίσετε πριν ξεκινήσει η ανάπτυξη

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

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

Η πρώτη απόφαση: ποιο πρόβλημα λύνει η δυναμική λειτουργία

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

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

Απαιτήσεις δεδομένων: τι αποθηκεύεται, από πού έρχεται και πότε αλλάζει

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

Εξίσου σημαντική είναι η πηγή. Κάποια δεδομένα γράφονται χειροκίνητα, άλλα εισάγονται από αρχείο και άλλα έρχονται από εξωτερικό σύστημα. Αν υπάρχει προγραμματιστική διεπαφή, δηλαδή API (Διεπαφή Προγραμματισμού Εφαρμογών, Application Programming Interface), πρέπει να είναι γνωστό ποια δεδομένα ανταλλάσσονται, πόσο συχνά και τι συμβαίνει όταν η εξωτερική υπηρεσία δεν είναι διαθέσιμη.

Ρόλοι χρηστών και δικαιώματα

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

Για περιεχόμενο που ενημερώνεται συχνά εξετάζουμε αν χρειάζεται CMS (Σύστημα Διαχείρισης Περιεχομένου, Content Management System) ή ειδικό διαχειριστικό περιβάλλον. Το πρώτο είναι κατάλληλο όταν οι ανάγκες ταιριάζουν σε τυπικές ροές δημοσίευσης. Το δεύτερο μπορεί να είναι προτιμότερο όταν η επιχείρηση έχει πολύ συγκεκριμένες διαδικασίες που δεν αποδίδονται καλά σε γενικά μοντέλα.

λίστα ελέγχου λειτουργιών πριν από την εκτίμηση έργου

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

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

Εξαρτήσεις που συχνά αλλάζουν το εύρος

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

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

SEO, προσβασιμότητα και απόδοση είναι μέρος της αρχιτεκτονικής

Το SEO (Βελτιστοποίηση για Μηχανές Αναζήτησης, Search Engine Optimization) σε δυναμική ιστοσελίδα επηρεάζεται από το πώς παράγονται οι διευθύνσεις, οι τίτλοι, οι κανονικές σελίδες και οι εσωτερικοί σύνδεσμοι. Δεν είναι εργασία που προστίθεται στο τέλος. Αν ένα φίλτρο δημιουργεί πολλές παραλλαγές διευθύνσεων σελίδων ή αν κάθε εγγραφή δημοσιεύεται χωρίς σαφή θεματική σχέση, το πρόβλημα είναι αρχιτεκτονικό.

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

Ασφάλεια, αντίγραφα και συντήρηση

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

Πώς κλειδώνει το εύρος πριν γραφτεί κώδικας

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

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

Πρωτότυπο ροής πριν από την πλήρη ανάπτυξη

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

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

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