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

Τερματίστε την ατελείωτη συζήτηση

- "Ακούστε, αυτές οι ιδιωτικές μεταβλητές πρέπει να ακολουθούν τις δημόσιες!"

- "Με τιποτα! Οι δημόσιες μεταβλητές είναι προγενέστερες! "

- «Ας ρωτήσουμε τον Ντεμπ και ας την αποφασίσουμε»

- «Περιμένετε, γιατί δεν είναι αυτές οι σταθερές με καμήλα;»

; ‍♂? ‍♀

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

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

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

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

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

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

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

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

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

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

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

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

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

Είτε μόλις ξεκινήσατε την κωδικοποίηση, είτε είστε μέλος μιας ομάδας kickass dev, ή εάν μόλις γίνετε CTO, πώς θα επιλέξετε την εφαρμογή των συμβάσεων κώδικα;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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