ฉันควรบันทึกข้อผิดพลาดที่พบและแก้ไขหรือไม่

ฉันคิดว่านี่เป็นสถานการณ์ทั่วไป: ฉันทดสอบบางรหัสค้นหาข้อผิดพลาดแก้ไขและยอมรับข้อผิดพลาดแก้ไขไปยังที่เก็บ สมมติว่ามีหลายคนที่ทำงานในโครงการนี้ฉันควรสร้างรายงานข้อผิดพลาดก่อนกำหนดให้กับตัวเองและอ้างถึงในข้อความกระทำ (เช่น "แก้ไขข้อผิดพลาด # XYZ ข้อผิดพลาดเกิดจาก X และ Y. แก้ไขโดย Q และ R ")? อีกทางหนึ่งฉันสามารถข้ามรายงานข้อผิดพลาดและส่งข้อความเช่น "แก้ไขข้อผิดพลาดที่ทำให้เกิด A เมื่อ B ข้อผิดพลาดเกิดจาก X และ Y. แก้ไขโดย Q และ R"

การปฏิบัติที่ดีกว่าคืออะไร?

ขึ้นอยู่กับว่าใครเป็นผู้ชมรายงานข้อผิดพลาด

หากนักพัฒนาซอฟต์แวร์มองภายในเท่านั้นที่จะรู้ว่าต้องแก้ไขอะไรแล้วอย่ากังวล มันเป็นเพียงเสียง ณ จุดนั้น

รายการเหตุผลที่ไม่ครบถ้วนในการเข้าสู่ระบบ:

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

ฉันว่ามันขึ้นอยู่กับว่าผลิตภัณฑ์ของคุณเปิดตัวพร้อมข้อบกพร่องหรือไม่

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

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

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

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

ขึ้นอยู่กับหลายปัจจัย

ทั้ง Pieter B และ Caleth เขียนคำตอบไว้บ้าง:

• ข้อผิดพลาดเป็นส่วนหนึ่งของการเปิดตัวอย่างเป็นทางการหรือไม่?
• มีการติดตามจำนวนข้อบกพร่อง / เวลาที่ใช้ไปหรือไม่

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

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

คำถามนี้สามารถตอบได้โดยหัวหน้าโครงการของคุณเท่านั้นหรือใครก็ตามที่รับผิดชอบ "กระบวนการออกตั๋ว"

แต่ให้ฉันถามวิธีอื่น: ทำไมคุณไม่บันทึกข้อผิดพลาดที่คุณได้รับการแก้ไข

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

ในกรณีนี้ปัญหาไม่ใช่ว่าจุดบกพร่องนั้นง่ายต่อการแก้ไข แต่เอกสารใช้เวลานานเกินไป มันไม่ควรจริง ๆ สำหรับผมแล้วค่าใช้จ่ายในการสร้างตั๋ว Jira กดcแล้วป้อนสรุป 1 เส้นสั้น ๆ Enterและกด คำอธิบายไม่ได้เหนือศีรษะเพราะฉันสามารถตัดและวางลงในข้อความยืนยันพร้อมด้วยหมายเลขปัญหา ในตอนท้าย. c <Enter>และปัญหาถูกปิด ที่เดือดลงไปกดปุ่ม 5 ค่าใช้จ่าย

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

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

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

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

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

ใช่แล้ว

มีคำตอบบางอย่างอยู่แล้วซึ่งแสดงสถานการณ์ที่ควรสร้างรายงานบั๊ก บางคำตอบ และพวกเขาแตกต่างกัน

คำตอบเดียวคือไม่มีใครรู้ คนที่แตกต่างกันในแต่ละช่วงเวลาจะมีความคิดเห็นที่แตกต่างกันในเรื่องนี้

ดังนั้นเมื่อพบข้อผิดพลาดคุณมีสองวิธีแก้ไข:

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

การสร้างรายงานนั้นเร็วกว่าและหากไม่ใช่ ... จะทำให้เป็นอัตโนมัติ

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

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

เพียงแค่ถามผู้จัดการของคุณ ผู้จัดการของคุณหรือหัวหน้าโครงการหรือผู้นำการต่อสู้หรืออื่น ๆ ขึ้นอยู่กับโครงสร้างของกลุ่ม

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

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