Εκτός Συνόρων, Εκτός Συστήματος: Η Τραγωδία του να Είσαι Φοιτητής Εξωτερικού στο Ελληνικό Web

Έκλεισα αισίως το πρώτο μου έτος στο Ελληνικό Ανοικτό Πανεπιστήμιο (ΕΑΠ), έχοντας επιβιώσει από pointers της ANSI C γραμμένους σε κόλλες αναφοράς και fast-paced ανακρίσεις στην Python. Με το pass στην τσέπη και ένα χαμόγελο γεμάτο ακαδημαϊκή αισιοδοξία, είπα σήμερα να μπω στην πλατφόρμα να δηλώσω τα μαθήματα του δεύτερου έτους. Όλα κυλούσαν όμορφα, μέχρι που ήρθε η ώρα να συμπληρώσω τα προσωπικά μου στοιχεία.

Εκεί, το σύστημα αποφάσισε να μου υπενθυμίσει τη σκληρή πραγματικότητα: στο ελληνικό πανεπιστημιακό web portal, αν ζεις εκτός συνόρων, απλά δεν υπάρχεις. Αντί η πλατφόρμα να λειτουργεί ως αρωγός για τον φοιτητή, διευκολύνοντας τις διαδικασίες, μετατρέπεται σε έναν ψηφιακό λαβύρινθο που σε αναγκάζει να σκαρφιστείς πατέντες για να παρακάμψεις τα δικά του εμπόδια. Είναι από εκείνες τις υλοποιήσεις που λειτουργούν ως το απόλυτο αρνητικό παράδειγμα (anti-pattern): σε κάνουν να σκέφτεσαι «τι να ΜΗΝ κάνεις ποτέ στη δική σου δουλειά ως μελλοντικός developer».

Αναρωτιέμαι ειλικρινά: αν ο developer αυτού του συστήματος παρέδιδε αυτό το ψηφιακό ανέκδοτο ως εργασία εξαμήνου στο ΕΑΠ, τι βαθμό θα έπαιρνε; Μάλλον θα τον έστελναν πακέτο για επανεγγραφή στο επόμενο έτος με ένα μεγαλοπρεπές 0/10 και παρατήρηση για «παντελή έλλειψη αλγοριθμικής σκέψης». Είναι τουλάχιστον ειρωνικό: εμάς, για 6 ECTS, μας περνάνε από κόσκινο ζητώντας enterprise-grade, modular και testable αρχιτεκτονικές. Αλλά στο επίσημο portal του ιδρύματος, οι «επαγγελματίες» που πληρώνονται κανονικά, πατάνε deploy σε κώδικα που μοιάζει γραμμένος από Llama-3.2-1B με 2-bit quantization (και χωρίς system prompt), αγνοώντας βασικούς κανόνες του web development και παραβιάζοντας ευρωπαϊκές οδηγίες.

Κεφάλαιο 1: Η Τέχνη του if (iban.length != 27) return false;

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

Για όσους δεν το γνωρίζουν, από το 2012 και την εφαρμογή του SEPA (Single Euro Payments Area) με τον ευρωπαϊκό νόμο 260/2012, όλες οι χώρες της Ευρωπαϊκής Ένωσης είναι υποχρεωμένες να δέχονται IBAN από οποιοδήποτε κράτος-μέλος. Το λεγόμενο IBAN Discrimination (η απόρριψη ξένων IBAN) είναι παράνομο.

Αλλά ο "vibe coder" (ελπίζω να είναι απλά vibe coder και όχι φτυχιούχος HTML expert) που ανέλαβε να γράψει το validation script, είχε άλλη άποψη:

// Πιθανή αποτύπωση της αρχιτεκτονικής ιδιοφυΐας του συστήματος
function validateIBAN(iban) {
    // Γιατί ποιος στο καλό θα είχε λογαριασμό εκτός Ελλάδας; ¯\_(ツ)_/¯
    if (iban.length !== 27) {
        showValidationError("Το IBAN πρέπει να έχει ακριβώς 27 χαρακτήρες!");
        return false;
    }
    return true;
}

Η Ελλάδα έχει IBAN 27 ψηφίων. Η Γερμανία έχει 22 ψηφία. Το σύστημα του ΕΑΠ, κάνοντας ένα απλό και ξερό length validation, αποφάσισε ότι η Γερμανία δεν πληροί τις προδιαγραφές του.

