ความรับผิดชอบในการทำซ้ำข้อบกพร่อง

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

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

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

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

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

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

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

ทั้งสองฝ่ายควรใช้ความพยายาม

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

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

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

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

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

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

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

ฉันอยากจะปล่อยให้สุนัขนอนนอนตอนนี้ - คุณได้หยิบยกปัญหาขึ้นมาแล้วและได้รับมอบหมายให้เขา สันนิษฐานว่ามีกระบวนการในการติดตามข้อบกพร่องที่โดดเด่นและไล่ล่าเหล่านี้

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

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

คุณพบข้อผิดพลาดคุณรายงานเรื่องนี้และเขาก็เป็นคนที่ฉุนเฉียว

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

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

บันทึกข้อมูลให้มากที่สุดเท่าที่จะทำได้และติดตามต่อไป

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

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

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

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

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

คุณได้กล่าวว่า 'ฉันได้ยื่นข้อบกพร่องพร้อมคำอธิบายของเงื่อนไขเพื่อทำให้การรั่วไหลนี้เกิดขึ้น'

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

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

หากวิธีนี้ใช้ไม่ได้ผลคุณมีทางเลือกดังนี้:

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