วิธีการโน้มน้าวใจสมาชิกในทีมถึงการมี“ mandelbug”

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

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

ปัญหาคือผู้พัฒนาปฏิเสธที่จะแก้ไขข้อผิดพลาดเพราะ "เขาไม่เชื่อว่ามีอยู่" น่าเสียดายสำหรับฉันเจ้านายกำลังเข้าข้างเขาและบอกว่าข้อผิดพลาดนี้ไม่สามารถแก้ไขได้เว้นแต่ฉันจะสร้าง "กรณีทดสอบที่เป็นของแข็ง" เพื่อพิสูจน์การมีอยู่ของข้อบกพร่องและทำการทดสอบหน่วยเพื่อยืนยันว่ามันหายไป สิ่งที่เป็นไปไม่ได้โดยทั่วไปเนื่องจากลักษณะของข้อบกพร่อง

คำแนะนำใด ๆ?

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

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

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

ดังนั้นจากความเห็นที่เพิ่มขึ้นหรือลดลงของคุณฉันได้มาทางนี้:

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

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

คนส่วนใหญ่ง่ายต่อการโน้มน้าวใจเมื่องานเสร็จแล้ว นอกจากนี้พวกเขาตอบสนองได้ดีกว่าใน "นี่คือทางออกที่ดีขึ้น" ซึ่งตรงข้ามกับ "รหัสนี้ผิดแก้ไขด้วยวิธีใดวิธีหนึ่ง"

แก้ไข: เมื่อ dev ยังคงปฏิเสธที่จะเพิ่มการเปลี่ยนแปลงตัวเลือกที่ดีที่สุดพยายามที่จะทำให้รหัสที่เป็นปัญหาทำงานในชุดทดสอบที่แยกซึ่งคุณจำลองข้อผิดพลาดของเครือข่าย การทำงานอย่างมีประสิทธิภาพด้วยรหัสดั้งเดิมอธิบายเทคนิคมากมายเกี่ยวกับวิธีจัดการกับปัญหาดังกล่าว ตัวอย่างเช่นคุณสามารถสร้างเวอร์ชันทดสอบของไลบรารีรวมถึงเฉพาะโมดูลและฟังก์ชั่นที่มีปัญหาและสร้าง "สภาพแวดล้อมจำลอง" รอบ ๆ ซึ่งคุณสามารถจำลอง "ข้อยกเว้นเครือข่าย" ภายใต้เงื่อนไขที่ควบคุมได้ นั่นอาจดูเหมือนจะเป็นความพยายามมากเกินไปในตอนแรก แต่เมื่อคุณมีสภาพแวดล้อมเช่นนี้คุณสามารถเพิ่มการทดสอบเพิ่มเติมจำนวนมากได้ (และฉันเดาว่ามันจะสมเหตุสมผลเนื่องจากเมื่อผู้เขียน lib ปฏิเสธที่จะเพิ่มที่ขาดหายไป การจัดการข้อยกเว้นในที่เดียว

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

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

ผู้ให้การสนับสนุนของมารแนะนำเส้นทางอื่น

ผู้พัฒนารายอื่นได้ระบุไว้อย่างชัดเจนว่าไม่มีข้อผิดพลาด

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

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

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

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

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