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

Αν έχετε δυστυχισμένους χρήστες, πώς θα το γνωρίζατε;

Όλοι αγαπάμε να κωδικοποιήσουμε.

Όταν σκεφτόμαστε την κωδικοποίηση, συνήθως φτιάχνουμε τον εαυτό μας.

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

Αλλά οι ρομαντικές εικόνες στο κεφάλι μας συχνά δεν μεταφράζονται στην πραγματικότητα.

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

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

Ιστορικά, οι προγραμματιστές λογισμικού έπρεπε να ψάξουν για τη βελόνα στο άχυρα. Έπρεπε να βρουν τις απαντήσεις τους, αντί να βασίζονται σε αυτά τα στιγμιότυπα από χρήστες που δημοσιεύονται σε ένα έγγραφο του Microsoft Word.

Είμαστε όλοι εκεί!

Ποιο πρόγραμμα περιήγησης και έκδοση χρησιμοποιείτε; Τι OS; Μπορείτε να μου πείτε ακριβώς πού κάνατε κλικ; Τι έγινε μετά? Σε ποια σελίδα είχατε πριν; Πώς μπήκατε σε αυτή την οθόνη;

Τόσες πολλές ερωτήσεις, τόσο λίγες (χρήσιμες) απαντήσεις.

Η σάρωση ενός προβλήματος μπορεί να διαρκέσει για πάντα!

Στηριζόμενη στους χρήστες να αναφέρουν προβλήματα

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

Κάτι που είναι τρελός αυτές τις μέρες.

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

Αλλά δεν θα επιστρέψουν ποτέ.

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

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

Το λογισμικό σας δεν είναι τόσο καλό όσο νομίζετε ότι είναι

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

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

Αυτό που βρήκαν ήταν ανησυχητικό.

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

Ένας στους οκτώ περιόδους ελέγχου χρήστη ήταν σπασμένος.

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

Εκτίμησαν ότι είχε επηρεάσει πάνω από 5.000 χρήστες - παρόλα αυτά είχαν λάβει μόνο δύο εισιτήρια υποστήριξης γι 'αυτό.

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

Η αποστολή μηνυμάτων ηλεκτρονικού ταχυδρομείου όταν εμφανίζονται σφάλματα είναι μια χαζή ιδέα

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

Μέχρι να το κάνετε.

Αν το ρυθμίσετε, μπορεί να μοιάζει με αυτό:

δημόσιο κενό TryProcessLineNumber (int lineNumber)
{
    προσπαθήστε
    {
        ProcessLineNumber (lineNumber);
    }}
    αλιεύματα (Εξαιρέσεις ex)
    {
        LetMyselfKnowViaEmail ("Κάτι πήγε στραβά:" + ex.Message);
    }}
}}

Αλλά προσέξτε τα προβλήματα που μπορεί να δημιουργήσει.

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

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

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

Έχετε αφεθεί να τράβετε μέσω χιλιάδων μηνυμάτων ηλεκτρονικού ταχυδρομείου που αναζητούν την ορθή εμφάνιση σφάλματος.

Χρειαζόμαστε κάτι πιο έξυπνο.

ELMAH - καταγραφή των εξαιρέσεών σας

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

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

Elmah καταγραφή των σφαλμάτων

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

Εδώ είναι ένα σπουδαίο φροντιστήριο για το πώς να ξεκινήσετε.

Εξειδικευμένα εργαλεία αναφοράς σφαλμάτων και σφαλμάτων

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

Είναι μερικές γραμμές κώδικα - αυτό είναι όλο που χρειάζεται.

Χρησιμοποιώντας ένα εργαλείο όπως αυτό σας επιτρέπει να:

  • Κόψτε τις θορυβώδεις εξαιρέσεις και επικεντρωθείτε στα πράγματα που έχουν σημασία, όπως οι επιπτώσεις στους χρήστες
  • Ρυθμίστε τις διαμορφώσιμες ειδοποιήσεις μέσω ηλεκτρονικού ταχυδρομείου, Slack ή HipChat
  • Χρησιμοποιήστε ένα εργαλείο για να παρακολουθείτε πολλές γλώσσες και πλατφόρμες
  • Επωφεληθείτε από την ομαδοποίηση σφαλμάτων για παρόμοια σφάλματα
  • Κρατήστε όλη την ομάδα σας πάνω από τα λάθη και την επίλυση τους
Χρησιμοποιήστε ένα ειδικό λογισμικό παρακολούθησης σφαλμάτων όπως το Raygun

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

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

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

Πάρτε μια προορατική προσέγγιση και καρπωθείτε τις ανταμοιβές

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

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

Το μέλλον της παρακολούθησης σφαλμάτων έγκειται στη διασφάλιση ότι όλες οι ομάδες - front end, back end, διαχείριση ή υποστήριξη - έχουν πλήρη προβολή σε κάθε πρόβλημα που συναντούν οι χρήστες τους. Και έπειτα να έχετε τη δυνατότητα να το λύσετε αμέσως.

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

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

Επειδή δεν θα το κάνουν.