มันมีเหตุผลที่จะยืนยันในการทำซ้ำทุกข้อบกพร่องก่อนที่จะวินิจฉัยและแก้ไขหรือไม่

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

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

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

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

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

หรือ:

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

การดีบักสำหรับน้องสาวหรือไม่?

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

สุดท้าย แต่ไม่ท้ายสุดถ้าคุณเห็นด้วยกับฉัน:

ฉันจะพูดคุยกับทีมของฉันเพื่อโน้มน้าวพวกเขาได้อย่างไรว่าแนวทางของฉันนั้นมีความสมเหตุสมผล

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

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

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

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

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

ฉันจะพูดคุยกับทีมของฉันเพื่อโน้มน้าวพวกเขาได้อย่างไรว่าแนวทางของฉันนั้นมีความสมเหตุสมผล

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

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

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

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

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

แต่ ... นั่นอาจไม่เป็นไปได้หรือแม้แต่เป็นไปได้ทางกายภาพ โดยเฉพาะอย่างยิ่งกับซอฟต์แวร์ประเภท 'องค์กร' ที่การติดตั้งแต่ละครั้งไม่ซ้ำใคร นอกจากนี้ยังมีการประเมินค่าใช้จ่าย / ผลประโยชน์ สองสามชั่วโมงในการค้นหารหัสและทำการเดาการศึกษาบางอย่างเกี่ยวกับปัญหาที่ไม่สำคัญอาจมีค่าใช้จ่ายน้อยกว่าการมีทีมสนับสนุนด้านเทคนิคใช้เวลาหลายสัปดาห์ในการตั้งค่าและทำซ้ำสภาพแวดล้อมของลูกค้าโดยหวังว่าจะสามารถทำซ้ำ ปัญหา. ย้อนกลับไปเมื่อฉันทำงานในโลกของ 'Enterprise' เรามักจะปล่อยโคเดอร์ออกและให้พวกเขาแก้ไขบั๊กที่ไซต์เพราะไม่มีทางที่จะทำซ้ำการตั้งค่าของลูกค้า

ดังนั้นให้ทำซ้ำเมื่อคุณทำได้ แต่หากไม่สามารถทำได้ให้ควบคุมความรู้ของระบบและลองระบุผู้ร้ายในรหัส

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

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

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

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

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

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

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

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

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

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

ฉันพูดว่าใช่กับคำเตือนบางอย่าง

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

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

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

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

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

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

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

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

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

ไม่มันไม่ใช่อย่างแน่นอน นั่นจะเป็นนโยบายที่โง่

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

• รายงานข้อผิดพลาด
• ความล้มเหลว ( ข้อผิดพลาด )
• ข้อบกพร่อง (บางครั้งเรียกว่าข้อผิดพลาด )

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

รายงานข้อผิดพลาดเป็นหลักฐานของความล้มเหลว

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

ความล้มเหลวอาจเกิดจากข้อผิดพลาด

ข้อผิดพลาดเป็นสาเหตุของความล้มเหลว; สิ่งที่สามารถเปลี่ยนแปลงได้ (ตามหลักการ) เพื่อป้องกันความล้มเหลวที่เกิดขึ้นในอนาคต

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

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

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

เช่นเดียวกับทุกอย่างในการพัฒนาซอฟต์แวร์คำตอบที่ถูกต้องคือการประนีประนอม

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

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

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

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

เว้นแต่ข้อผิดพลาดจะเห็นได้ชัดชัดเจนและมีข้อผิดพลาดเฉพาะเจาะจง ฯลฯมันมักจะยากที่จะแก้ไขข้อผิดพลาดหากผู้ใช้หรือผู้ดูแลไม่สามารถทำซ้ำได้

นอกจากนี้คุณจะพิสูจน์ได้อย่างไรว่าข้อผิดพลาดได้รับการแก้ไขถ้าคุณไม่สามารถทำซ้ำขั้นตอนได้?

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

ฉันคิดว่าประเด็นของคุณสมเหตุสมผล หากคุณมีพลังจิตคุณอาจจะไม่ได้รับเงินเดือน

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

ปัญหาจะเกิดขึ้นเมื่อเพื่อนร่วมงานบางคนของคุณพบข้อผิดพลาดจากโชคที่บริสุทธิ์และแก้ไขมัน

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

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

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

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

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

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

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

อ่านคำถามฉันไม่เห็นความขัดแย้งพื้นฐานระหว่างตำแหน่งของคุณและทีมของคุณ

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

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

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

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

สรุปฉันจะลองทั้งสองวิธีพร้อมกันและขอให้ทั้งระบบถ่ายทอดสดแสดงปัญหา (และแสดงให้เห็นว่ามันได้รับการแก้ไขในภายหลัง) หรือการทดสอบหน่วยทำลายบางส่วนที่ทำลายปัญหา (และแสดงให้เห็นว่าได้รับการแก้ไขหลังจากแก้ไข)

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

ฟังดูเหมือนว่าคุณต้องการการบันทึกที่ละเอียดมากขึ้น

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

โดยเฉพาะอย่างยิ่งในสถานการณ์ที่ซับซ้อน / มีเธรดหรือสิ่งใดก็ตามที่คุณไม่สามารถใช้ดีบักเกอร์ได้การย้อนกลับไปที่ "debug by printf ()" อาจเป็นเพียงการขอความช่วยเหลือจากคุณ ในกรณีนี้ให้ล็อกเท่าที่คุณจะทำได้ (มากกว่าที่คุณต้องการ) และมีเครื่องมือที่ดีในการกรองข้าวสาลีจากแกลบ

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

เนื่องจากไม่มีใครพูดถึงมันในเงื่อนไขที่ชัดเจนเลย: ไม่อย่างแน่นอน!

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

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

และแน่นอนว่ามีข้อบกพร่องซึ่งหากคุณทำผิดพวกเขาลูกค้าจะเสีย $ 100'000 + และข้อบกพร่องที่ลูกค้าจะสูญเสีย $ 100'000 + ทุก ๆ ชั่วโมงข้อผิดพลาดจะไม่ได้รับการแก้ไข คุณต้องดูที่ข้อผิดพลาดและตัดสินใจ งบแบบครอบคลุมเพื่อจัดการข้อบกพร่องทั้งหมดที่เหมือนกันไม่ทำงาน

คำถามที่ดีมาก! ความคิดเห็นของฉันคือถ้าคุณไม่สามารถสร้างปัญหาขึ้นมาได้คุณจะไม่สามารถ 100% แน่นอนว่าการแก้ไขที่คุณทำจะไม่:

ก) แก้ไขปัญหาจริง b) สร้างข้อผิดพลาดอื่น

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

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

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

[ข้อผิดพลาดที่เกี่ยวข้องกับ] การเข้าถึงฐานข้อมูลพร้อมกัน, การใช้งานแบบคลัสเตอร์, มัลติเธรด

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

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

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

ทั้งกิจกรรม (การตรวจสอบรหัสและการทดสอบ) เป็นสิ่งที่จำเป็นไม่เพียงพอ

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

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

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