ใครควรทำรีวิวโค้ด?

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

อย่างไรก็ตามด้วยระบบปัจจุบันมีสองปัญหา:

1. สถาปนิกกลายเป็นคอขวด

2. นักพัฒนาไม่รับผิดชอบต่อคุณภาพของรหัสและสถาปัตยกรรม (ซึ่งนำไปสู่ปัญหาทุกประเภท)

เราจะแก้ไขปัญหาเหล่านี้ได้อย่างไร เราควรเปลี่ยนใครเป็นผู้ตรวจสอบรหัส?

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

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

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

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

• การเขียนโปรแกรมคู่ สำหรับฉันนี่เป็นเครื่องมือที่ดีที่สุดในการเผยแพร่ความรู้ในทีม

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

ขั้นตอนการตรวจสอบ [*] ที่ฉันชอบคือ:

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

ดังนั้นคำตอบสั้น ๆ สำหรับคำถามของคุณคือ นักพัฒนาควรทำการเปลี่ยนแปลงความเห็น

[*] น่าเสียดายที่นี่ไม่ใช่วิธีการที่โครงการมีส่วนร่วมในการดำเนินงานเสมอไป

ฉันชอบการฝึกฝนการทบทวนโค้ดทีมเป็นครั้งคราวซึ่งรวมถึงทีมสถาปนิกทั้งทีม แต่หลังจากนั้นมีการทบทวนโค้ดมากมายระหว่างสมาชิกสองถึงสามคนของทีม

หากเป็นรหัสที่ยุ่งยากหรือละเอียดอ่อนให้สมัครเป็นสถาปนิกหรือสมาชิกอาวุโสของทีม

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

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

• ทำให้รหัสของคุณเป็นแบบสาธารณะเพื่อให้ทุกคนเห็นสิ่งที่ทุกคนกำลังทำงานอยู่ ใส่ชื่อที่จุดเริ่มต้นของแต่ละไฟล์ที่มีรหัส; อาจพิมพ์ออกมาและประทับตราไว้ใน, เอ่อ, ห้องน้ำหรือที่ใดก็ตามที่คุณรู้สึกว่ามันจะดึงดูดสายตา
• การโปรแกรมคู่ ด้วยสมองอีกข้างคุณคุณจะคิดสองครั้งก่อนที่จะตั้งชื่อตัวแปรของคุณi
• เลือกภารโรงของคุณและอธิบายให้เขาฟังว่าการทำงานของมรดกนั้น (โอ้ใช่มันไม่ทำงาน) การอธิบายรหัสของคุณให้คนอื่นช่วยทราบ บางทีมันอาจจะรวบรวมบางทีมันอาจเป็นสิ่งที่ถูกต้อง แต่คุณไม่เข้าใจว่าทำไม ตอนนี้เป็นโอกาสของคุณ
• มีชุดแนวทางและทำให้ทุกคนปฏิบัติตาม อะไรก็ตามที่เป็นแนวทางก็ดีกว่าไม่มีแนวทาง