Πορτρέτο του Ξενοφών Απάκη
Ξενοφών Απάκης
Web designer και developer από το 1997

ανάπτυξη ιστοσελίδων

ανάπτυξη ιστοσελίδων

· Με δύο λόγια

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

Ανάπτυξη ιστοσελίδων: ποια τεχνική προσέγγιση ταιριάζει στο έργο σας

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

Η βασική επιλογή: έτοιμη πλατφόρμα, CMS ή εξατομικευμένη ανάπτυξη

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

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

Κριτήριο 1: πόσο ιδιαίτερη είναι η επιχειρηματική λογική

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

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

Κριτήριο 2: ποιος θα ενημερώνει το περιεχόμενο

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

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

Κριτήριο 3: ενσωματώσεις και εξωτερικές υπηρεσίες

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

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

Κριτήριο 4: ιδιοκτησία κώδικα, δεδομένων και δυνατότητα μεταφοράς

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

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

Κριτήριο 5: συντήρηση και ρυθμός αλλαγών

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

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

Δέντρο απόφασης για την επιλογή προσέγγισης

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

  1. Χρειάζεστε κυρίως στατικό ή απλό περιεχόμενο; Εξετάστε πρώτα μια λιτή έτοιμη λύση.
  2. Θα ενημερώνεται συχνά το περιεχόμενο από μη τεχνικούς χρήστες; Εξετάστε CMS με καθαρό μοντέλο διαχείρισης.
  3. Υπάρχει ιδιαίτερη επιχειρηματική λογική που δεν αποδίδεται φυσικά με έτοιμα στοιχεία; Διερευνήστε εξατομικευμένη ανάπτυξη.
  4. Υπάρχουν πολλές κρίσιμες διασυνδέσεις; Αξιολογήστε αρχιτεκτονική, σφάλματα, ασφάλεια και δυνατότητα ελέγχου πριν επιλέξετε πλατφόρμα.
  5. Η μελλοντική επέκταση είναι βασική απαίτηση; Προτιμήστε λύση με σαφή όρια μεταξύ δεδομένων, παρουσίασης και λειτουργιών.

Πότε δεν αξίζει η εξατομίκευση

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

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

Πότε μια έτοιμη λύση γίνεται περιορισμός

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

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

Η σωστή επιλογή είναι αυτή που μειώνει τη συνολική τριβή

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

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

Πριν αποφασίσετε, κάντε ένα μικρό τεχνικό δοκιμαστικό πρωτότυπο

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

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

Κριτήριο 6: δυνατότητα ελέγχου και διάγνωσης

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