κατασκευή διαδικτυακών εφαρμογών

Κατασκευή διαδικτυακών εφαρμογών που λύνουν πραγματικά προβλήματα

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

Πότε χρειάζεται εφαρμογή αντί για απλό ιστότοπο;

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

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

Ανάλυση χρηστών, δεδομένων και ροών

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

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

Αρχιτεκτονική: τι χωρίζουμε και γιατί

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

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

Ασφάλεια πριν από τη δημοσίευση

Ο έλεγχος πρόσβασης πρέπει να εφαρμόζεται σε κάθε πράξη ανάγνωσης και μεταβολής δεδομένων. Η αναγνωρισμένη κοινότητα ασφάλειας OWASP (Open Worldwide Application Security Project, ανοιχτό έργο για την ασφάλεια εφαρμογών) καταγράφει την ανεπαρκή διαχείριση πρόσβασης στις βασικές κατηγορίες κινδύνου διαδικτυακών εφαρμογών. Χρειάζονται επίσης έλεγχος εισόδων, περιορισμός προσπαθειών σύνδεσης, ασφαλής χειρισμός αρχείων και καταγραφή κρίσιμων συμβάντων χωρίς έκθεση προσωπικών πληροφοριών.

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

Προσβασιμότητα και χρήση σε διαφορετικές συσκευές

Η καλή διεπαφή χρήστη δεν εξαντλείται σε όμορφα χρώματα. Οι φόρμες πρέπει να έχουν σαφείς ετικέτες, τα σφάλματα να εξηγούν τη διόρθωση και οι μεγάλες εργασίες να εμφανίζουν πραγματική κατάσταση. Οι Οδηγίες Προσβασιμότητας Περιεχομένου Ιστού WCAG (Web Content Accessibility Guidelines, οδηγίες προσβασιμότητας διαδικτυακού περιεχομένου) περιλαμβάνουν απαίτηση λειτουργίας μέσω πληκτρολογίου. Γι' αυτό ελέγχουμε πλοήγηση χωρίς ποντίκι, ορατή εστίαση, ανάγνωση μηνυμάτων και λογική σειρά πεδίων.

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

Πώς κρίνεται ένα σχέδιο υλοποίησης;

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

Παραδοτέα και έλεγχοι που αξίζει να ζητήσετε

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

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

Πώς σχεδιάζεται η εξέλιξη χωρίς να χαθούν δεδομένα;

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

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

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

Πότε θεωρούμε ότι η εφαρμογή απέδωσε;

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

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