Τι είναι ο κώδικας-σπαγγέτι

Κώδικας-σπαγγέτι (spaghetti code) — μια μεταφορά για την περιγραφή κώδικα του οποίου η δομή θυμίζει ένα πιάτο σπαγγέτι: τα επιμέρους νήματα (λογικά μπλοκ) είναι μπερδεμένα, κολλημένα και αδιαχώριστα μεταξύ τους. Σε τέτοιο κώδικα είναι αδύνατο να ξεχωρίσετε επίπεδα, μονάδες ή στοιχεία — όλα ανακατεύονται σε μια μεγάλη μάζα.

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

Σύμφωνα με το IEEE (2022), περίπου το 35% όλων των σφαλμάτων σε μεγάλα έργα οφείλεται ακριβώς στη μπερδεμένη δομή του κώδικα, όχι σε λογικά σφάλματα του προγραμματιστή. Ο προγραμματιστής κάνει λάθος όχι επειδή κατάλαβε λάθος την εργασία, αλλά επειδή δεν μπόρεσε να εντοπίσει τη ροή εκτέλεσης στον κώδικα-σπαγγέτι.

Η βασική διαφορά από άλλα anti-pattern

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

Η ιστορία του όρου και η εποχή του goto

Ο όρος «κώδικας-σπαγγέτι» εμφανίστηκε τη δεκαετία του 1970 μαζί με την κριτική του τελεστή goto. Στις πρώιμες γλώσσες προγραμματισμού (BASIC, FORTRAN, COBOL) το goto ήταν ο κύριος τρόπος ελέγχου της ροής εκτέλεσης. Το πρόγραμμα ήταν μια ακολουθία αριθμημένων γραμμών και το goto επέτρεπε τη μετάβαση σε οποιαδήποτε από αυτές. Αυτό δημιουργούσε ένα «κουβάρι» από μεταβάσεις που ήταν αδύνατο να ξεμπλέξει.

Το 1968 ο Edsger Dijkstra δημοσίευσε το διάσημο γράμμα «Go To Statement Considered Harmful», το οποίο σηματοδότησε την αρχή της εποχής του δομημένου προγραμματισμού. Ο Dijkstra απέδειξε ότι κάθε αλγόριθμος μπορεί να υλοποιηθεί χωρίς goto, χρησιμοποιώντας μόνο τρεις κατασκευές: ακολουθία, διακλάδωση (if) και βρόχο (while). Αυτό έγινε το θεμέλιο του σύγχρονου προγραμματισμού.

Ο δομημένος προγραμματισμός δεν εξάλειψε εντελώς το πρόβλημα. Ο κώδικας-σπαγγέτι πέρασε σε νέο επίπεδο — αντί για φυσικά goto, οι προγραμματιστές άρχισαν να δημιουργούν λογικά «goto»: καθολικές μεταβλητές, callback hell στη JavaScript, πολύπλοκες αλυσίδες κλήσεων και έμμεσες εξαρτήσεις μεταξύ στοιχείων. Το πρόβλημα παρέμεινε, άλλαξε μόνο η μορφή.

Σύγχρονες μορφές goto

Το callback hell στη JavaScript, τα βαθιά ένθετα Promise, το async/await χωρίς διαχείριση σφαλμάτων, τα γεγονότα που δεν είναι σαφές ποιος και πότε τα ενεργοποιεί — όλα αυτά είναι σύγχρονες παραλλαγές κώδικα-σπαγγέτι. Το anti-pattern ζει και ανθεί, απλώς πλέον δεν χρησιμοποιεί τον τελεστή goto.

Σημάδια κώδικα-σπαγγέτι στο έργο

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

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

Οι κλάσεις-θεοί (god-classes) και οι συναρτήσεις-θεοί — το τρίτο σημάδι. Μια κλάση 2000+ γραμμών που είναι υπεύθυνη και για την επιχειρηματική λογική, και για την εμφάνιση, και για την εργασία με δεδομένα — αυτός είναι τυπικός κώδικας-σπαγγέτι. Το ίδιο ισχύει για μια συνάρτηση που δέχεται 10 παραμέτρους και κάνει 5 διαφορετικά πράγματα.

Διάγνωση μέσω δοκιμών