Ένας σωστός developer που σέβεται το πληκτρολόγιό του, θα χρησιμοποιούσε μια έτοιμη βιβλιοθήκη validation ή έστω έναν δυναμικό έλεγχο που διαβάζει τα δύο πρώτα γράμματα της χώρας (π.χ. DE, GR, FR) και ελέγχει το μήκος με βάση τον πίνακα προτύπων του ISO.

Και το κυριότερο; Θα υλοποιούσε τον πραγματικό αλγόριθμο ελέγχου εγκυρότητας: το Modulo 97.

Για τα «τζιμάνια» του ΕΑΠ που ίσως διαβάζουν αυτό το άρθρο και αναρωτιούνται πώς λειτουργεί ο αλγόριθμος (ISO 13616) —ο οποίος παρεμπιπτόντως διδάσκεται σε εισαγωγικά μαθήματα προγραμματισμού— η διαδικασία είναι εξαιρετικά απλή:

1. Παίρνεις τους 4 πρώτους χαρακτήρες του IBAN (π.χ. GR24 ή DE21) και τους μεταφέρεις στο τέλος του string.
2. Μετατρέπεις τα γράμματα σε αριθμούς (A = 10, B = 11, ..., Z = 35), δημιουργώντας έναν τεράστιο αριθμό.
3. Διαιρείς αυτόν τον αριθμό με το 97. Αν το υπόλοιπο της διαίρεσης (modulo) είναι ακριβώς 1, το IBAN είναι έγκυρο. Αν όχι, έχει γίνει τυπογραφικό λάθος.

Αλλά ο developer του ΕΑΠ προτίμησε να παίξει με τα μήκη των strings. Αυτό σημαίνει ότι αν πληκτρολογήσεις ένα ελληνικό IBAN με 27 χαρακτήρες που περιέχει τυπογραφικά λάθη (π.χ. έγραψες 5 αντί για 6), η πλατφόρμα θα το δεχτεί με ενθουσιασμό! Το validation τους είναι εντελώς «τρύπιο» ακόμα και για τους Έλληνες φοιτητές, απλά και μόνο επειδή βαρέθηκαν να γράψουν 5 γραμμές κώδικα για να ελέγξουν το checksum.

Αντ' αυτού, βρισκόμαστε στο 2026 και το σύστημα του ΕΑΠ επιβάλλει ψηφιακά σύνορα, αναγκάζοντας τους φοιτητές να κάνουν «παρατυπίες» (βλέπε: να δανειστούν IBAΝ φίλων ή συγγενών και μετά να έχουν όλοι πρόβλημα με την εφορία) απλά για να μπορέσουν να προχωρήσουν τη διαδικασία.

Κεφάλαιο 2: Το Γεωγραφικό Matrix (Γερμανία, Νομός... Αττικής;)

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

Σε οποιοδήποτε normal UI, η επιλογή μιας χώρας εκτός Ελλάδας θα έκανε trigger ένα event που είτε θα άλλαζε τα πεδία της διεύθυνσης, είτε θα απενεργοποιούσε τις επιλογές που αφορούν αποκλειστικά την ελληνική επικράτεια. ΧΑ!!! ΛΑΘΟΣ ΜΟΥ ΠΟΥ ΣΚΕΦΤΗΚΑ ΚΑΤΙ ΤΟΣΟ ΑΠΛΟ!!! Στο ΕΑΠ, η επιλογή «Νομός» είναι υποχρεωτικό πεδίο (required). Και οι μόνες επιλογές στο dropdown; Αττική, Θεσσαλονίκη, Αχαΐα...

Ρίχνοντας λίγο τεχνικό φαρμάκι: Μάλλον το front-end τους δεν υποστηρίζει events όπως το onchange. Ή ίσως ο κώδικας είναι τόσο spaghetti/ai slop, που αν κάνουν disable το πεδίο του Νομού, θα σκάσει κανένα null pointer exception στο backend και θα πέσει ολόκληρος ο database server.

Στην τελική, είπα "ναι, ναι, μες στην Αττική μένω, μες στην Κηφισιά",μην μας πούνε και ...πτωχούς.

Κεφάλαιο 3: Η Νοσταλγία του Σταθερού Τηλεφώνου

Το κερασάκι στην τούρτα ήρθε στα στοιχεία επικοινωνίας. Το σύστημα απαιτεί υποχρεωτικά σταθερό τηλέφωνο.

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

