Code Calligraph VS Code Chicken Scratch

Τα τελευταία 17 χρόνια έχω εργαστεί σε περισσότερα από 90 έργα με πολλές ομάδες. Αλλά μόλις έβρισκα το blameχαρακτηριστικό του Git έμαθα για το "χειρόγραφο" κάθε κωδικοποιητή. Αυτή η απλή περιέργεια σύντομα έγινε συνήθεια. Κάθε φορά που έβλεπα νέο κωδικό, προσπαθούσα να μαντέψω ποιος τον έγραψε. Τότε θα επαληθεύσω την εικασία μου με ένα git blame.

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

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

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

Ομιλίες κώδικα. Κραυγές κακού κώδικα! Λοιπόν, είναι ο κώδικας που διαβάζετε τον κώδικα καλλιγραφίας ή είναι κωδικός μηδέν κοτόπουλου;

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

Insight # 1: Φουσκωμένος κώδικας = αγώνας

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

Στην πραγματική ζωή, οι άνθρωποι που κάνουν λιγότερα, τείνουν να μιλούν περισσότερο. Είναι το ίδιο και στο code land: όσοι δεν μπορούν να κάνουν τη δουλειά τους τείνουν να γράφουν πολύ κώδικα.

Δυστυχώς, τα σφάλματα γιορτάζουν τον κώδικα, και όσο περισσότερες διατάξεις κώδικα, τόσο μεγαλύτερος είναι ο βιότοπος για σφάλματα.

«Μισώ τον κώδικα, και θέλω όσο το δυνατόν λιγότερα στο προϊόν μας» - Jack Diederich

Insight # 2: Dead code = sloppiness

Έχετε δει τεράστια μπλοκ κώδικα σχολιασμένων δεσμευμένων στο repo; Ή ακόμη χειρότερο: κώδικας που δεν κάνει κάτι ιδιαίτερο, αλλά υπάρχει για ιστορικούς λόγους;

Είναι ενδιαφέρον ότι αυτό έχει άμεση σχέση με την ακαταστασία του γραφείου του προγραμματιστή που το έγραψε. Έχετε δει ξεπερασμένα σχόλια ή δοκιμές; Ναι, βρήκες έναν απρόσεκτο προγραμματιστή.

3. Σύνθετος κωδικός = ηλιθιότητα ή απληστία

Μου αρέσει αυτό το απόσπασμα από τον Schumacher:

«Κάθε έξυπνος ανόητος μπορεί να κάνει τα πράγματα μεγαλύτερα, πιο περίπλοκα και πιο βίαια. Χρειάζεται ένα άγγιγμα ιδιοφυΐας - και πολύ κουράγιο να κινηθούμε στην αντίθετη κατεύθυνση. - Fritz Schumacher

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

Insight # 4: Σχόλια = παίκτης της ομάδας (εκτός εάν…)

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

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

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

Insight # 5: Names = ικανότητα επικοινωνίας

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

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

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

Και αν αλλάξει η λειτουργικότητα μιας οντότητας, είναι σημαντικό να αναδιαμορφωθεί το όνομά της ανάλογα.

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

Insight # 6: Κακή αναγνωσιμότητα = έλλειψη ευχέρειας

Μερικές φορές οι προγραμματιστές είναι άπταιστοι σε μια γλώσσα, αλλά προσπαθούν να στρίψουν και να λυγίσουν μια άλλη γλώσσα για να συμπεριφέρονται όπως η αγαπημένη τους γλώσσα.

Το JavaScript είναι μία από αυτές τις κακές γλώσσες στόχους.

Οι περισσότεροι προγραμματιστές back-end έχουν την πολυτέλεια να επιλέξουν τη «μητρική τους γλώσσα». Και πολλοί είναι αρκετά γενναίοι για να χαράξουν μαζί μερικές γραμμές κώδικα front-end. Αλλά επειδή το πρόγραμμα περιήγησης είναι ως επί το πλείστον JavaScript (που είναι μια ευέλικτη γλώσσα), προσπαθούν να μιμηθούν ποια μοτίβα είναι ποτέ γνωστά από τη «μητρική τους γλώσσα».

Όλα αυτά είναι καλά και καλά έως ότου ένας πραγματικός προγραμματιστής JavaScript δει τον κώδικα και βγάλει τα μαλλιά τους έξω!

Insight # 7: Hacks = ρηχή προσωπικότητα ή έλλειψη πειθαρχίας

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

Συγχαρητήρια: γνωρίσατε έναν χάκερ!

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

Λοιπόν, τι είναι το αλίευμα; Διορθώνουν ένα πρόβλημα και δημιουργούν 10 άλλα.

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

Παρ 'όλα αυτά, έχω δει εσωτερικούς προγραμματιστές που κάνουν ακόμη και τους πιο δύσκολους συμβούλους να μοιάζουν με ροκ σταρ. Υπολογίστηκε ποτέ ότι ένα ζήτημα θα διαρκέσει 8 ώρες, αλλά κάποιος διαχειριστής προϊόντων μειώνει την εκτίμησή σας σε μόλις 1 ώρα; Αυτό συμβαίνει συνήθως όταν γεννιούνται οι αμυχές.

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

Insight # 8: Ασυνεπής = υπερηφάνεια και φανατισμός

