จะค่อยๆแนะนำบทวิจารณ์โค้ดได้อย่างไร?

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

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

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

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

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

มันทำงานหนัก

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

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

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

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

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

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

มีวิธีที่ดีในการแนะนำบทวิจารณ์หรือไม่

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

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

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

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

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

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

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

ฉันรู้สึกถึงการฝืนใจมากจากทีมเพราะมันเป็นอีกสิ่งหนึ่งที่ต้องทำและการสนทนาจะเจ็บปวด

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

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

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

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

วิธีนี้ใช้ได้ผล แต่ก็ไม่สมบูรณ์แบบ

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