เวลาที่จัดสรรให้กับการตรวจสอบโค้ด

หากคุณกำลังทำรีวิวรหัส

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

มีการศึกษาเกี่ยวกับประสิทธิภาพหรือไม่?

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

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

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

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

ในส่วนที่เกี่ยวกับการศึกษาซอฟต์แวร์ Smart Bear จะส่งหนังสือเล่มเล็ก ๆ ให้คุณฟรีBest Kept Secrets of Peer Code Reviewให้คุณฟรี มีบทความจำนวนหนึ่งเกี่ยวกับการตรวจสอบโค้ดในด้านต่าง ๆ รวมถึงการศึกษาว่าต้องใช้เวลานานแค่ไหนและมีประสิทธิภาพเพียงใด

ในโครงการของเราการเปลี่ยนแปลงที่สำคัญของระบบจะได้รับการตรวจสอบโดยหัวหน้าทีมหรือร่วมกับผู้พัฒนารายอื่นที่จะเป็น "ผู้บริโภค" หลักของโมดูลใหม่ เราพูดคุยกับ skype และใช้ Rudel ใน Emacs (ปลั๊กอินสำหรับการแก้ไขร่วมกันโดยทั่วไปจะอนุญาตให้ผู้ใช้หลายคนแก้ไขไฟล์เดียวกันแบบสด) หรือ TypeWith.me (Piratepad) หรือหนึ่งในเราแบ่งปันหน้าจอของเขาใน skype

เป็นการยากที่จะหาจำนวนเนื่องจากการเปลี่ยนแปลงทางโลกเช่นมุมมองใหม่หน้า ฯลฯ ไม่ได้รับการตรวจสอบ เราทำการตรวจสอบโมดูลใหม่การปรับปรุงที่สำคัญและการปรับโครงสร้างใหม่ สำหรับการเปลี่ยนแปลงครั้งใหญ่การตรวจสอบโค้ดอาจใช้เวลา 10% ถึง 30% ของเวลา แต่มันก็คุ้มค่า

ฉันสามารถพูดได้ว่าการเขียนโปรแกรมคู่เมื่อโปรแกรมเมอร์ 2 คนทำการแก้ไขไฟล์เดียวกันในเวลาเดียวกันไม่ใช่แค่นั่งอยู่ที่คอมพิวเตอร์เครื่องเดียวกันมันดีกว่าแบบฝึกหัดสำนักงานทั่วไปของการนั่งหลังไหล่

สำหรับสิ่งง่าย ๆ เช่นการตั้งชื่อการประชุมและข้อผิดพลาดขอบเขตเราใช้เครื่องมืออัตโนมัติของเราเองหรือโอเพนซอร์ซ (jslint, pylint, pyflakes, pep8) และเราไม่ จำกัด การคอมมิทและการผลักดัน: เราใช้ Mercurial ซึ่งมีการแยกและรวมได้ง่ายมาก (ฉันต้องพูดง่ายกว่าใน Git) ข้อบกพร่องไม่ใช่เรื่องการตรวจสอบรหัส

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

ไม่มีคำตอบที่ถูกหรือผิดเกี่ยวกับเรื่องนี้ แต่เป็นจำนวนมากก่อนที่ฉันจะแนะนำ - หากการตรวจสอบโค้ดทำโดยสมาชิกในทีมภายนอก [วิธีการแนะนำสูง] มันอาจมีจำนวนประมาณ 30% ถึง 35%ของความพยายามในการพัฒนา แต่ถ้าสิ่งนี้ทำโดยสมาชิกในทีมโครงการภายในซึ่งเป็นส่วนหนึ่งของทีมพัฒนา [ไม่แนะนำ] สิ่งนี้สามารถทำให้เสร็จภายในเวลาประมาณ 20%ของเวลาที่ใช้ในการพัฒนา

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

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

ข้อแม้เดียวคือว่าสิ่งนี้สามารถเริ่มกลายเป็นระบบราชการและขึ้นอยู่กับวัฒนธรรมองค์กร