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

Σταματήστε την ατέρμονη συζήτηση

Φωτογραφία από τον John Jackson στο Unsplash

- "Ακούστε, αυτές οι ιδιωτικές μεταβλητές πρέπει να πάνε μετά τις δημόσιες!"
- "Με τιποτα! Οι δημόσιες μεταβλητές πηγαίνουν πρίν ιδιωτικές! "
- "Ας ρωτήσουμε το Deb και την αφήσουμε να αποφασίσει"
- "Περιμένετε, γιατί αυτές οι σταθερές δεν είναι καμηλοειδείς;"

♂ ♀

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

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

Μπορεί να είναι επώδυνη.

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

Γιατί λοιπόν χρειαζόμαστε συμβάσεις;

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

Υπάρχουν περισσότεροι από λίγοι λόγοι, αλλά θα επικεντρωθώ στη σημαντικότερη: αναγνωσιμότητα.

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

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

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

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

"Τα προγράμματα πρέπει να είναι γραμμένα για να διαβάζουν οι άνθρωποι και μόνο παρεμπιπτόντως για να εκτελέσουν μηχανές." - Hal Abelson

Πώς να επιλέξετε την καλύτερη σύμβαση κώδικα

Είτε μόλις ξεκινήσατε την κωδικοποίηση, είτε είστε μέλος μιας ομάδας kickass dev, ή εάν έχετε γίνει μόνο ένας ΚΟΤ, πώς πηγαίνετε για να επιλέξετε τις συμβάσεις κώδικα;

Εδώ είναι ο οδηγός μου για την επιλογή της καλύτερης σύμβασης κώδικα:

  1. Εμπνευστείτε από τις ομάδες dev που θαυμάζετε: Τίποτα δεν χτυπά την εμπειρία και μερικές από τις μεγαλύτερες και πιο έξυπνες εταιρείες δημοσιεύουν τις οδηγίες τους για την κωδικοποίηση. Για παράδειγμα, η Airbnb δημοσίευσε τους οδηγούς javascript και ruby ​​style και η Google δημοσίευσε τους δικούς της οδηγούς για το Java και Python. Είτε σας αρέσουν αυτές οι εταιρείες είτε όχι, εάν συνοψίσετε τα χρόνια εμπειρίας που έχει κάθε ένας από τους προγραμματιστές τους, προσθέτει στο gazillion. Προσπαθήστε να εφαρμόσετε μερικούς από τους οδηγούς στυλ αυτών των εταιρειών στη δική σας ομάδα.
  2. Γνώση από τους συμμαθητές σας: Είμαστε τυχεροί που συμμετέχουμε σε μια τέτοια δυναμική κοινότητα. Στην πραγματικότητα, ένα από τα μεγαλύτερα πλεονεκτήματα της ανάπτυξης σήμερα είναι η κοινότητά μας. Είτε σε Slack, Spectrum, Discord ή σε οποιαδήποτε πλατφόρμα Collab, μπορείτε πάντα να βρείτε ομάδες με γνώση για να δημοσιεύσετε μια ερώτηση σχετικά με τις συμβάσεις κώδικα και να λάβετε απαντήσεις από devs σε όλο τον κόσμο, αμέσως.
  3. Αγνοήστε δείγματα κώδικα. Yup, απλώς τους αγνοήστε. Κάθε λίγο καιρό σκοντάφω τον κώδικα που ήταν αντιγραφόμενος / επικολλημένος από μια απάντηση στο Stackoverflow ή κάτι παρόμοιο. Αυτό που οι άνθρωποι μερικές φορές ξεχνάνε είναι ότι τα δείγματα κώδικα που μόλις αντιγράφηκαν πιθανότατα γράφτηκαν ως απάντηση σε μια τεχνική ερώτηση ή ως εξήγηση για κάποια βιβλιοθήκη. Στις περισσότερες περιπτώσεις, ο συγγραφέας δεν σήμαινε, ούτε είχε χρόνο να αντιμετωπίσει, συμβάσεις κώδικα.

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

Και τώρα για κάποια φιλοσοφία.

Υπάρχουν ακόμη και συμβάσεις «καλύτερο»;

Αυτό εξαρτάται από το τι σημαίνει «καλύτερο». Εάν η Airbnb ή η Google χρησιμοποιούν μια συγκεκριμένη σύμβαση ή εάν 10 διαφορετικοί ΚΟΤ σας έχουν πει τη σύμβασή τους είναι το καλύτερο - αυτό σημαίνει ότι είναι η καλύτερη σύμβαση για εσάς;

Επιπλέον, οι συμβάσεις υπόκεινται σε αλλαγές. Μπορεί κάτι που αλλάζει με την πάροδο του χρόνου να ονομάζεται "καλύτερο";

Όταν ξεκίνησα στο Lemonade ως ο μόνος προγραμματιστής του front-end, δυσκολεύτηκα να διαβάσω τον κώδικα που έγραψε το προηγούμενο dev. Ίσως ήταν η καλύτερη σύμβαση για αυτόν, αλλά δεν ήταν για μένα. Γι 'αυτό και ξαναγράψαμε κάθε κομμάτι του κώδικα στον οποίο εργάστηκα χρησιμοποιώντας τις συμβάσεις μου. Με την πάροδο του χρόνου, περισσότεροι προγραμματιστές εντάχθηκαν στην ομάδα και οι συμβάσεις μας εξελίχθηκαν.

Κάθε dev προέρχεται από ένα διαφορετικό υπόβαθρο, με διαφορετικά πρότυπα και συμβάσεις. Για να επισημοποιήσουμε τις συμβάσεις μας, χρησιμοποιήσαμε τον οδηγό στυλ javascript του Airbnb ως σημείο εκκίνησης. Αναθεωρήσαμε τις συμβάσεις σε αυτόν τον οδηγό και άλλαξαμε ή αφαιρέσαμε εκείνες με τις οποίες δεν συμφωνούσαμε και υιοθέτησα αυτές που μας άρεσαν. Έχουμε ακόμη υιοθετήσει τις συμβάσεις devs που έφεραν από τη δική τους εμπειρία και τις ενσωμάτωσαν στην κύρια μας σύμβαση.

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

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

Σε αντίθεση με αυτό που διδάσκετε στο σχολείο, δεν υπάρχει πάντα μια σωστή απάντηση σε κάθε ερώτηση. Στην περίπτωση αυτή, μπορεί να υπάρχουν πολλά από αυτά.

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

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

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

Ποιες είναι οι καλύτερες συμβάσεις κώδικα; Εύκολο - δικό σου!