Ανάπτυξη ιστού Τα 10 αντιδιατάγματα κωδικοποίησης που πρέπει να αποφύγετε

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

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

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

Τι είναι τα Αντίπανα?

Ο όρος “αντίθετη” επινοήθηκε σε ένα βιβλίο που ονομάζεται AntiPatterns το 1998. Αναφέρεται επαναχρησιμοποιούμενες λύσεις που αρχικά φαίνονται χρήσιμες, αλλά αργότερα αποδεικνύεται να κάνει περισσότερο κακό παρά καλό.

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

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

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

1. Πρόωρη βελτιστοποίηση

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

Σύμφωνα με το διάσημο απόσπασμα του Donald Knuth “η πρόωρη βελτιστοποίηση είναι η ρίζα όλων των κακών“, που μπορεί να είναι υπερβολή, αλλά δείχνει πόσο σοβαρά προβλήματα μπορεί να προκαλέσει η πρόωρη βελτιστοποίηση.

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

Για να αποφευχθεί η πρόωρη βελτιστοποίηση, είναι καλή ιδέα να ακολουθήσετε την αρχή προγραμματισμού YAGNI (You Do not Need It), η οποία συμβουλεύει “πάντα να εφαρμόζετε τα πράγματα όταν τα χρειάζεστε πραγματικά, ποτέ όταν προβλέπετε ότι τα χρειάζεστε.”

2. Επανεμφάνιση του τροχού

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

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

3. Κόλαση εξάρτησης

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

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

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

4. Κώδικας σπαγγέτι

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

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

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

5. Προγραμματισμός από το Permutation

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

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

6. Αντιγραφή και επικόλληση προγραμματισμού

“Αντιγράψτε και επικολλήστε τον προγραμματισμό” όταν δεν ακολουθούμε την αρχή κωδικοποίησης Do not Repeat Yourself (DRY) και αντί να δημιουργούμε γενικές λύσεις, εισάγουμε ήδη υπάρχοντα αποσπάσματα κώδικα σε διαφορετικά μέρη και αργότερα τα επεξεργαστούμε ώστε να ταιριάζουν στο δεδομένο πλαίσιο.

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

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

7. Προγραμματισμός φορτοεκλεκτικής

Το όνομα του “προγραμματισμός φορτίου-λατρείας” προέρχεται από ένα συγκεκριμένο εθνογραφικό φαινόμενο που ονομάζεται “θρησκεία φορτίου”. Οι λατρείες φορτίου εμφανίστηκαν στον Νότιο Ειρηνικό μετά τον Δεύτερο Παγκόσμιο Πόλεμο, όταν η αναγκαστική επαφή με προηγμένους πολιτισμούς οδήγησε τους ντόπιους να πιστεύουν ότι τα κατασκευασμένα προϊόντα, όπως η Coca-Cola, οι τηλεοράσεις και τα ψυγεία που έφεραν φορτηγά πλοία στα νησιά, δημιουργήθηκαν από υπερφυσικά μεθόδων · και αν εκτελούν μαγικές τελετές παρόμοιες με τα έθιμα των Δυτικών, το φορτίο που γεμίζει με αγαθά θα έρθει και πάλι.

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

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

8. Λάβα Ροή

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

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

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

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

9. Σκληρός Κωδικοποίηση

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

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

10. Μαλακός κωδικοποίηση

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

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

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