Αν δεν μπορείτε να γράψετε unit test για μια συνάρτηση χωρίς να δημιουργήσετε 15 mock αντικείμενα — αυτός είναι κώδικας-σπαγγέτι. Αν η δοκιμή μιας μονάδας απαιτεί να σηκώσετε ολόκληρη την υποδομή της εφαρμογής — αυτός είναι κώδικας-σπαγγέτι. Η μη δοκιμασιμότητα είναι αντικειμενικός δείκτης μπερδεμένης αρχιτεκτονικής.

Γιατί εμφανίζονται μακαρόνια στον κώδικα

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

Η εξελικτική ανάπτυξη — η δεύτερη αιτία. Το έργο ξεκινά ως μικρό script, μετά αποκτά λειτουργίες, μετά γίνεται εφαρμογή και έπειτα — monolith. Κατά τη διαδικασία αυτή η αρχιτεκτονική δεν αναθεωρείται. Ό,τι λειτουργούσε για 100 γραμμές κώδικα γίνεται καταστροφή για 100 000 γραμμές.

Η παραβίαση των αρχών SOLID — η τρίτη αιτία. Ιδιαίτερα της αρχής της μοναδικής ευθύνης (S) και της αντιστροφής εξαρτήσεων (D). Όταν μια κλάση είναι υπεύθυνη για όλα, οι εξαρτήσεις είναι άκαμπτες και οι μονάδες είναι άρρηκτα συνδεδεμένες — προκύπτει κώδικας-μακαρόνια.

Ο παράγοντας χρόνος

Οι προθεσμίες και η κουλτούρα hotfix — καταλύτες για τον κώδικα-σπαγγέτι. Όταν «έπρεπε να γίνει ήδη χθες», οι προγραμματιστές εισάγουν κώδικα στο πρώτο σημείο που βρίσκουν, χωρίς να σκέφτονται την αρχιτεκτονική. Δέκα τέτοια hotfix — και η αρχιτεκτονική της εφαρμογής έχει καταστραφεί.

Συνέπειες του κώδικα-σπαγγέτι

Η κύρια συνέπεια — η απώλεια ελέγχου πάνω στη βάση κώδικα. Οι προγραμματιστές σταματούν να κατανοούν πώς λειτουργεί η εφαρμογή στο σύνολό της. Μια αλλαγή σε ένα σημείο σπάει ένα άλλο, φαινομενικά άσχετο. Κάθε patch δημιουργεί δύο νέα bugs. Η ομάδα μπαίνει σε κατάσταση «φόβου για τις αλλαγές».

Η παραγωγικότητα της ομάδας πέφτει εκθετικά. Η έρευνα της Microsoft Research (2023) έδειξε ότι ο χρόνος προσθήκης μιας νέας λειτουργίας στον κώδικα-σπαγγέτι αυξάνεται με τετραγωνικό νόμο σε σχέση με το μέγεθος της βάσης κώδικα. Για καθαρή αρχιτεκτονική αυτή η αύξηση είναι γραμμική. Η διαφορά γίνεται κρίσιμη σε 50 000+ γραμμές κώδικα.

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

Επίδραση στην ομάδα

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

Πώς να ανασχηματίσετε τον κώδικα-σπαγγέτι

Πρώτον — ξεκινήστε με τον διαχωρισμό των επιπέδων. Χωρίστε τον κώδικα σε τρία επίπεδα: presentation (UI, controllers), business logic (υπηρεσίες, use cases) και data access (repositories, DAO). Ακόμη και ο μερικός διαχωρισμός βελτιώνει αμέσως τη δομή και κάνει τον κώδικα δοκιμάσιμο.

Δεύτερον — εισαγάγετε dependency injection. Αντικαταστήστε την άμεση δημιουργία εξαρτήσεων με μεταβίβαση μέσω κατασκευαστή ή παραμέτρων. Αυτό σπάει τους άκαμπτους δεσμούς μεταξύ των στοιχείων και επιτρέπει τη δοκιμή κάθε μονάδας μεμονωμένα.

