วิธีที่มีประสิทธิภาพที่สุดในการตรวจสอบโค้ดคืออะไร [ปิด]

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

วิธีที่มีประสิทธิภาพที่สุดในการตรวจสอบโค้ดคืออะไร

ตัวอย่างเช่น:

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

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

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

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

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

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

หากทำเป็นกลุ่มที่มีโปรเจ็กเตอร์ควรทำการตรวจสอบเป็นรายบุคคลก่อนการประชุม มิฉะนั้นจะเป็นเพียงการเสียเวลาที่น่ารำคาญ

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

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

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

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

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

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

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

หากคุณกำลังทำงานในโครงการที่หลายคนจะมีส่วนร่วมในฐานรหัสจะต้องมีการสร้างมาตรฐาน

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

ในฐานะที่เป็น dev ตัวเองฉันจะตรวจสอบรหัสของตัวเองหลาย ๆ ครั้งเพื่อให้สามารถอ่านได้มีเหตุผลและทุกอย่างอื่น โดยปกติเราจะใช้ javadoc หรือคล้ายกันในภาษาที่เราให้รหัสด้วยและใช้ @author tag เพื่อแนบความเป็นเจ้าของกับฟังก์ชั่นคลาส ฯลฯ

หากฟังก์ชั่นไม่ถูกต้องเราจะคุยกับเจ้าของเช่นเดียวกับคลาส ฯลฯ

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

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

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

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

ฉันแนะนำให้ใช้บทวิจารณ์โค้ดหากคุณไม่ได้ทำการเขียนโปรแกรมแบบคู่

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

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

YMMV

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

อุตสาหกรรมโครงสร้างพื้นฐานที่สำคัญสนใจในความน่าเชื่อถือและการทำซ้ำเหมือนกัน :-)

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

ระบบนี้ใช้งานได้ดี - การตรวจสอบเสร็จสิ้นเมื่อเวลาผ่านไปและการเปลี่ยนแปลงสามารถตรวจสอบได้ด้วยลูกตาหลายชุด

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

ใน บริษัท ของฉันเราไม่เคยทำการตรวจสอบโค้ดอย่างเป็นทางการก่อนเช็คอินเว้นแต่เราจะทำการปรับเปลี่ยนการผลิตที่สำคัญมากและไม่มีเวลาที่จะดำเนินการตามกระบวนการ QA มาตรฐานของเรา

สิ่งที่เราทำคือทุกครั้งที่เรารู้สึกว่าการตรวจสอบรหัสจะมีประโยชน์เราเพิ่มความคิดเห็น "// todo: code review by joe" ลงในรหัสที่แก้ไขแล้ว โดยปกติเราเลือก Joe เพราะเขาเป็นเจ้าของรหัสที่แก้ไขแล้ว แต่หากเกณฑ์การเลือกนี้ไม่ได้ใช้ (โดยปกติจะเป็นเช่นนั้น) เราแค่เลือกคนอื่นแบบสุ่ม และแน่นอนถ้าโจเกิดขึ้นในเวลานั้นเราใช้วิธีการทบทวนแบบเก่าที่ดี

ในฐานะผู้ตรวจทานสิ่งเดียวที่คุณต้องทำคือการค้นหารหัสทั้งหมดสำหรับ "// todo: code review by me"ตรวจสอบการเปลี่ยนแปลงและตรวจสอบรหัสกลับโดยไม่มีความคิดเห็น "todo ... "

หากมีปัญหาเราสลับกลับไปเป็นวิธีการสื่อสารแบบดั้งเดิม (mail / chat / etc)

วิธีนี้ทำให้เรามีคุณสมบัติหลักสองประการที่เรากำลังค้นหาอยู่ในระบบตรวจสอบ:

• ค่าใช้จ่ายเบามาก
• ตรวจสอบย้อนกลับ

เราพบว่าวิธีที่มีประสิทธิภาพที่สุดในการตรวจสอบโค้ดคือ 1 ต่อ 1 โดยใช้ github เพื่อแสดงความแตกต่างในสาขา

• บุคคลหนึ่งถูกมองว่าเป็นผู้รักษาประตูเพื่อคุณภาพและตรวจสอบรหัสหรือทีมนั้นมีมาตรฐานหรือไม่

  • ขึ้นอยู่กับขนาดของทีม - ทีม 3 คนจะมีอาวุโส 1 คนที่มีความรู้เกี่ยวกับการปฏิบัติที่ดีที่สุดในขณะที่ทีมงาน 12 คนอาจมี 3 หรือ 4 คนที่จะทำหน้าที่นั้นให้สำเร็จ

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

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

• ทำด้วยตนเองผ่านอีเมลหรือใช้เครื่องมือหรือไม่

  • ในบุคคล. เราใช้ git และ gitub และมีการตรวจสอบโค้ดที่ยอดเยี่ยมและเครื่องมือเปรียบเทียบ diff เพื่อให้การตรวจสอบโค้ดง่ายขึ้น

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

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

เช่นเดียวกับรายการเข้ารหัสคำตอบที่ถูกต้องควรคำนึงถึง:

• ประเภทของ บริษัท (เช่นการเริ่มต้นกับ บริษัท ขนาดใหญ่)
• ขนาดของ บริษัท
• จำนวนผู้พัฒนา
• งบ
• กรอบเวลา
• จำนวนงาน
• ความซับซ้อนของรหัส
• ความสามารถในการวิจารณ์
• ความพร้อมใช้งานของผู้ตรวจสอบ

ฉันทำงานที่ บริษัท หลายแห่งและเห็นกระบวนการมากมาย ทีมปัจจุบันของฉันจัดการสิ่งที่ดีที่สุดที่ฉันเคยเห็นมา

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

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

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

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

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

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