Μπαστούνια στον προγραμματισμό — τι είναι, αιτίες και πότε δικαιολογούνται

Τι είναι το “μπαστούνι” στον προγραμματισμό

Μπαστούνι (crutch) — μια λύση λογισμικού που λειτουργεί, αλλά είναι φτιαγμένη “βιαστικά”: κλείνει ένα συγκεκριμένο πρόβλημα, αλλά δεν εξαλείφει την αιτία του, δεν ακολουθεί την αρχιτεκτονική του έργου και μπορεί να χαλάσει με τις μικρότερες αλλαγές στο περιβάλλον. Η μεταφορά είναι ακριβής — όπως ένα πραγματικό μπαστούνι, τέτοιος κώδικας βοηθά στο “περπάτημα”, αλλά δεν θεραπεύει το “πόδι”.

Οι προγραμματιστές “στηρίζουν με μπαστούνια” bugs, ασυμβατότητες εκδόσεων, χαρακτηριστικά πλατφόρμας και επείγουσες απαιτήσεις πελατών. Ένα τυπικό μπαστούνι — μπαστούνι-συνθήκη: αν iOS 15 πρόσθεσε κενό, αν Huawei — κρύψε το κουμπί. Τέτοιοι έλεγχοι πολλαπλασιάζονται και μετατρέπουν τον κώδικα σε “κέικ με στρώσεις” από διακλαδώσεις πλατφόρμας και έκδοσης.

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

Γιατί εμφανίζονται τα μπαστούνια: αιτίες και πλαίσιο

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

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

Προθεσμίες

Η πιο συχνή αιτία. Η κυκλοφορία είναι αύριο, το bug αναπαράγεται μόνο σε ένα συγκεκριμένο μοντέλο, η αρχιτεκτονική διόρθωση διαρκεί δύο εβδομάδες. Το μπαστούνι-συνθήκη διαρκεί μία ώρα και κλείνει το πρόβλημα. Μετά την κυκλοφορία, η ομάδα υπόσχεται να επιστρέψει και να το ξαναγράψει σωστά. “Τίποτα δεν είναι πιο μόνιμο από το προσωρινό” — ακριβώς για τέτοια μπαστούνια.

Ασυμβατότητα εκδόσεων

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

// Μπαστούνι για συμβατότητα με API 29
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.R) {
    useModernApi()
} else {
    useLegacyFallback()
}

Εξωτερικές εξαρτήσεις με bugs

Η βιβλιοθήκη από την οποία εξαρτάται το έργο περιέχει ένα bug, αλλά η ενημέρωσή της μπορεί να διαρκέσει εβδομάδες (χρειάζεται PR, code review, δημοσίευση). Αντί να περιμένει, η ομάδα γράφει ένα wrapper που διορθώνει τη συμπεριφορά της βιβλιοθήκης εν κινήσει. Μετά τη κυκλοφορία της διορθωμένης έκδοσης, το wrapper αφαιρείται. Αν δεν αφαιρεθεί — αυτό είναι ήδη αρχιτεκτονικό πρόβλημα.

Ελλιπής κατανόηση του συστήματος

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

Πότε δικαιολογείται ένα μπαστούνι: πραγματιστική προσέγγιση

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

Κριτήρια δικαιολογημένου μπαστουνιού: κλείνει ένα συγκεκριμένο πρόβλημα, έχει ιδιοκτήτη (ποιος είναι υπεύθυνος για την αφαίρεσή του) και υπάρχει σχέδιο αναδόμησης. Αν τουλάχιστον μία από τις τρεις συνθήκες δεν ικανοποιείται — το μπαστούνι μετατρέπεται σε τεχνικό χρέος. Εργαλεία όπως σχόλια TODO με ticket στον tracker — ο ελάχιστος τρόπος τεκμηρίωσης.

Παράδειγμα δικαιολογημένου μπαστουνιού

