วิธีจัดการกับการไม่ใช้รหัสรีวิวในสถานที่ใหม่ของฉันเมื่อฉันมาจากการปฏิบัตินั้น?

ทีมใน บริษัท ใหม่ของฉันไม่มีกระบวนการตรวจสอบรหัส

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

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

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

สามารถตรวจสอบรหัสได้หรือไม่ถ้าคุณมีการทดสอบหน่วย?

แต่ทำไม

บทบาทหลักของการตรวจสอบโดยเพื่อนไม่ใช่การดักจับบั๊ก

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

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

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

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

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

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

มีการศึกษาและสถิติใด ๆ ที่แสดงความเห็นเกี่ยวกับรหัสไม่ใช่เพียงแค่ตัวแก้ไขเวลา แต่เป็นการประหยัดเวลา?

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

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

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

สามารถตรวจสอบรหัสได้หรือไม่ถ้าคุณมีการทดสอบหน่วย?

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

นำมาจากสไลด์สุ่มที่ฉันพบแต่ข้อมูลที่ยากมาจากหนังสือที่สมบูรณ์ของ Steve McConnell:

รีวิวรหัสมีประโยชน์หรือไม่

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

Jeff Atwood แห่ง Coding Horror ที่ http://www.codinghorror.com/blog/2006/01/code-reviews-just-do-it.html

---

"การตรวจสอบส่วนบุคคลมักจะพบข้อบกพร่องประมาณ 60 เปอร์เซ็นต์ซึ่งสูงกว่าเทคนิคอื่น ๆ ยกเว้นการทดสอบต้นแบบและการทดสอบเบต้าในปริมาณมาก"

Steve McConnell, Code Complete 2nd Edition, หน้า 485

รูปที่ 60% มาจากกระดาษ IEEE โดย Shull et al 2002 สิ่งที่เราได้เรียนรู้เกี่ยวกับการต่อสู้ข้อบกพร่องซึ่งมีหัวข้อ:

"ความเห็นจากเพื่อน ๆ จับ 60% ของข้อบกพร่อง"

คำเตือน: คำตอบนี้เป็นประสบการณ์ส่วนตัวของฉัน :)

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

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

ดังนั้นฉันจะบอกว่ามันขึ้นอยู่กับว่าคุณกำลังทำอะไรมีกี่คนที่คุณเป็นต้น

นอกจากนี้ความเสี่ยงที่ codereviews ของคุณจบลงด้วยการทำสงครามก็ไม่ได้ถูกประเมินต่ำเกินไป

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

ตรวจสอบให้แน่ใจว่าโค้ดของคุณเขียนได้ดีและผ่านการทดสอบก่อนการตรวจสอบ

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

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

การตรวจสอบรหัสมีวัตถุประสงค์หลายประการ:

• การค้นหาข้อบกพร่องในรหัส
• การถ่ายโอนความรู้ระหว่างสมาชิกในทีม

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

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

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

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

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

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

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

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

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

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

ในระหว่างนี้ให้ทำสิ่งที่คุณสามารถทำได้เพื่อให้ได้มากที่สุด:

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

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

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

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

จากนั้นทดสอบทุกอย่างก่อนที่จะตรวจสอบสิ่งที่สำคัญที่สุดคือทำงานได้อย่างถูกต้อง

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