Ο προγραμματισμός διέπεται από ορισμένες σημαντικές αρχές που κάθε εμπλεκόμενος θα πρέπει να γνωρίζει. Υπάρχουν όμως και μερικές άλλες αρχές προγραμματισμού που μπορεί να αποδειχθούν ακόμα πιο ευεργετικές από τις πρώτες.
Οι συγκεκριμένες αρχές, προσπαθούν να σας διδάξουν πώς να είστε πιο έξυπνοι με τον κώδικα σας, μερικές είναι περίεργες και άλλες χιουμοριστικές. Όλες όμως είναι εξίσου πρακτικές και σημαντικές…
Η αρχή του Bloat
Η αρχή έχει τόσες παραλλαγές που είναι δύσκολο να διαλέξουμε μια σαν κύρια. Ίσως η πιο «επίσημη» έκδοση είναι ο νόμος του Zawinski, ο οποίος ονομάστηκε έτσι από τον Jamie Zawinski και αναφέρεται στο The Art of UNIX Programming:
“Κάθε πρόγραμμα προσπαθεί να επεκταθεί μέχρι να διαβάζει μηνύματα. Τα προγράμματα που δεν μπορούν να επεκταθούν, αντικαθίστανται από αυτά που μπορούν.”
Μιλάει για την τάση των προγραμμάτων να προσελκύουν όλο και περισσότερα χαρακτηριστικά με την πάροδο του χρόνου και αναπόφευκτα να οδηγούν σε μια πολύ αυξανόμενη πολυπλοκότητα. Ηη συνεχιζόμενη προσθήκη νέων χαρακτηριστικών που δεν έχουν καμία σχέση με τον κύριο σκοπό του προγράμματος, οδηγεί σε ένα “παραφούσκωμα” της εφαρμογής, κάτι που συχνά είναι ανεπιθύμητο.
Αυτό ισχύει και για την απόδοση του λογισμικού:
“Το λογισμικό επεκτείνεται για να καταναλώσει όλους τους διαθέσιμους πόρους.”
Στη δεκαετία του ’90, οι σκληροί δίσκοι οι CPU και το RAM ήταν πολύ περιοριστικά για τους προγραμματιστές, που έπρεπε να πακετάρουν τον κώδικά τους εντός συγκεκριμένων ορίων. Σήμερα που διαθέτουμε μεγαλύτερους δίσκους, ταχύτερους CPU και περισσότερη RAM, εξακολουθούμε να φέρουμε τον κώδικα εντός ορίων. Τα πάντα μεγαλώνουν με την πάροδο του χρόνου.
Η νοοτροπία “Το Χειρότερο είναι καλύτερο”
Η νοοτροπία του Worse Is Better, επινοήθηκε από τον Richard P. Gabriel σε ένα δοκίμιο που έγραψε για την ποιότητα του λογισμικού:
“Λογισμικό που είναι περιορισμένο, αλλά απλό στη χρήση, μπορεί να είναι πιο ελκυστικό για τον χρήστη και την αγορά από το αντίστροφο.”
Με άλλα λόγια, αν το λογισμικό σας στοχεύει να κάνει ένα πράγμα και το κάνει καλά, κρατήστε το έτσι. Κρατήστε το απλό. Όσο πιο πολύ το μεγαλώνετε, τόσο πιο αναξιοποίητο θα γίνει και τόσο πιο ανεπιθύμητο από τους χρήστες.
η αρχή λογισμικού του Peter αναφέρει:
“Ένα υπερβολικά σύνθετο έργο τελικά θα γίνει πολύ περίπλοκο για να γίνει κατανοητό ακόμα και από τους προγραμματιστές του”.
Η αρχή του Eagleson
“Οποιοσδήποτε κώδικας δική σας που δεν έχετε εξετάσει για έξι ή περισσότερους μήνες θα μπορούσε επίσης να έχει γραφτεί από κάποιον άλλο.”
Αυτή η φαινομενικά υποτιμητική αρχή είναι στην πραγματικότητα κάτι που πρέπει να πάρετε πολύ σοβαρά. Αναφέρεται στο γεγονός είναι ότι κανείς δεν είναι τέλειος.
Μπορεί να νομίζετε ότι σήμερα είστε κάποιος μεγαλοφυής προγραμματιστής, αλλά αύριο θα υπάρξει πάντα κάτι περισσότερο που μπορείτε να μάθετε. Αν κοιτάξετε ξανά τον παλιό σας κώδικα, μπορεί να τον εξελίξετε περισσότερο γιατί και εσείς έχετε εξελιχθεί.
Η αρχή της ελάχιστης έκπληξης
“Αν ένα απαραίτητο χαρακτηριστικό επιφέρει μεγάλη έκπληξη, μπορεί να χρειαστεί να το επανασχεδιάσετε.”
Δημοσιεύτηκε πρώτα στο IBM Systems Journal το 1984, αλλά η αρχή αυτή εξακολουθεί να είναι εκπληκτικά σχετική και σήμερα (ίσως περισσότερο από ποτέ).
Ασχολείται ουσιαστικά με τη λεπτή ισορροπία ανάμεσα στην καινοτομία και την εξοικείωση: εάν ένα λογισμικό είναι πολύ διαφορετικό από άλλα του είδους του και δεν συμμορφώνεται με τις προσδοκίες των χρηστών, τότε πιθανότατα δεν θα το υιοθετήσουν.
Είναι καλύτερο να επιδιώκετε βελτιώσεις που είναι αρκετά μεγάλες ώστε να είναι εντυπωσιακές αλλά και αρκετά μικρές ώστε να παραμένουν οικείες.
Η αρχή της Εντομολογίας
“Υπάρχει πάντα ακόμα ένα σφάλμα (bug).”
Συχνά ονομάζεται και νόμος του Lubarsky, αλλά δεν είναι σαφές το ποιος είναι αυτός ο Lubarsky.
Ωστόσο, η αρχή του ισχύει για όλους τους προγραμματιστές: δεν έχει σημασία πόσο καθαρός είναι ο κώδικας που γράφετε, και πόσο πολύ τον δοκιμάζετε: θα υπάρχει πάντα άλλο ένα σφάλμα.
Η αρχή του Kernighan
“Το Debugging είναι διπλά πιο δύσκολο από την εγγραφή του κώδικα. Επομένως, αν γράψετε τον κώδικα όσο πιο έξυπνα μπορείτε, εξ ορισμού δεν θα είστε τόσο έξυπνοι για το debug.”
Ο Brian Kernighan, εργάστηκε με τη γλώσσα προγραμματισμού C, και έγινε διάσημος για αυτόν τον διορατικό νόμο. Η ουσία της συγκεκριμένης αρχής είναι η εξής: γράψτε καλό κώδικα, γράψτε αναγνώσιμο κώδικα, γράψτε απλό κώδικα, γράψτε οτιδήποτε αρκεί να μην είναι έξυπνος κώδικας.
Προσπαθώντας να εκπλήξετε με την πολυπλοκότητα του κώδικά σας, θα φέρει ακριβώς το αντίθετο αποτέλεσμα. Μπορεί ο κώδικας που θα γράψετε να είναι έξυπνος, ίσως πιο έξυπνος και από εσάς τον ίδιο αν ξεπεράσετε τον ευατό σας, όμως ποιος θα κάνει το debug; Όσο πιο δύσκολο είναι να καταλάβετε τον κώδικα, τόσο πιο δύσκολο θα είναι να κάνετε και εντοπισμό των σφαλμάτων στο debug.
Η αρχή του Ενενήντα Ενενήντα
“Το πρώτο 90 τοις εκατό του κώδικα αντιστοιχεί στο πρώτο 90 τοις εκατό του χρόνου ανάπτυξης. Το υπόλοιπο 10% του κώδικα αντιπροσωπεύει το υπόλοιπο 90% του χρόνου ανάπτυξης.”
Αυτή η μπερδεμένη αρχή, ανήκει στον Tom Cargill. Ας δούμε γιατί είναι πολύ βασική.
Ο προγραμματισμός μπορεί να γίνει πολύ απογοητευτικός: δεν έχει σημασία πόσο κοντά νομίζετε ότι είστε στο τέλος ένος project. Είστε πολύ πιο μακριά από τις καλύτερες εκτιμήσεις σας. Όταν νομίζετε ότι έχετε τελειώσει, είστε μόνο στα μισά του δρόμου.
Η αρχή του Parkinson
“Η εργασία επεκτείνεται ώστε να γεμίσει το διαθέσιμο χρόνο για την ολοκλήρωσή της.”
Αυτή η αρχή ανήκει στον Cyril Northcote Parkinson. Είναι μια ευρύτερη αρχή που ισχύει απολύτως για τον προγραμματισμό και συμβαδίζει με την παραπάνω αρχή του ενενήντα ενενήντα: όσο καιρό έχετε για να ολοκληρώσετε ένα project, τόσο ακριβώς καιρός θα χρειαστείτε. Στην ανάπτυξη λογισμικού, το “τελειώνει νωρίς” είναι λίγο πολύ μύθος.
Ο νόμος του Parkinson είναι ο λόγος για τον οποίο οι σύγχρονοι επαγγελματίες προγραμματιστές συχνά συστήνουν ευέλικτες αρχές διαχείρισης projects και εργαλεία διαχείρισης όπως η Asana.
Η αρχή του Brook
“Η προσθήκη ανθρώπινου δυναμικού σε ένα project που άργησε, θα το καθυστερήσει περισσότερο.”
Την επόμενη φορά που θα καθυστερήσετε κάποιο Project, θυμηθείτε ότι η προσθήκη κωδικοποιητών δεν θα το τελειώσει πιο γρήγορα.
Στην πραγματικότητα, ίσως χρειαστεί ακόμα περισσότερο χρόνο για να ολοκληρωθεί. Όχι μόνο θα πρέπει να εξηγήσετε στο νέο προγραμματιστή το τι συμβαίνει, αλλά πιθανότατα μπορεί να έρθει και σε σύγκρουση με τους υπάρχοντες προγραμματιστές.
Γνωρίζετε άλλες περίεργες αρχές προγραμματισμού που δεν αναφέρουμε;
Πολύ ενδοαφέροντες νόμοι, αν και οι περισσότεροι δείχνουν ότι οι προγραμματιστές δεν είναι και οι πιο αισιόδοξοι άνθρωποι (και ένας νόμος λέει ότι σίγουρα δεν ισχύει κάτι τέτοιο)