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

ขึ้นอยู่กับความคิดเห็นและ upvotes ที่ตามมาจากBug เปิดใหม่กับใหม่ :

การอ้างถึง bug IDs ใน patch notes เป็นเพียงแค่ .. ไม่เป็นมิตรมาก - Krelp

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

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

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

มันเป็นอย่างที่กล่าวไว้ในความคิดเห็นที่ยกมา ... ไม่เป็นมิตร

เป็นมิตรกับตัวเอง

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

แก้ไข # 1307

คุณเรียกใช้ระบบติดตามบั๊กโดยหวังว่าจะมีสิ่งที่เป็นประโยชน์ รายงาน Bug # 1307 ว่าแก้ไขแล้ว ในคำอธิบายคุณจะเห็น:

ข้อผิดพลาดเช่นเดียวกับ # 1284

ขอบคุณมันมีประโยชน์มาก ตอนนี้คุณต้องไปที่รายงานข้อผิดพลาด # 1284 เพื่ออ่านว่าเป็นข้อผิดพลาดซ้ำ # 1113 ซึ่งหมายถึงข้อบกพร่อง # 1112, # 1065 และ # 1067

ห้านาทีต่อมาคุณไม่รู้ว่าคุณกำลังค้นหาอะไรในตอนเริ่มต้น

ที่เป็นประโยชน์มากขึ้นการควบคุมเวอร์ชันข้อความบันทึกจะเป็น:

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

ในทำนองเดียวกันในระบบติดตามบั๊กรายงาน # 1307 อาจอธิบายตนเองได้มากขึ้นโดยนึกถึงสิ่งที่รายงานบั๊ก # 1284 เกี่ยวกับและสิ่งใหม่ที่แตกต่างจากเดิม

ไม่เป็นมิตรกับลูกค้า

นี่ไม่ใช่ปัญหาที่เป็นมิตรเท่านั้น

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

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

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

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

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

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

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

การอ้างอิง bug IDs ทำให้ฉันหยุดและคิดและฉัน - ในฐานะผู้ใช้ - ไม่ต้องการคิด มันเป็นปัญหาการใช้งาน

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

PS: ฉันเป็นผู้เขียนความคิดเห็นที่จุดประกายคำถาม

ให้มีรหัสข้อผิดพลาดคือบังคับสำหรับจุดอ้างอิง เหตุผล:

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

3052 ได้รับการแก้ไขแล้วและยังคงใช้งานได้ใน 3077

สะดวกกว่า:

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

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

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