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

ทีมของเราเพิ่งเริ่มทำการตรวจสอบโค้ดกับแต่ละเช็คอิน

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

มีหลักฐานการศึกษาหรือการชี้นำจากแหล่งที่รู้จักกันดีซึ่งแนะนำวิธีการที่เป็นประโยชน์หรือไม่?

โปรดทราบถึงเป้าหมายที่ครอบคลุม: ในที่สุดซอฟต์แวร์ที่ใช้งานได้มีความสำคัญเท่านั้น

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

กำหนดขอบเขตที่ชัดเจนสำหรับรีวิวของคุณ

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

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

• อย่าท้าทายประสิทธิภาพที่ไม่ดีเว้นแต่จะมีหน่วยวัดที่แสดงว่าปัญหาอยู่ที่ใด การเพิ่มประสิทธิภาพก่อนวัยอันควรเป็นรากของความชั่วร้ายทั้งหมด ;-)

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

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

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

พัฒนาความเป็นผู้นำ: ด้านมนุษย์ของการตรวจสอบ

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

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

ใช้ประโยชน์จากการปฏิบัติอื่น ๆ

มีบางสิ่งที่คุณสามารถหลีกเลี่ยงได้ในการตรวจสอบโค้ด:

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

ในฐานะนักพัฒนาที่เรามีความคิดควรเปิดอยู่เสมอและไม่เชื่อในเวลาเดียวกัน

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

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

ที่นี่วิธีการส่วนตัว IMO มีการอธิบายวิธีการอย่างชัดเจนในคำถามนี้

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

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

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

การเข้าไปยุ่งกับรหัสของผู้พัฒนาสำหรับการเปลี่ยนแปลงเครื่องสำอางจะเป็นการลดระดับนักพัฒนาซอฟต์แวร์ แต่ในสถานการณ์ที่ต้องทำ นำมีการหาสมดุลระหว่างการให้ตรวจสอบรหัสที่มีประโยชน์และเรียนรู้ที่จะปล่อยให้ไปของข้อบกพร่องเล็ก ๆ น้อย ๆ https://blog.smartbear.com/sqc/for-the-new-team-lead-the-first-six-things-you-should-know/

สิ่งที่ควรทราบ:

1. มันเกี่ยวกับจิตวิทยามากเท่ากับเทคโนโลยีดังนั้นจึงไม่มีกฎทอง
2. สิ่งที่เกี่ยวกับคนไม่เพียง แต่เกี่ยวกับความรู้ แต่ยังเกี่ยวกับวัฒนธรรมและตำแหน่งในลำดับชั้น
3. หากนี่เป็นเกมที่ "ยาวนาน" (บริษัท ที่มั่นคงและมั่นคง) ทีมที่บูรณาการอย่างดีซึ่งผู้คนเชื่อใจกันมักจะมีมูลค่าสูงกว่ารหัสที่อยู่ระหว่างการตรวจสอบ ไม่ควรใช้เพื่อบังคับให้สิ่งต่าง ๆ ที่ไม่จำเป็นต้องดำเนินการ ปีศาจอยู่ในรายละเอียด ...
4. หากนี่เป็นเกม "สั้น ๆ " (โครงการด้านการวิจัยและพัฒนา, คนทำงานอิสระจำนวนมากในกลุ่ม) ค่าใช้จ่ายของ CR มักจะเอาชนะการผจญภัยที่ทำมา และทัศนคติควรเป็น "แค่ทำให้กระทะ"

มีเพียงสองสิ่งที่สำคัญ

1. มีการทดสอบอัตโนมัติสำหรับข้อกำหนดทั้งหมดหรือไม่
2. พวกเขาทั้งหมดผ่าน?

ทุกอย่างอื่นเป็นเครื่องสำอางและควรจะถกเถียงกันเรื่องเบียร์มากกว่าบังคับใช้เป็นประตู

หากคุณติดตามมุมมองนี้จะเป็นการ จำกัด ขอบเขตของการโฟกัส

ข้อกำหนดเหล่านี้ดีหรือไม่? สิ่งใดที่คุณควรทราบก่อนเริ่มงานเช่นประสิทธิภาพความปลอดภัย ฯลฯ ควรอยู่ในนั้น

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