วิธีการสนับสนุนให้นักพัฒนารุ่นเยาว์มีส่วนร่วมในการตรวจสอบโค้ด

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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