Όταν στη Ρώμη, κάντε όπως οι Ρωμαίοι. - μια παροιμία

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

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

Το χειρότερο από όλα είναι όταν πιέζουν για τις δικές τους συμβάσεις. Αυτός είναι καθαρός φανατισμός. Και μπορείτε να είστε βέβαιοι ότι ο προγραμματιστής έχει στενή σκέψη και σε άλλα θέματα.

Insight # 9 WET code = κακή μνήμη

Το αντίθετο του Dry ("Μην επαναλαμβάνετε τον εαυτό σας") είναι WET ("Απολαμβάνουμε την πληκτρολόγηση" ή "Γράψτε τα πάντα δύο φορές").

Λοιπόν, τα σφάλματα αναπαράγονται μέσω μιας ακατάστατης διαδικασίας που ονομάζεται «αντιγραφή» και «επικόλληση».

Υπάρχουν εκπληκτικά πολλοί τύποι κώδικα WET. Για παράδειγμα:

  1. Μια συνάρτηση ή τάξη που γράφεται δύο φορές, μόνο με μικρές διαφορές
  2. Μια μεταβλητή που κρατά την τιμή μιας άλλης μεταβλητής
  3. Ένα σύνολο επαναλαμβανόμενων οδηγιών που θα μπορούσαν να βρίσκονται σε μια συνάρτηση

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

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

Πληροφορίες # 10. Προσωρινές λύσεις = έλλειψη πειθαρχίας

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

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

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

Insight # 11: Πολλές εξαρτήσεις = απροσεξία για το μέλλον του έργου

Οι εξαρτήσεις πρέπει να ενημερώνονται. Όταν ένα έργο έχει πάρα πολλές εξαρτήσεις, είναι ένα σημάδι αδράνειας.

Είναι δύσκολο να πούμε τι είναι «πάρα πολύ», αλλά ο κανόνας είναι: εάν το έργο μπορεί εύκολα να επιβιώσει χωρίς εξάρτηση, είναι περιττό.

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

Υπάρχουν τρία κίνητρα για περιττές εξαρτήσεις:

Λόγος # 1: Ο προγραμματιστής είναι πολύ πρόθυμος να μάθει νέα πράγματα.

Με την εισαγωγή νέων εξαρτήσεων, έχουν την ευκαιρία να κάνουν αυτή τη μάθηση σε ένα πραγματικό έργο.

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

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

Λόγος # 2: Αυτό γίνεται από έναν υπερβολικά φιλόδοξο junior προγραμματιστή.

Οι νεοεισερχόμενοι σε οποιονδήποτε τομέα τείνουν να κατακλύζονται από όλους τους νέους λέξεις-κλειδιά, και από απογοήτευση ή άγνοια (ή τη σύσταση ενός «επαγγελματία») μπορεί να αποφασίσουν να «πηδήξουν στην πισίνα» και να μάθουν τα πάντα ταυτόχρονα. Μην τους αφήσετε. Διαλέξτε την τεχνολογία σας.

Λόγος # 3: Ο προγραμματιστής έχει αποσκευές από άλλη εργασία (ή ένα δευτερεύον έργο)

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

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

Μερικές φορές ο εν λόγω κωδικοποιητής κάουμποϋ μπορεί να κάνει μια μαζική αναδιαμόρφωση και, στη συνέχεια, να θέσει την ομάδα σε θέση να αποδεχτεί ολόκληρη την αλλαγή επειδή έχει ήδη γίνει. Λοιπόν, μην! Ζητήστε τους να σπάσουν το αίτημα έλξης σε μικρότερα μέρη και να είναι δύσπιστοι σχετικά με τη δημιουργία νέων εξαρτήσεων. Ναι, είναι περισσότερη δουλειά, αλλά θα εξοικονομήσει πολύ περισσότερο χρόνο και ενέργεια μακροπρόθεσμα.

Οι καλοί προγραμματιστές ενδιαφέρονται για το μέλλον του έργου τους επειδή ξόδεψαν τον πιο πεπερασμένο και πολύτιμο πόρο τους για να το δημιουργήσουν: ο χρόνος τους!

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

Κωδικός καλλιγραφία

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

Μερικοί λένε ακόμη και «ο κώδικας είναι ποίηση».

Ο πηγαίος κώδικας για το jQuery ή το lodash είναι εξαιρετικά παραδείγματα, αλλά σχεδόν όλες οι δημοφιλείς βιβλιοθήκες στο Github που πολλοί συνεισφέροντες τελικά θα συγκλίνουν στην ομορφιά. Αυτή, οι φίλοι μου, είναι υπέροχη καλλιγραφία κώδικα .

Ουσιαστικά, ο εξαιρετικός κώδικας είναι:

  1. Εύκολη ανάγνωση, παρακολούθηση και εντοπισμός σφαλμάτων
  2. Ευέλικτη, διαμορφώσιμη και επεκτάσιμη
  3. Έξυπνο με χρήση πόρων
  4. Υψηλή απόδοση

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

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

⚡ ️ Σας άρεσε αυτό που διαβάσατε; Ακολουθήστε με για να λαμβάνω ειδοποίηση όταν γράφω κάτι νέο.

Επίσης, ίσως θέλετε να δείτε γιατί ο προγραμματισμός είναι η καλύτερη δουλειά ποτέ.