รับนักพัฒนาทั้งหมดทำรีวิวรหัส

ฉันเป็นนักพัฒนาซอฟต์แวร์ในทีมนักพัฒนา 7-8 คน เราได้ทำการตรวจสอบโค้ดมาระยะหนึ่งแล้วและคุณภาพของโค้ดก็ดีขึ้นเมื่อเวลาผ่านไป

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

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

คุณจัดการกับปัญหานี้ในทีมของคุณอย่างไร

คุณได้สร้างกฎสำหรับการเลือกผู้ตรวจสอบรหัสหรือไม่

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

ขอบคุณสำหรับคำตอบ / ความคิดของคุณ

เราไม่เลือกผู้ตรวจสอบ

ในทีมของเรา:

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

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

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

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

ส่วน,

คุณคิดว่าผู้ตรวจสอบโค้ดควรได้รับรางวัลเมื่อพวกเขาใช้เวลาในการตรวจสอบโค้ด (ดี) หรือไม่

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

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

• ทำความเข้าใจว่าการเปลี่ยนแปลงคืออะไร คำขอดึง Git ในสาขาฟีเจอร์ช่วยให้กระบวนการนี้ดำเนินไปได้อย่างแท้จริง
• การทำให้โค้ดตรวจสอบเหตุการณ์ที่ผู้คนต้องอยู่ในห้องเดียวกัน สิ่งนี้จะเพิ่มความเครียดของการกำหนดเวลาการประชุมทรัพยากร ฯลฯ GitHub, GitLab และ BitBucket ช่วยให้การตรวจสอบแบบอะซิงโครนัสเพื่อให้สามารถเกิดขึ้นได้เมื่อเพื่อนพร้อม
• ความสามารถในการให้ข้อเสนอแนะที่มีความหมายเมื่อดูรหัส ตามความจริงแล้วคุณลักษณะการแสดงความคิดเห็นแบบบรรทัดต่อบรรทัดใน GitHub, GitLab, Bitbucket คำขอการดึงจะมีประโยชน์มากกว่าการประชุมแบบเห็นหน้า มันให้ความรู้สึกทางการเมืองน้อยลง

ไม่ได้หมายความว่าคุณไม่สามารถใช้ SubVersion หรือเครื่องมืออื่น ๆ (เช่น Fisheye) เพื่อช่วยได้ แต่การรวมเข้าด้วยกันใน Git ไปป์ไลน์ด้วยฟีเจอร์สาขาทำให้งานน่าเบื่อน้อยลง

นอกเหนือจากการใช้เครื่องมือคุณต้องดูความท้าทายทางสังคมเพิ่มเติม:

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

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

ความคิดที่ดีคือการทำแบบ Round Round - คุณเลือกคนที่ทำรีวิวน้อยที่สุดสำหรับโค้ดของคุณ เมื่อเวลาผ่านไปทุกคนในทีมควรทำบทวิจารณ์จำนวนเท่า ๆ กัน มันกระจายความรู้ด้วย

เห็นได้ชัดว่าจะมีข้อยกเว้นเป็นครั้งคราวเช่นวันหยุดที่จะมียอดเขาและราง

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

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

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

ดูเหมือนว่าทีมไม่มีกระบวนการที่เป็นทางการสำหรับการตรวจสอบโค้ด

ฉันไม่ได้พูดถึงการสร้างเอกสาร Word ที่มี 350 หน้า แต่เพียงแค่สัญลักษณ์แสดงหัวข้อย่อยที่เรียบง่ายเกี่ยวกับกระบวนการที่เกิดขึ้น

บิตสำคัญ:

1. กำหนดชุดหลักของผู้ตรวจสอบ ไม่มีข้อความทั่วไป ตั้งชื่อคน

   สิ่งเหล่านี้ควรเป็นนักพัฒนาอาวุโสของคุณ

2. ต้องการผู้ตรวจสอบหลักมากกว่า 1 คนในการลงชื่อออกในการตรวจสอบ

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

รายการ # 3 ช่วยให้ devs อื่น ๆ หมุนเข้าสู่กลุ่มผู้ตรวจสอบหลัก บางสัปดาห์พวกเขาจะใช้เวลาในการตรวจสอบมากกว่าคนอื่น ๆ มันเป็นการกระทำที่สมดุล

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

เมื่อสงสัยให้กำหนดกระบวนการและบอกทีมที่พวกเขาต้องทำ

และมีสิ่งสุดท้ายที่คุณสามารถลองได้ - โต้เถียงอย่างที่มันอาจเป็น: ให้ @ # $% เข้าชมแฟน ๆ ถ้าฉันอาจใช้สำนวน

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

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

บางครั้งคุณต้องปล่อยให้ไททานิคชนน้ำแข็งกัน