แนวทางและแนวทางปฏิบัติที่ดีสำหรับการตรวจสอบรหัสที่จำเป็น [ปิด]

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

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

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

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

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

1. ทำให้บทวิจารณ์สั้น ๆ

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

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

2. หลีกเลี่ยงการตรวจสอบโค้ดที่ไม่ดี

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

3. ใช้ตัวตรวจสอบอัตโนมัติก่อนการตรวจสอบ

   ตัวตรวจสอบอัตโนมัติหลีกเลี่ยงการเสียเวลาอันมีค่าซึ่งจะพบได้โดยอัตโนมัติ ตัวอย่างเช่นสำหรับรหัส C #, เรียกใช้ StyleCop, การวัดรหัสและโดยเฉพาะการวิเคราะห์รหัสเป็นโอกาสที่ดีในการค้นหาข้อผิดพลาดบางอย่างก่อนการตรวจสอบ จากนั้นการตรวจสอบโค้ดอาจใช้กับคะแนนที่ทำได้ยากมากสำหรับเครื่องจักร

4. เลือกคนที่ทำรีวิวอย่างระมัดระวัง

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

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

5. ทำรีวิวทั้งแบบเป็นทางการและไม่เป็นทางการ

   การมีรายการตรวจสอบช่วยในการจดจ่อกับข้อบกพร่องที่แม่นยำ รายการตรวจสอบนี้สามารถมีคะแนนเช่น:

   • การฉีด SQL
   • สมมติฐานที่ไม่ถูกต้องเกี่ยวกับภาษาซึ่งอาจนำไปสู่ข้อผิดพลาด
   • สถานการณ์เฉพาะที่สามารถนำไปสู่ข้อผิดพลาดเช่นลำดับความสำคัญของผู้ประกอบการ ตัวอย่างเช่นใน C # var a = b ?? 0 + c ?? 0;อาจดูดีสำหรับบางคนที่ต้องการเพิ่มสองตัวเลขที่ไม่มีค่าด้วยการรวมกันที่ศูนย์ แต่ไม่ใช่
   • การยกเลิกการจัดสรรหน่วยความจำ
   • การโหลดที่ขี้เกียจ (ด้วยความเสี่ยงสองประการ: การโหลดแบบเดียวกันมากกว่าหนึ่งครั้งและไม่โหลดเลย)
   • ล้น
   • โครงสร้างข้อมูล (ที่มีข้อผิดพลาดเช่นรายการอย่างง่ายแทนที่จะเป็นชุดแฮช)
   • การตรวจสอบอินพุตและการตั้งโปรแกรมการป้องกันโดยทั่วไป
   • ความปลอดภัยด้าย
   • เป็นต้น

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

6. ปรับรายการตรวจสอบอย่างต่อเนื่อง

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

เรามีรายการตรวจสอบเกือบจะ:

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

ทำงานได้ค่อนข้างดี

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

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

สิ่งที่สองเป็นไปโดยอัตโนมัติให้มากที่สุด!

• การควบคุมช่องว่างสีขาว
• ซอฟต์แวร์ควบคุมสไตล์
• สร้างอัตโนมัติก่อนที่จะตรวจสอบรหัส
• การทดสอบอัตโนมัติก่อนตรวจสอบโค้ด

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

หลายอย่างขึ้นอยู่กับเทคโนโลยีของคุณ แต่ค้นหาสิ่งที่คุณสามารถตรวจสอบได้โดยอัตโนมัติยิ่งดียิ่งขึ้น

เรายังไม่ชนะการต่อสู้นี้ แต่นั่นคือสิ่งที่เราพบว่ามีประโยชน์