Ένα κρίσιμο bug στον κλάδο έκδοσης που πρέπει να κλείσει πριν από την αυριανή ανάπτυξη. Η καθαρή λύση απαιτεί αναδόμηση αρχιτεκτονικής και θα διαρκέσει δύο εβδομάδες. Μπαστούνι — προσθέστε έλεγχο nil και στείλτε το fix ως hotfix. Προϋποθέσεις δικαιολόγησης: δημιουργήθηκε ticket για αναδόμηση στον tracker, ορίστηκε υπεύθυνος, το μπαστούνι επισημάνθηκε με σχόλιο. Σε δύο εβδομάδες η ομάδα επιστρέφει στην εργασία.

// TODO: IT-1234 — αφαιρέστε αυτό το μπαστούνι μετά την αναδόμηση του AuthService
guard let userId = session.user?.id else {
    return Result.failure(.notAuthenticated)
}

Πώς να ξεχωρίσετε το προσωρινό μπαστούνι από το αρχιτεκτονικό πρόβλημα

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

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

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

Σημάδια κρίσης μπαστουνιών

Αν στον κώδικα υπάρχουν πέντε ένθετοι έλεγχοι για την έκδοση OS, τον κατασκευαστή συσκευής και την παρουσία συγκεκριμένης βιβλιοθήκης — αυτό δεν είναι μπαστούνι, είναι αρχιτεκτονικό πρόβλημα. Αν η προσθήκη ενός fix προκαλεί τρεις παλινδρομήσεις σε γειτονικά modules — τα μπαστούνια έπαψαν να είναι τοπικά. Αν το code review απορρίπτεται τακτικά λόγω “ακόμα ενός μπαστουνιού” — ήρθε η ώρα να προγραμματίσετε αναδόμηση.

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

Αναδόμηση μπαστουνιών: στρατηγική και πρακτική

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

Στρατηγική προτεραιοποίησης

Υψηλή προτεραιότητα — μπαστούνια σε συχνά αλλαγμένα modules (business logic, UI γενικής χρήσης) που επιβραδύνουν την ανάπτυξη και προκαλούν παλινδρομήσεις. Μεσαία προτεραιότητα — μπαστούνια σε σπάνια αλλαγμένα modules, αλλά με πιθανή επίδραση στους χρήστες (επεξεργασία πληρωμών, εξουσιοδότηση). Χαμηλή προτεραιότητα — μπαστούνια σε legacy κώδικα που λειτουργεί σταθερά και δεν προγραμματίζεται για τροποποίηση.

Διαδικασία αφαίρεσης βήμα προς βήμα

Βήμα 1: απογραφή — βρείτε όλα τα TODO και FIXME που σχετίζονται με μπαστούνια. Βήμα 2: αξιολόγηση — καθορίστε ποια είναι ακόμα σχετικά. Βήμα 3: προγραμματισμός — ορίστε την αναδόμηση μπαστουνιών σε ένα sprint, ξεκινώντας από υψηλής προτεραιότητας. Βήμα 4: αντικατάσταση — υλοποιήστε την καθαρή λύση, αφαιρέστε το μπαστούνι και το TODO σχόλιό του. Βήμα 5: επαλήθευση — βεβαιωθείτε ότι τα tests περνούν και δεν υπάρχουν παλινδρομήσεις.

# Βρείτε όλα τα TODO-μπαστούνια στο έργο
grep -r "TODO\|FIXME\|HACK\|XXX" --include="*.kt" --include="*.swift" .

Πρόληψη νέων μπαστουνιών

Ο καλύτερος τρόπος να καταπολεμήσετε τα μπαστούνια είναι να μην τα δημιουργείτε χωρίς ανάγκη. Πριν γράψετε ένα μπαστούνι, κάντε τρεις ερωτήσεις στον εαυτό σας: μπορεί να γίνει καθαρή λύση σε λογικό χρόνο; Υπάρχει εναλλακτική που δεν είναι μπαστούνι; Θα έχει η ομάδα χρόνο να επιστρέψει και να το ξαναγράψει; Αν τουλάχιστον σε μία ερώτηση η απάντηση είναι “όχι” — σκεφτείτε ξανά πριν “στηρίξετε” τον κώδικα.