เคล็ดลับบางประการในการลดเสียงรบกวนจากข้อยกเว้น

ไม่มีแอปใดรอดจากการติดต่อครั้งแรกกับผู้ใช้จริง เมื่อผู้คนเริ่มใช้งาน พวกเขาจะพบข้อผิดพลาด

ดังนั้น เมื่ออยู่ในขั้นตอนการผลิต แอพส่วนใหญ่จะมีวิธีการติดตามและรายงานข้อผิดพลาด คุณสามารถทำได้ง่ายๆ ด้วย exception_notification หรือใช้เว็บแอป เช่น Honeybadger หรือ Raygun

แต่ในไม่ช้า คุณจะเห็นข้อยกเว้นบางประการซ้ำแล้วซ้ำเล่า บางทีบริการบนเว็บที่คุณพึ่งพาอาจไม่เสถียรโดยสิ้นเชิง หรือผู้ที่ใช้ไซต์ของคุณพิมพ์อีเมลผิด ดังนั้นจึงไม่มีข้อความใดส่งผ่าน ข้อยกเว้นควรเป็นข้อยกเว้น ควรไม่คาดคิด แต่จะเกิดข้อผิดพลาดที่คาดไม่ถึงได้ขนาดไหนถ้าคุณเห็นมันสามสิบครั้งต่อวัน

มีวิธีแก้ไขปัญหาเหล่านี้ได้ดีกว่าการรายงานและการเพิกเฉย ข้อยกเว้นที่มีเสียงดังส่วนใหญ่จัดอยู่ในหมวดหมู่พื้นฐานสองสามประเภท และสำหรับแต่ละหมวดหมู่เหล่านี้ คุณสามารถใช้รูปแบบเพื่อลดเสียงรบกวนและทำให้ผู้ใช้ของคุณมีความสุขมากขึ้นไปพร้อม ๆ กัน

เครือข่ายล่ม!

มีแอพไม่กี่ตัวที่ทำงานคนเดียว ส่วนใหญ่สื่อสารกับแอพอื่น แต่เมื่อ API ตำแหน่งทางภูมิศาสตร์ของคุณหยุดทำงานหรือ ec2 มีปัญหา คุณคงไม่อยากถูกสแปมด้วยข้อยกเว้นนับพันที่คุณทำอะไรไม่ได้

เมื่อคุณจัดการกับบริการที่ไม่น่าเชื่อถือ ให้ลองใช้รูปแบบ Circuit Breaker , จากผลงานของ Michael Nygard's Release It:

แนวคิดพื้นฐานเบื้องหลังเซอร์กิตเบรกเกอร์นั้นง่ายมาก คุณห่อการเรียกใช้ฟังก์ชันที่ได้รับการป้องกันในออบเจ็กต์เบรกเกอร์ ซึ่งจะตรวจสอบความล้มเหลว เมื่อความล้มเหลวถึงเกณฑ์ที่กำหนด เบรกเกอร์วงจรจะตัดการทำงาน และการเรียกไปยังเซอร์กิตเบรกเกอร์ทั้งหมดจะกลับมาพร้อมกับข้อผิดพลาด โดยไม่มีการป้องกันการโทรเลย

ดังนั้น เมื่อบริการขัดข้อง คุณจะหยุดพยายามเชื่อมต่อโดยอัตโนมัติ คุณจะไปต่อได้โดยไม่ต้องใช้ฟังก์ชันนั้น คุณยังสามารถรักษาตัวเองได้ ดังนั้นแอปของคุณจะตรวจสอบบริการโดยอัตโนมัติอีกครั้งหลังจากผ่านไประยะหนึ่ง

รูปแบบเซอร์กิตเบรกเกอร์ได้รับการออกแบบมาเพื่อป้องกันความล้มเหลวในการเรียงซ้อน แต่คุณยังสามารถใช้เพื่อจำกัดการแจ้งเตือนข้อยกเว้น ด้วยรูปแบบนี้ คุณจะต้องได้รับการแจ้งเตือนจริงๆ เมื่อมีการเดินทางและเมื่อไม่สามารถกู้คืนได้ สามารถเปลี่ยนข้อยกเว้นนับพันให้เป็นบางส่วนได้ หากยังมากเกินไป คุณสามารถบอกให้เบรกเกอร์รายงานได้ก็ต่อเมื่อล้มเหลวในการลองใหม่สองสามครั้งติดต่อกัน (หรือค้นหาบริการอื่นที่น่าเชื่อถือยิ่งขึ้น!)

การใช้รูปแบบนี้ได้ผล แต่ก็ทำให้ผู้ใช้ได้รับประสบการณ์ที่ดีขึ้นด้วย แทนที่จะเป็นหน้าแสดงข้อผิดพลาด ผู้ใช้จะเห็นข้อความแจ้งว่าฟีเจอร์นี้ใช้งานไม่ได้ในขณะนี้ และควรลองอีกครั้งในภายหลัง เป็นข้อมูลที่ดีกว่าสำหรับพวกเขา จัดส่งในเวลาที่เหมาะสม