Επιπλέον, το πεδίο του σταθερού τηλεφώνου δεν δέχεται κωδικό χώρας εκτός Ελλάδος (+30) αλλά και κωδικό περιοχής της Ελλάδας. Μπορεί να μην έχω σταθερό, αλλα να είμαι Γερμανός πολίτης, ωστόσο μ ένα αλλοδαπό σταθερό τηλέφωνο (+49...) το validation χτυπάει κόκκινο.

Πιθανόν το validation module να γράφτηκε την εποχή του dial-up modem, όταν το ίντερνετ χρεωνόταν με το λεπτό και το σταθερό τηλέφωνο ήταν το block interface της οικογένειας. Περιμένω στο επόμενο βήμα να μου ζητήσουν αριθμό Telex, Fax ή διεύθυνση τηλέγραφου για να μου στείλουν τα αποτελέσματα των ενοτήτων.

Η ειρωνεία είναι διάχυτη και αγγίζει τα όρια του παραλόγου. Από εμάς τους φοιτητές απαιτείται απόλυτη ακαδημαϊκή συνέπεια. Πρέπει να κατανοούμε σε βάθος τη σημασία του σωστού error handling, του edge-case validation, της ασφάλειας των δεδομένων και της συμμόρφωσης με τα διεθνή πρότυπα. Αν παραδώσουμε κώδικα με ένα και μόνο unhandled exception ή αν ξεχάσουμε να κάνουμε validation σε μια είσοδο χρήστη, ο καθηγητής (ο δικός μας «Πλάτωνας») θα μας κόψει με συνοπτικές διαδικασίες στην παρουσίαση, στέλνοντάς μας για επανεξέταση το επόμενο έτος με την επισήμανση ότι «δεν είμαστε έτοιμοι για production».

Όμως, όταν το ίδιο το ίδρυμα βγαίνει στο production, οι κανόνες αυτοί εξαφανίζονται ως δια μαγείας. Η προχειρότητα στον κώδικα βαφτίζεται «σύστημα», οι ευρωπαϊκοί κανονισμοί (SEPA) αγνοούνται επιδεικτικά, και ο χρήστης/φοιτητής αναγκάζεται να μπει σε ρόλο «αλχημιστή» για να παρακάμψει τα bugs.

Και εδώ δεν μιλάμε απλώς για ένα κακό UX. Μιλάμε για πραγματικές, υλικές συνέπειες. Όταν αναγκάζεις έναν φοιτητή εξωτερικού να δανειστεί το ελληνικό IBAN ενός φίλου ή συγγενή για να μπορέσει να ολοκληρώσει την εγγραφή του, τον σπρώχνεις σε μια άτυπη παρατυπία που αύριο-μεθαύριο μπορεί να δημιουργήσει θέματα με την εφορία ή τις τράπεζες (πόθεν έσχες, μεταφορές κεφαλαίων κ.λπ.). Όλα αυτά επειδή ένας developer βαρέθηκε να γράψει 5 γραμμές dynamic check.

Αγαπητό ΕΑΠ, οι ακαδημαϊκοί θεσμοί πρέπει να διδάσκουν την τεχνολογία του μέλλοντος, όχι να συντηρούν ψηφιακά μουσεία της δεκαετίας του '90 που ταλαιπωρούν τους φοιτητές τους και παραβιάζουν ευρωπαϊκές οδηγίες.

Αν η συντήρηση του portal είναι τόσο δύσκολη, έχουμε μια πρόταση: Αναθέστε την πλατφόρμα του portal σε εμάς ως project για την ΠΛΗ. Υποσχόμαστε να σας την παραδώσουμε modular, responsive, με dynamic validation, πλήρως συμβατή με τον SEPA, και κυρίως, χωρίς να χρειάζεται να μετακομίσει η Στουτγκάρδη στον Νομό Αττικής για να πάρει κάποιος πτυχίο.

Ώρα για ένα γερό refactor. Γιατί το UX του portal δεν είναι απλώς κακό· είναι εξυβριστικό προς μια κοινότητα που υποτίθεται ότι σπουδάζει και διδάσκεται Computer Science. Και όσο για το IBAN Discrimination; Όταν ο νόμος προβλέπει τσουχτερά πρόστιμα (ακόμα και 500€ για κάθε μεμονωμένη περίπτωση απόρριψης πληρωμής λόγω διαφορετικού format), η ερασιτεχνική αυτή υλοποίηση στο production δεν είναι απλώς ένα αθώο bug. Είναι μια οικονομική και νομική βόμβα έτοιμη να σκάσει.

Refactor τώρα.