การอ้างอิงถึงข้อบกพร่อง / ปัญหาในการส่งข้อความถือว่าเป็นแนวปฏิบัติที่ดีหรือไม่?


11

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

ฉันเห็นข้อเสียเพียงเล็กน้อยสำหรับการฝึกนี้ หากบางครั้งในอนาคตรหัสแหล่งที่มาจะถูกแยกออกจากซอฟต์แวร์ติดตามบั๊ก (หรือรายงานข้อบกพร่อง / ปัญหาหายไป) หรือเมื่อใครบางคนกำลังค้นหาประวัติของการกระทำ แต่ไม่มีสิทธิ์เข้าถึงตัวติดตามบั๊กของเรา

คำถามของฉันคือถ้ามีการอ้างอิงข้อบกพร่อง / ปัญหาในข้อความกระทำถือว่าเป็นการปฏิบัติที่ดี? มีข้อเสียอื่น ๆ บ้างไหม?

คำตอบ:


10

เราได้นำวิธีปฏิบัตินี้มาใช้และทำงานได้ดีมากสำหรับเรา การผสานอย่างแน่นหนาระหว่างระบบควบคุมเวอร์ชัน (VCS) และระบบอื่น ๆ ที่เราใช้เช่นการรวมอย่างต่อเนื่องตัวติดตามบั๊ก ฯลฯ มีค่าอย่างยิ่ง หากเราเปลี่ยนแปลงอะไรในอนาคตเราจะต้องประเมินผลข้างเคียงอย่างแน่นอนรวมถึงการเชื่อมโยงระหว่าง VCS และระบบติดตามบั๊ก

โดยทั่วไปฉันจะเห็นว่านี่เป็นวิธีปฏิบัติที่ดี สำหรับระบบติดตามบางระบบจะมีตัวเลือกและเครื่องมือเพิ่มเติมให้ใช้ตัวอย่างเช่นคุณสมบัติ bugtraq สำหรับ Subversion (SVN) สิ่งนี้ชี้ให้เห็นว่ามีบางคนที่เห็นคุณค่าในการฝึกนี้


13

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

แก้ไขข้อผิดพลาด # 123: แอปขัดข้องหลังจากเข้าสู่ระบบ

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


เราทำเช่นนั้นจริง ๆ ดังนั้นเราจึงไม่ต้องเปลี่ยนไปใช้ตัวติดตามบั๊กทุกครั้งที่เราค้นหาประวัติของการกระทำ
คริสเตียน

โอเคแล้วฉันจะปล่อยมันตามที่เป็นอยู่ IMO นี่เป็นวิธีที่ดีที่สุดที่คุณจะทำได้!
Christian Specht

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

นี่เป็นวิธีปฏิบัติมาตรฐานที่ฉันเคยทำงานด้วยฉันคิดว่ามันเป็นวิธีที่ถูกต้องที่จะทำ
Carson63000

+1 ทำสิ่งนี้เสมอ! ฉันเพิ่งทำการบำรุงรักษาโครงการที่เต็มไปด้วยอัญมณีเช่น "นี่อาจเป็นสาเหตุของข้อผิดพลาด 5423" เราไม่สามารถเข้าถึงตัวติดตามข้อผิดพลาดได้
Kryptic

2

นี่เป็นวิธีปฏิบัติทั่วไปและฉันพบว่าสะดวกมาก ฉันใช้ TRAC เพื่อให้ฉันสามารถอ่านประวัติรหัสและนำทางไปยังงานที่ผลักการเปลี่ยนแปลงหรืออ่านประวัติงานและนำทางไปยังการเปลี่ยนแปลงรหัส

"หากบางครั้งในอนาคต ... " หากคุณแยกรหัสออกจากตัวติดตามบั๊กประวัติการแก้ไขแบบเก่าอาจไม่น่าสนใจอีกต่อไป


2

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

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.