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

Ένα από τα πιο ηλίθια επαγγέλματα είναι οι μάνατζερ που διοικούν προγραμματιστές. Όχι όλοι, αλλά όσοι δεν ήταν οι ίδιοι προγραμματιστές. Αυτοί που πιστεύουν ότι είναι δυνατό να «αυξηθεί» η αποτελεσματικότητα (ή να αυξηθεί η «αποτελεσματικότητα»;) χρησιμοποιώντας μεθόδους από βιβλία. Χωρίς καν να μπω στον κόπο να διαβάσω αυτά τα ίδια βιβλία, το βίντεο είναι τσιγγάνικο.

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

Αυτοί που είναι η πλειοψηφία.

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

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

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

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

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

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

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

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

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

Αποδεικνύεται διπλό χάσιμο χρόνου. Χρειάζεται χρόνος για να βρεθεί μια απάντηση. Χρειάζεται επίσης χρόνος για να διατυπωθεί αυτή η απάντηση - και όχι τόσο λίγος.

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

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

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

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

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

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

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

Τι πρέπει να κάνω? Βλέπω και προτείνω δύο μονοπάτια που μπορούν να συνδυαστούν.

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

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

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

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

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

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

Είναι αλήθεια ότι αυτό θα απαιτήσει να περάσετε προσωπικό χρόνο. Όπως και κάθε άλλη εξέλιξη. Δες το όχι ως κόστος, αλλά ως επένδυση – στον εαυτό σου.

Πηγή: www.habr.com

Προσθέστε ένα σχόλιο