กลายเป็นว่า gmaaaail.com ไม่ใช่สิ่งที่คุณหมายถึง

ข้อยกเว้นอีกประเภทหนึ่งที่ฉันเห็นบ่อยมากมาจากข้อมูลผู้ใช้ที่ไม่ดี

ตัวอย่างเช่น สมมติว่ามีคนพิมพ์อีเมลของตนผิดเมื่อลงชื่อสมัครใช้ พวกเขาพูดว่า “[email protected]” แต่หมายถึง “[email protected]” อันแรกในทางทฤษฎีอาจเป็นที่อยู่อีเมลที่ถูกต้อง แต่อีเมลทั้งหมดที่คุณส่งตีกลับ และคุณจะได้รับแจ้งเกี่ยวกับการตีกลับจากผู้ให้บริการอีเมลของคุณ

การแจ้งเตือนเหล่านี้เป็นเพียงเสียงรบกวน

ให้ใช้แนวทางสองด้านแทน ป้องกันข้อมูลที่ไม่ถูกต้องล่วงหน้า และปิดใช้งานคุณลักษณะและแจ้งให้ผู้ใช้ทราบหากล้มเหลวในภายหลัง

สำหรับอีเมล ฉันได้ใช้ mailcheck-js gem เพื่อตรวจการสะกดเช่น “gmail.com” และ “yahoo.com” เมื่อผู้ใช้ใหม่ลงทะเบียน:

{% img img-responsive /images/posts/email-spellcheck.gif 477 451 โอ้ แฟนซี %}

จากนั้น หากอีเมลยังคงตีกลับในภายหลัง ให้ปิดอีเมลถึงผู้ใช้รายนั้น

เมื่อคุณปิดฟีเจอร์สำหรับบางคนแล้ว คุณต้องบอกพวกเขาด้วยว่าฟีเจอร์นี้ถูกปิดใช้งานและวิธีแก้ไข แบนเนอร์ที่ด้านบนของไซต์มักเป็นคำตอบที่ดี บางอย่างเช่น “เราไม่สามารถส่งอีเมลสองสามฉบับล่าสุดของคุณ ดังนั้นเราจึงปิดการส่งอีเมลถึงคุณ คลิกที่นี่เพื่ออัปเดตที่อยู่อีเมลของคุณ แล้วเราจะเปิดใช้งานอีกครั้ง”

คุณจะได้รับข้อมูลที่ดีขึ้น และอีเมลของผู้ใช้จะไม่เพียงแค่เข้าสู่ความว่างเปล่า ดีกว่าข้อผิดพลาดที่คุณเพิ่งละเลย

404s และ RoutingErrors

คุณอาจต้องการทราบเกี่ยวกับลิงก์เสียหรือเนื้อหาในไซต์ของคุณ แต่สิ่งเหล่านั้นไม่อยู่ในตัวติดตามข้อยกเว้นของคุณ

สำหรับสิ่งเหล่านี้และ "ข้อผิดพลาดที่ไม่คาดคิด" อื่นๆ ให้แบทช์และจัดการทั้งหมดในคราวเดียว คุณไม่จำเป็นต้องรับการแจ้งเตือนเมื่อเกิดขึ้น ต้องการดึง ไม่ใช่ผลัก

สิ่งต่าง ๆ เช่น RoutingErrors และ 404 สามารถจัดการกับบางอย่างเช่น Google Webmaster Tools ซึ่งจะแสดงให้คุณเห็นหน้าที่ Google รู้เกี่ยวกับที่กำลังโยน 404s หรือคุณอาจเรียกใช้บางอย่าง เช่น ตัวตรวจสอบลิงก์เพื่อตรวจสอบลิงก์ในเว็บไซต์ของคุณซึ่งเป็นส่วนหนึ่งของกระบวนการก่อนเผยแพร่

ข้อยกเว้นควรดำเนินการได้

ไม่น่าจะได้รับอีเมลยกเว้น เสียงรบกวนมากเกินไปในตัวติดตามข้อผิดพลาดจะทำให้คุณไม่เห็นและแก้ไขปัญหาจริงในทันที

หากคุณรำคาญมากกว่าอายเกี่ยวกับข้อยกเว้นที่คุณเห็น แสดงว่าคุณมีปัญหาเรื่องเสียง ใช้รูปแบบที่นี่เพื่อลดเสียงรบกวนและมอบประสบการณ์ที่ดียิ่งขึ้นให้กับผู้ใช้พร้อมๆ กัน

ฉันได้พูดคุยเกี่ยวกับหมวดหมู่ข้อยกเว้นที่มีเสียงดังบางประเภทที่ฉันพบบ่อยที่สุด แต่ฉันแน่ใจว่าฉันไม่ได้เห็นพวกเขาทั้งหมด ข้อยกเว้นใดที่รบกวนคุณมากที่สุดในแอพของคุณ? เข้ากับหมวดหมู่ใด ๆ เหล่านี้หรือกำหนดหมวดหมู่ใหม่หรือไม่? คุณจะป้องกันไม่ให้พวกเขารบกวนคุณสองสามร้อยครั้งต่อวันได้อย่างไร