Τρίτον — απομονώστε τις κλάσεις-θεούς και τις συναρτήσεις-θεούς. Χωρίστε τες σε μικρές κλάσεις και μεθόδους με μοναδική ευθύνη. Χρησιμοποιήστε το μοτίβο Facade για την απλοποίηση πολύπλοκων υποσυστημάτων. Θυμηθείτε: μια κλάση 20 γραμμών είναι πιο κατανοητή από μια κλάση 2000 γραμμών.

// σπαγγέτι — όλα σε μία μέθοδο
function handleRequest(req, res) {
  const db = new Database("mysql://...");
  const user = db.query("SELECT * FROM users WHERE id =" + req.params.id);
  let html = "";
  html += "
" + user.name + "
";
  html += "
Balance: " + user.balance + "
";
  html += "";
  res.send(html);
}

// καθαρή αρχιτεκτονική — διαχωρισμένα επίπεδα
class UserController {
  constructor(userService) {
    this.userService = userService;
  }

  async getUser(req, res) {
    const user = await this.userService.findById(req.params.id);
    res.json(new UserResponse(user));
  }
}

class UserService {
  constructor(userRepository) {
    this.userRepository = userRepository;
  }

  async findById(id) {
    return await this.userRepository.findById(id);
  }
}

Στρατηγική ανασχηματισμού: η μέθοδος της χειρουργικής

Μην προσπαθήσετε να ξαναγράψετε ολόκληρη τη βάση κώδικα ταυτόχρονα — αυτή είναι εγγυημένη αποτυχία. Επιλέξτε μία μονάδα, γράψτε για αυτήν δοκιμές (characterization tests) που καταγράφουν την τρέχουσα συμπεριφορά και μόνο τότε ανασχηματίστε. Σταδιακά, μονάδα τη μονάδα, θα ξεμπλέξετε το σπαγγέτι.

Πρόληψη εμφάνισης μακαρονιών

Ο αρχιτεκτονικός σχεδιασμός — η βάση της πρόληψης. Πριν την έναρξη της ανάπτυξης εγκρίνετε το αρχιτεκτονικό στυλ: MVC, MVVM, Clean Architecture, VIPER ή άλλο. Γράψτε ένα ADR (Architecture Decision Record) με την αιτιολόγηση της επιλογής. Απαιτήστε την τήρηση της αρχιτεκτονικής στο code review.

Η αρχή της αντιστροφής εξαρτήσεων (DIP) — ισχυρό εργαλείο για την καταπολέμηση του κώδικα-σπαγγέτι. Τα υψηλού επιπέδου modules δεν πρέπει να εξαρτώνται από τα χαμηλού επιπέδου. Και τα δύο πρέπει να εξαρτώνται από αφαιρέσεις. Το Dependency Injection είναι η πρακτική υλοποίηση αυτής της αρχής.

Η δοκιμή — η καλύτερη πρόληψη. Αν γράφετε δοκιμές πριν από τον κώδικα (TDD), σχεδιάζετε αναπόφευκτα χαλαρά συνδεδεμένα στοιχεία. Ο δοκιμάσιμος κώδικας είναι καλά δομημένος κώδικας. Ο μη δοκιμάσιμος κώδικας είναι σχεδόν πάντα κώδικας-σπαγγέτι.

• Αρχιτεκτονική πριν από τον κώδικα: εγκρίνετε τα σχήματα επιπέδων και εξαρτήσεων
• Dependency Injection ως το κύριο μοτίβο σύνδεσης
• TDD ή τουλάχιστον υψηλή κάλυψη δοκιμών
• Code review με έλεγχο αρχιτεκτονικής, όχι μόνο στυλ
• Τακτικός ανασχηματισμός ως μέρος της διαδικασίας ανάπτυξης

Εργαλεία για την καταπολέμηση του κώδικα-σπαγγέτι

SonarQube — παρακολουθεί την κυκλωματική πολυπλοκότητα, το βάθος κληρονομικότητας, το μέγεθος των μεθόδων. JDepend (Java) — μετρά τις εξαρτήσεις μεταξύ πακέτων. PhpMetrics — δίνει δείκτη συντηρησιμότητας (maintainability) για έργα PHP. Παρακολουθείτε τις μετρικές στο CI/CD — προλάβετε την εμφάνιση μακαρονιών αντί να τα καταπολεμάτε εκ των υστέρων.