Không có ứng dụng nào tồn tại trong lần tiếp xúc đầu tiên với người dùng thực tế. Khi mọi người bắt đầu sử dụng nó, họ sẽ gặp lỗi.
Vì vậy, khi đang trong quá trình sản xuất, hầu hết các ứng dụng sẽ có cách theo dõi và báo cáo lỗi. Bạn có thể thực hiện đơn giản với exception_notification hoặc sử dụng ứng dụng web như Honeybadger hoặc Raygun.
Nhưng chẳng bao lâu nữa, bạn sẽ thấy lặp đi lặp lại một vài ngoại lệ giống nhau. Có thể một dịch vụ web mà bạn phụ thuộc không hoàn toàn ổn định. Hoặc những người sử dụng trang web của bạn đánh máy email của họ, vì vậy không có thư nào của bạn được chuyển qua. Các trường hợp ngoại lệ nên đặc biệt, họ phải bất ngờ. Nhưng lỗi không mong muốn có thể xảy ra như thế nào nếu bạn nhìn thấy nó ba mươi lần một ngày?
Có nhiều cách tốt hơn để giải quyết những vấn đề này hơn là báo cáo và phớt lờ. Hầu hết các trường hợp ngoại lệ ồn ào rơi vào một vài loại cơ bản. Và đối với mỗi danh mục này, bạn có thể sử dụng các mẫu để giảm nhiễu và đồng thời làm cho người dùng của bạn vui vẻ hơn.
Mạng bị lỗi!
Rất ít ứng dụng hoạt động một mình. Hầu hết giao tiếp với các ứng dụng khác. Nhưng khi API vị trí địa lý của bạn gặp trục trặc hoặc ec2 gặp trục trặc, bạn không muốn bị spam với hàng nghìn trường hợp ngoại lệ mà bạn không thể làm gì được.
Khi bạn xử lý các dịch vụ không đáng tin cậy, hãy thử mẫu Máy ngắt mạch , từ Michael Nygard's Release It:
Ý tưởng cơ bản đằng sau bộ ngắt mạch rất đơn giản. Bạn bọc một lệnh gọi hàm được bảo vệ trong một đối tượng bộ ngắt mạch, đối tượng này sẽ theo dõi các lỗi hỏng hóc. Khi sự cố đạt đến một ngưỡng nhất định, bộ ngắt mạch sẽ hoạt động và tất cả các cuộc gọi tiếp theo đến bộ ngắt mạch đều quay trở lại với một lỗi mà không có cuộc gọi được bảo vệ nào được thực hiện.
Vì vậy, khi một dịch vụ gặp sự cố, bạn sẽ tự động ngừng cố gắng kết nối với dịch vụ đó. Bạn sẽ chỉ tiếp tục mà không có chức năng đó. Bạn thậm chí có thể làm cho nó tự phục hồi, vì vậy ứng dụng của bạn sẽ tự động kiểm tra lại dịch vụ sau một khoảng thời gian nhất định.
Mẫu thiết bị ngắt mạch được thiết kế để ngăn ngừa các lỗi xếp tầng, nhưng bạn cũng có thể sử dụng nó để hạn chế các thông báo ngoại lệ. Với mẫu này, bạn thực sự chỉ cần nhận được thông báo khi nó di chuyển và khi nó không khôi phục được. Nó có thể biến hàng ngàn trường hợp ngoại lệ thành một vài trường hợp. Nếu vẫn còn quá nhiều, bạn có thể yêu cầu bộ ngắt chỉ báo cáo sau khi không thành công một vài lần thử lại liên tiếp. (Hoặc tìm một dịch vụ khác, đáng tin cậy hơn!)
Sử dụng mẫu này sẽ hiệu quả nhưng nó cũng giúp người dùng của bạn trải nghiệm tốt hơn. Thay vì trang lỗi khó, họ sẽ thấy thông báo cho biết rằng tính năng này hiện không hoạt động và họ nên thử lại sau. Đó là thông tin tốt hơn cho họ, được cung cấp vào đúng thời điểm.
Hóa ra gmaaaail.com không phải ý bạn
Một loại ngoại lệ khác mà tôi thấy rất nhiều đến từ dữ liệu người dùng xấu.
Ví dụ:giả sử ai đó đánh máy email của họ khi họ đăng ký. Họ nói, “justinweiss@gmaill.com”, nhưng có nghĩa là “justinweiss@gmail.com”. Địa chỉ đầu tiên về mặt lý thuyết có thể là một địa chỉ email hợp lệ, nhưng tất cả các email bạn gửi đều bị trả lại. Và bạn sẽ nhận được thông báo về những thư bị trả lại đó bởi nhà cung cấp dịch vụ email của bạn.
Những thông báo này chỉ là tiếng ồn.
Thay vào đó, hãy tiếp cận từ hai phía. Ngăn chặn dữ liệu xấu từ trước, đồng thời tắt tính năng này và thông báo cho người dùng nếu nó không thành công sau này.
Đối với email, tôi đã sử dụng đá quý mailcheck-js để kiểm tra chính tả những thứ như “gmail.com” và “yahoo.com” khi người dùng mới đăng ký:
{% img img-responsive /images/posts/email-spellcheck.gif 477 451 Ôi, thật tuyệt. %}
Sau đó, nếu email vẫn bị trả lại sau đó, hãy tắt email cho người dùng đó.
Sau khi tắt tính năng cho ai đó, bạn cũng cần cho họ biết rằng tính năng này đã bị tắt và cách khắc phục. Một biểu ngữ trên đầu trang web thường là một câu trả lời tốt. Đại loại như “Chúng tôi không thể gửi một vài email cuối cùng của bạn, vì vậy chúng tôi đã tắt tính năng gửi email cho bạn. Nhấp vào đây để cập nhật địa chỉ email của bạn và chúng tôi sẽ bật lại chúng ngay. ”
Bạn sẽ nhận được dữ liệu tốt hơn và email của người dùng sẽ không chỉ đi vào khoảng trống. Cách tốt hơn những lỗi bạn vừa bỏ qua.
404s và RoutingErrors
Bạn có thể muốn biết về các liên kết bị hỏng hoặc nội dung trên trang web của mình. Nhưng những thứ đó không thuộc về trình theo dõi ngoại lệ của bạn.
Đối với những lỗi này và "lỗi nửa vời" khác, hãy tập hợp chúng lại và xử lý tất cả chúng cùng một lúc. Bạn không cần phải nhận thông báo về chúng khi chúng xảy ra. Bạn muốn kéo chứ không phải đẩy.
Những thứ như RoutingErrors và 404 có thể được xử lý bằng một thứ gì đó như Công cụ quản trị trang web của Google, sẽ hiển thị cho bạn các trang mà Google biết đang ném 404. Hoặc bạn có thể chạy một cái gì đó như trình kiểm tra liên kết để kiểm tra các liên kết trên trang web của bạn như một phần của quy trình trước khi phát hành.
Các trường hợp ngoại lệ phải có thể hành động
Sẽ hiếm khi nhận được một email ngoại lệ. Quá nhiều nhiễu trong trình theo dõi lỗi của bạn sẽ khiến bạn không thể nhìn thấy và khắc phục các sự cố thực sự ngay lập tức.
Nếu bạn khó chịu hơn là xấu hổ về các trường hợp ngoại lệ mà bạn thấy, thì bạn có vấn đề về tiếng ồn. Sử dụng các mẫu ở đây để giảm thiểu tiếng ồn đó và đồng thời mang đến cho người dùng của bạn trải nghiệm tốt hơn.
Tôi đã nói về một số danh mục ngoại lệ ồn ào mà tôi thường thấy nhất. Nhưng tôi chắc chắn rằng tôi chưa nhìn thấy tất cả. Những ngoại lệ nào làm bạn khó chịu nhất trong ứng dụng của mình? Chúng có phù hợp với bất kỳ danh mục nào trong số này không hay chúng xác định một danh mục mới? Bạn làm cách nào để họ không làm phiền bạn vài trăm lần mỗi ngày?