การตรวจสอบรหัสเป็นการปฏิบัติที่ดีหรือไม่?

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

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

อะไรคือประโยชน์ของสิ่งนี้และมีข้อเสียอะไรบ้าง?

การตรวจสอบรหัสเป็นการปฏิบัติที่ดี

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

การตรวจสอบรหัสเกิดขึ้นในหลาย บริษัท แม้ว่าเป็นการยากที่จะบอกว่ามีกระบวนการเฉพาะที่ทุกคนปฏิบัติตาม

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

สิทธิประโยชน์เพิ่มเติมจากการตรวจสอบโค้ด (ตามความเห็นสำหรับคำถามนี้) รวมถึง:

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

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

ความคิดเห็นเกี่ยวกับโค้ดมีหลายประเภท:

• Over-the-shoulder - ที่นักพัฒนาซอฟต์แวร์คนหนึ่งมองข้ามไหล่ของผู้เขียนรหัสขณะที่คนหลังกำลังอ่านรหัส
• ส่งผ่านอีเมล - รหัสที่มาของระบบการจัดการรหัสอีเมลไปยังผู้ตรวจสอบโดยอัตโนมัติหลังจากทำเช็คอิน สารสกัดจากความคิดเห็น:การจัดการที่ล้มเหลวในการจัดสรรเวลาสำหรับการตรวจสอบโค้ดที่เป็นทางการฉันไม่ได้มองไปที่การเปลี่ยนแปลงของเพื่อนร่วมงานเมื่อใดก็ตามที่ฉันดึงการแก้ไขใหม่ลงมาจากแหล่งควบคุมโดยใช้เครื่องมือประวัติ / diff ที่สร้างขึ้นใน Tortise
• การเขียนโปรแกรมคู่ - ผู้เขียนสองคนพัฒนารหัสด้วยกันที่เวิร์กสเตชันเดียวกันซึ่งเป็นเรื่องปกติใน Extreme Programming
• การตรวจสอบโค้ดด้วยเครื่องมือช่วยผู้เขียนและผู้ตรวจทานใช้เครื่องมือพิเศษที่ออกแบบมาสำหรับการตรวจสอบโค้ดเพียร์

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

การอ้างอิงเพิ่มเติมมีการระบุไว้ด้านล่าง (สำหรับการอ่านการดำน้ำลึกมากขึ้น)

• MSDN - ตรวจสอบรหัส
• ค้นหาและแก้ไขช่องโหว่ก่อนที่ใบสมัครของคุณจะจัดส่ง
• ลิงค์วิกิ

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

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

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

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

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

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

หลายเรื่องจะต้องตัดสินใจ:

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

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

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

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

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

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

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

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

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

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

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

ในฐานะที่เป็นนักศึกษาฝึกงานด้านวิศวกรรมซอฟต์แวร์ฉันพบว่าการตรวจสอบโค้ดมีประโยชน์อย่างมาก

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

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

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

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

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

การตรวจสอบรูปแบบและไวยากรณ์พื้นฐานส่วนใหญ่จะถูกตรวจจับโดยใช้เครื่องมือในทุกวันนี้ (FXCop ฯลฯ )

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

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

ฉันยังคิดว่าความคิดเห็นเกี่ยวกับรหัสที่ไม่มีการบังคับใช้เช่นการวางรหัสในการแชร์หรือส่งอีเมลไปรอบ ๆ ด้วยความหวังว่ามีคนสละเวลาทานอาหารกลางวันเพื่อให้ผ่านพ้นไป - เป็นการเสียเวลา

นั่งลงกับกองรายการเครื่องหมายและถ้วยกาแฟในพื้นที่กาแฟที่ดีสำหรับการนี้

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

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