Από τις αρχές του 2018, κατέχω τη θέση του επικεφαλής/αφεντικού/επικεφαλής προγραμματιστή στην ομάδα - πείτε το όπως θέλετε, αλλά το θέμα είναι ότι είμαι εξ ολοκλήρου υπεύθυνος για ένα από τα modules και για όλους τους προγραμματιστές που εργάζονται πάνω του. Αυτή η θέση μου δίνει μια νέα προοπτική στη διαδικασία ανάπτυξης, καθώς συμμετέχω σε περισσότερα έργα και συμμετέχω πιο ενεργά στη λήψη αποφάσεων. Πρόσφατα, χάρη σε αυτά τα δύο πράγματα, συνειδητοποίησα ξαφνικά πόσο το μέτρο της κατανόησης επηρεάζει τον κώδικα και την εφαρμογή.
Το σημείο που θέλω να επισημάνω είναι ότι η ποιότητα του κώδικα (και του τελικού προϊόντος) σχετίζεται στενά με το πόσο γνωρίζουν τα άτομα που σχεδιάζουν και γράφουν τον κώδικα για το τι κάνουν.
Μπορεί να σκέφτεστε αυτή τη στιγμή, «Ευχαριστώ, Cap. Φυσικά, θα ήταν ωραίο να καταλάβουμε τι γράφεις γενικά. Διαφορετικά, μπορεί κάλλιστα να προσλάβετε μια ομάδα πιθήκων για να χτυπήσουν αυθαίρετα πλήκτρα και να το αφήσετε έτσι.” Και έχεις απόλυτο δίκιο. Ως εκ τούτου, θεωρώ δεδομένο ότι συνειδητοποιείτε ότι είναι απαραίτητο να έχετε μια γενική ιδέα για το τι κάνετε. Αυτό μπορεί να ονομαστεί μηδενικό επίπεδο κατανόησης και δεν θα το αναλύσουμε λεπτομερώς. Θα εξετάσουμε λεπτομερώς τι ακριβώς πρέπει να καταλάβετε και πώς επηρεάζει τις αποφάσεις που παίρνετε καθημερινά. Αν τα ήξερα αυτά τα πράγματα εκ των προτέρων, θα μου είχε γλυτώσει από πολύ χαμένο χρόνο και αμφισβητήσιμο κώδικα.
Παρόλο που δεν θα δείτε ούτε μία γραμμή κώδικα παρακάτω, εξακολουθώ να πιστεύω ότι όλα όσα αναφέρονται εδώ έχουν μεγάλη σημασία για τη σύνταξη υψηλής ποιότητας, εκφραστικό κώδικα.
Πρώτο επίπεδο κατανόησης: Γιατί δεν λειτουργεί;
Οι προγραμματιστές συνήθως φτάνουν σε αυτό το επίπεδο πολύ νωρίς στην καριέρα τους, μερικές φορές ακόμη και χωρίς καμία βοήθεια από άλλους - τουλάχιστον από την εμπειρία μου. Φανταστείτε ότι λάβατε μια αναφορά σφάλματος: κάποια λειτουργία στην εφαρμογή δεν λειτουργεί, πρέπει να διορθωθεί. Πώς θα προχωρήσετε;
Το τυπικό σχήμα μοιάζει με αυτό:
- Βρείτε το κομμάτι κώδικα που προκαλεί το πρόβλημα (το πώς να το κάνετε αυτό είναι ξεχωριστό θέμα, το καλύπτω στο βιβλίο μου σχετικά με τον κώδικα παλαιού τύπου)
- Κάντε αλλαγές σε αυτό το απόσπασμα
- Βεβαιωθείτε ότι το σφάλμα έχει διορθωθεί και ότι δεν έχουν προκύψει σφάλματα παλινδρόμησης
Τώρα ας επικεντρωθούμε στο δεύτερο σημείο - κάνοντας αλλαγές στον κώδικα. Υπάρχουν δύο προσεγγίσεις σε αυτή τη διαδικασία. Το πρώτο είναι να εμβαθύνετε στο τι ακριβώς συμβαίνει στον τρέχοντα κώδικα, να εντοπίσετε το σφάλμα και να το διορθώσετε. Δεύτερον: μετακίνηση κατά αίσθηση - προσθέστε, ας πούμε, +1 σε μια πρόταση υπό όρους ή βρόχο, δείτε εάν η συνάρτηση λειτουργεί στο επιθυμητό σενάριο, μετά δοκιμάστε κάτι άλλο και ούτω καθεξής επ' άπειρον.
Η πρώτη προσέγγιση είναι σωστή. Όπως εξηγεί ο Steve McConnell στο βιβλίο του Code Complete (το οποίο προτείνω ανεπιφύλακτα, παρεμπιπτόντως), κάθε φορά που αλλάζουμε κάτι στον κώδικα, θα πρέπει να μπορούμε να προβλέψουμε με σιγουριά πώς θα επηρεάσει την εφαρμογή. Παραθέτω από μνήμης, αλλά αν μια επιδιόρθωση σφαλμάτων δεν λειτουργεί με τον τρόπο που περιμένατε, θα πρέπει να ανησυχείτε πολύ και θα πρέπει να αμφισβητήσετε ολόκληρο το σχέδιο δράσης σας.
Για να συνοψίσουμε όσα ειπώθηκαν, για να εκτελέσετε μια καλή διόρθωση σφαλμάτων που δεν υποβαθμίζει την ποιότητα του κώδικα, πρέπει να κατανοήσετε τόσο ολόκληρη τη δομή του κώδικα όσο και την πηγή του συγκεκριμένου προβλήματος.
Δεύτερο επίπεδο κατανόησης: Γιατί λειτουργεί;
Αυτό το επίπεδο κατανοείται πολύ λιγότερο διαισθητικά από το προηγούμενο. Εγώ, ενώ ήμουν ακόμη αρχάριος προγραμματιστής, το έμαθα χάρη στο αφεντικό μου και στη συνέχεια εξήγησα επανειλημμένα την ουσία του θέματος στους νεοφερμένους.
Αυτή τη φορά, ας φανταστούμε ότι λάβατε δύο αναφορές σφαλμάτων ταυτόχρονα: η πρώτη αφορά το σενάριο Α, η δεύτερη για το σενάριο Β. Και στα δύο σενάρια, κάτι δεν πάει καλά. Κατά συνέπεια, αντιμετωπίζετε πρώτα το πρώτο σφάλμα. Χρησιμοποιώντας τις αρχές που αναπτύξαμε για την κατανόηση του Επιπέδου XNUMX, σκάβετε βαθιά στον κώδικα που σχετίζεται με το πρόβλημα, καταλαβαίνετε γιατί προκαλεί τη συμπεριφορά της εφαρμογής με τον τρόπο που συμπεριφέρεται στο Σενάριο Α και κάνετε λογικές προσαρμογές που παράγουν το αναμενόμενο αποτέλεσμα. . Όλα πάνε υπέροχα.
Στη συνέχεια προχωράτε στο σενάριο Β. Επαναλαμβάνετε το σενάριο σε μια προσπάθεια να προκαλέσετε ένα λάθος, αλλά — έκπληξη! — τώρα όλα λειτουργούν όπως πρέπει. Για να επιβεβαιώσετε την εικασία σας, αναιρείτε τις αλλαγές που κάνατε ενώ εργάζεστε στο σφάλμα Α και το σφάλμα Β επιστρέφει. Η επιδιόρθωση σφαλμάτων έλυσε και τα δύο προβλήματα. Τυχερός!
Δεν το υπολόγιζες καθόλου. Έχετε βρει έναν τρόπο να διορθώσετε το σφάλμα στο σενάριο Α και δεν έχετε ιδέα γιατί λειτούργησε για το σενάριο Β. Σε αυτό το στάδιο, είναι πολύ δελεαστικό να πιστεύετε ότι και οι δύο εργασίες έχουν ολοκληρωθεί με επιτυχία. Αυτό είναι πολύ λογικό: το θέμα ήταν να εξαλειφθούν τα λάθη, έτσι δεν είναι; Αλλά το έργο δεν έχει τελειώσει ακόμα: πρέπει ακόμα να καταλάβετε γιατί οι ενέργειές σας διόρθωσαν το σφάλμα στο σενάριο Β. Γιατί; Επειδή μπορεί να λειτουργεί με λάθος αρχές και τότε θα χρειαστεί να αναζητήσετε άλλη διέξοδο. Ακολουθούν μερικά παραδείγματα τέτοιων περιπτώσεων:
- Εφόσον η λύση δεν ήταν προσαρμοσμένη στο σφάλμα Β, λαμβάνοντας υπόψη όλους τους παράγοντες, ενδέχεται να έχετε διακόψει εν αγνοία σας τη συνάρτηση C.
- Είναι πιθανό να κρύβεται κάπου και ένα τρίτο σφάλμα, που σχετίζεται με την ίδια λειτουργία, και η επιδιόρθωση σφαλμάτων σας εξαρτάται από αυτό για τη σωστή λειτουργία του συστήματος στο σενάριο Β. Όλα φαίνονται καλά τώρα, αλλά μια μέρα αυτό το τρίτο σφάλμα θα γίνει αντιληπτό και θα διορθωθεί. Στη συνέχεια, στο σενάριο Β το σφάλμα θα εμφανιστεί ξανά, και είναι καλό μόνο εκεί.
Όλα αυτά προσθέτουν χάος στον κώδικα και κάποια μέρα θα πέσουν στο κεφάλι σας - πιθανότατα την πιο ακατάλληλη στιγμή. Θα πρέπει να συγκεντρώσετε τη δύναμη της θέλησής σας για να αναγκάσετε τον εαυτό σας να αφιερώσει χρόνο κατανοώντας γιατί όλα φαίνονται να λειτουργούν, αλλά αξίζει τον κόπο.
Τρίτο επίπεδο κατανόησης: Γιατί λειτουργεί;
Η πρόσφατη ενόρασή μου σχετίζεται ακριβώς με αυτό το επίπεδο, και είναι πιθανότατα αυτό που θα μου είχε δώσει τα περισσότερα πλεονεκτήματα αν είχα καταλήξει σε αυτήν την ιδέα νωρίτερα.
Για να γίνει πιο σαφές, ας δούμε ένα παράδειγμα: η μονάδα σας πρέπει να γίνει συμβατή με τη συνάρτηση X. Δεν είστε ιδιαίτερα εξοικειωμένοι με τη συνάρτηση X, αλλά σας είπαν ότι για να είναι συμβατή με αυτήν πρέπει να χρησιμοποιήσετε το πλαίσιο F. Άλλο Οι ενότητες που ενσωματώνονται με το X λειτουργούν ακριβώς μαζί του.
Ο κώδικάς σας δεν είχε καμία επαφή με το πλαίσιο F από την πρώτη μέρα της ζωής του, επομένως δεν θα είναι τόσο εύκολο να το εφαρμόσετε. Αυτό θα έχει σοβαρές συνέπειες για ορισμένα μέρη της ενότητας. Ωστόσο, ρίχνετε τον εαυτό σας στην ανάπτυξη: ξοδεύετε εβδομάδες γράφοντας κώδικα, δοκιμάζετε, παρουσιάζετε πιλοτικές εκδόσεις, λαμβάνετε σχόλια, διορθώνετε σφάλματα παλινδρόμησης, ανακαλύπτετε απρόβλεπτες επιπλοκές, δεν τηρείτε τις αρχικώς συμφωνημένες προθεσμίες, γράφετε περισσότερο κώδικα, δοκιμάζετε, λαμβάνετε επικοινωνία ανατροφοδότησης, διόρθωση σφαλμάτων παλινδρόμησης - όλα αυτά για την εφαρμογή του πλαισίου F.
Και κάποια στιγμή ξαφνικά συνειδητοποιείτε - ή ίσως ακούσετε από κάποιον - ότι ίσως το πλαίσιο F να μην σας προσφέρει καθόλου συμβατότητα με το χαρακτηριστικό X. Ίσως όλος αυτός ο χρόνος και η προσπάθεια να καταβλήθηκαν εντελώς λάθος σε αυτό.
Κάτι παρόμοιο συνέβη κάποτε ενώ δούλευα σε ένα έργο για το οποίο ήμουν υπεύθυνος. Γιατί συνέβη αυτό; Επειδή είχα ελάχιστη κατανόηση της συνάρτησης X και πώς σχετίζεται με το πλαίσιο F. Τι έπρεπε να είχα κάνει; Ζητήστε από το άτομο που αναθέτει την εργασία ανάπτυξης να εξηγήσει με σαφήνεια πώς η επιδιωκόμενη πορεία δράσης οδηγεί στο επιθυμητό αποτέλεσμα, αντί απλώς να επαναλάβει αυτό που έγινε για άλλες ενότητες ή να υποστηρίξει ότι αυτό πρέπει να κάνει το χαρακτηριστικό X.
Η εμπειρία αυτού του έργου με δίδαξε να αρνούμαι να ξεκινήσω τη διαδικασία ανάπτυξης μέχρι να καταλάβουμε ξεκάθαρα γιατί μας ζητείται να κάνουμε ορισμένα πράγματα. Αρνηθείτε κατηγορηματικά. Όταν λαμβάνετε μια εργασία, η πρώτη παρόρμηση είναι να την αναλάβετε αμέσως για να μην χάσετε χρόνο. Αλλά η πολιτική «πάγωμα του έργου μέχρι να μπούμε σε όλες τις λεπτομέρειες» μπορεί να μειώσει τον χαμένο χρόνο κατά τάξεις μεγέθους.
Ακόμα κι αν προσπαθήσουν να σας πιέσουν, να σας αναγκάσουν να ξεκινήσετε τη δουλειά, αν και δεν καταλαβαίνετε το σκεπτικό γι' αυτό, αντισταθείτε. Αρχικά, υπολογίστε γιατί σας ανατίθεται μια τέτοια εργασία και αποφασίστε εάν αυτός είναι ο σωστός δρόμος για τον στόχο. Έπρεπε να τα μάθω όλα αυτά με τον δύσκολο τρόπο - ελπίζω το παράδειγμά μου να κάνει τη ζωή πιο εύκολη για όσους το διαβάζουν.
Τέταρτο επίπεδο κατανόησης: ???
Υπάρχουν πάντα περισσότερα να μάθουμε στον προγραμματισμό, και πιστεύω ότι έχω ξύσει μόνο την επιφάνεια του θέματος της κατανόησης. Ποια άλλα επίπεδα κατανόησης έχετε ανακαλύψει όλα αυτά τα χρόνια που εργάζεστε με κώδικα; Ποιες αποφάσεις λάβατε που είχαν θετικό αντίκτυπο στην ποιότητα του κώδικα και της εφαρμογής; Ποιες αποφάσεις αποδείχτηκαν λανθασμένες και σας έδωσαν ένα πολύτιμο μάθημα; Μοιραστείτε την εμπειρία σας στα σχόλια.
Πηγή: www.habr.com