สมมติว่าคนหนึ่งทำงานใน บริษัท สมมุติที่มีนักพัฒนาหลายคนที่ไม่ค่อยได้ทำงานร่วมกันในโครงการและบอสไม่เชื่อว่าการตรวจสอบโค้ดนั้นคุ้มค่ากับเวลาและค่าใช้จ่าย
อะไรคือข้อโต้แย้งต่าง ๆ ที่สามารถนำเสนอในสถานการณ์นี้ที่จะพรรณนาประโยชน์ของการตรวจสอบโค้ด? นอกจากนี้อะไรคือข้อโต้แย้งที่อาจเกิดขึ้นกับการตรวจสอบโค้ดที่นี่และวิธีการเหล่านี้สามารถตอบโต้ได้อย่างไร?
คำตอบ:
หากคุณต้องพิสูจน์ตัวเองสำหรับสิ่งพื้นฐานดังกล่าวคุณมีปัญหาที่ใหญ่กว่า
คุณเป็นผู้เชี่ยวชาญทีมของคุณควรตัดสินใจว่าคุณใช้แนวปฏิบัติอะไร บางทีคุณควรเริ่มโน้มน้าวใจเจ้านายของคุณเกี่ยวกับหลักการที่สำคัญมาก
เจ้านายของคุณควรจะตัดสินใจอะไรที่จะทำและที่สำคัญทำไมทำมัน คุณควรดูแลวิธีการสร้าง
(นั่นไม่ได้หมายความว่าคุณไม่สามารถแนะนำสิ่งที่ต้องทำใน บริษัท ของคุณ) หัวหน้าที่ดีควรสนับสนุนให้พนักงานของเขามีส่วนร่วมในกลยุทธ์องค์กร)
อย่างไรก็ตามนี่คือวิธีที่ฉันดูบทวิจารณ์เพียร์:
เนื่องจากการเขียนโปรแกรมเป็นงานทางปัญญาที่เข้มข้นมากคน ๆ หนึ่งจึงไม่สามารถมั่นใจได้ว่าทุกอย่างสมบูรณ์แบบ ดังนั้นการตรวจสอบรหัสจึงมั่นใจได้ว่า:
ทุกคนรับผลประโยชน์โดยตรงจากมัน:
การตรวจสอบรหัสสามารถทำให้นักพัฒนาซอฟต์แวร์หลายคนคุ้นเคยกับรหัสเดียวกัน นี่เป็นสิ่งที่ดี เกิดอะไรขึ้นถ้าผู้เขียนต้นฉบับตัดสินใจที่จะเลิกหรือแย่กว่านั้นมีบางอย่างไม่ดีเกิดขึ้นกับเขา หากการตรวจสอบโค้ดเสร็จสิ้นเป็นประจำผู้อื่นสามารถเข้าควบคุมได้รวดเร็ว
เพื่อนอาจสามารถตรวจพบจุดบกพร่องที่อาจเกิดขึ้นหรือปัญหาด้านประสิทธิภาพในระหว่างการตรวจสอบโค้ด สิ่งนี้จะลด QA และความพยายามในการพัฒนา สิ่งนี้สามารถชดเชยค่าใช้จ่ายเพิ่มเติมที่เกี่ยวข้องกับการตรวจสอบโค้ด
การทบทวนรหัสส่งเสริมการแบ่งปันความรู้ เพื่อนสามารถบอกวิธีที่ดีกว่าหรือวิธีอื่นในการทำสิ่งต่าง ๆ ตัวฉันเองได้เรียนรู้มากมายจากเพื่อนของฉันผ่านการตรวจสอบโค้ด
การตรวจสอบโค้ดช่วยเสริมแนวทางการเข้ารหัสตามด้วยทีม หากทีมไม่ได้มีหนึ่งนั้นจะต้องมีการแก้ไข รหัสมีไว้เพื่อเขียนครั้งเดียวและอ่านหลายครั้ง แนวทางการเข้ารหัสเป็นขั้นตอนต่อรหัสที่อ่านได้ รหัสมีไว้เพื่อให้คนอื่นอ่านได้ จะมีวิธีใดที่ดีไปกว่าการมีบทวิจารณ์โค้ดเพื่อให้อ่านง่าย
คำตอบที่ดีมากมายที่นี่ บางสิ่งที่ฉันจะเพิ่ม:
เมื่อคุณต้องอธิบายรหัสให้คนอื่นบ่อยครั้งในการอธิบายนักพัฒนาอาจรู้ทันทีว่าเขามีข้อบกพร่อง ฉันเคยเห็นมันเกิดขึ้นซ้ำแล้วซ้ำอีกว่า dev หยุดการตายในเพลงของเขาและพูดว่า "โอ้รอผิดปกติ" ก่อนที่ผู้ตรวจสอบจะเข้าใจสิ่งที่ดีพอที่จะเห็นข้อผิดพลาด
การรู้รหัสของคุณจะถูกตรวจสอบโดยบุคคลอื่นทำให้คุณมีแรงจูงใจมากขึ้นในการใช้มาตรฐานการเข้ารหัส (ทำให้การบำรุงรักษาง่ายขึ้น) หรือใช้วิธีการ "คาวบอย" น้อยลงซึ่งไม่มีใครยกเว้นตัวคุณเอง คุณไม่ต้องการที่จะอายเมื่อคุณแสดงรหัสของคุณกับคนอื่นดังนั้นคุณจึงทำงานได้ดีขึ้นในตอนแรก เนื่องจากปัจจัยความลำบากใจจึงทำให้โค้ดมีความคิดเห็นน้อยลง: "ฉันไม่รู้ว่าทำไมงานนี้ แต่ไม่ยุ่งกับมัน" ในฐานรหัส
นักพัฒนาที่มีความต้องการการกำกับดูแลหรือการฝึกอบรมที่กว้างขวางยิ่งขึ้นสามารถระบุได้ง่าย คนไร้ความสามารถก็เช่นกัน ยิ่งคุณพบและแก้ไขปัญหาด้านประสิทธิภาพได้เร็วเท่าใดทีมก็จะยิ่งดีขึ้นเท่านั้นและคุณภาพของแอปพลิเคชั่นก็จะยิ่งสูงขึ้นเท่านั้น มันเป็นการดีที่จะหาข้อมูลนี้ก่อนที่คุณจะรับคนใหม่ที่ต้องการการฝึกอบรมและมอบหมายให้เขาเป็นส่วนที่สำคัญที่สุดของการสมัครของคุณ
บางครั้งมันเป็นเพียงเรื่องของการแก้ไขความเข้าใจผิดที่จะบันทึกการทำผิดพลาดแบบเดียวกันในที่อื่น ๆ ตัวอย่างเช่นเราเพิ่งตรวจสอบ SQL สำหรับรายงานที่ซับซ้อนและพบว่า devs ใหม่ของเราหลายรายมีความเข้าใจผิดเหมือนกันเกี่ยวกับตำแหน่งที่จะหาข้อมูลเฉพาะในฐานข้อมูล ต้องแก้ไข) ที่จะสำคัญต่อการเขียนรายงานทั้งหมดอย่างถูกต้อง ด้วยการค้นหาปัญหาและแก้ไขในรายงานแรกที่พวกเขาเขียนมันช่วยให้เกิดข้อผิดพลาดเดียวกันในส่วนที่เหลือของรายงาน และมีบางอย่างที่ devs รุ่นเก่า (ในเวลาทำงานที่นี่ไม่ใช่อายุ) คุ้นเคยกับสิ่งที่พวกเขาไม่คิดว่ามันจำเป็นต้องมีการอธิบาย
จูเนียร์สามารถเรียนรู้จากโค้ดที่ซับซ้อนยิ่งขึ้นที่เขียนโดยผู้อาวุโส (ผู้ที่มีแนวโน้มที่จะเข้าใจข้อผิดพลาดในการวางกับดักและกรณีที่มีขอบดีกว่า) และผู้อาวุโสสามารถเรียนรู้จากเทคนิคใหม่ที่จูเนียร์ใช้
บางครั้งคนที่ทำงานในส่วนที่แตกต่างกัน แต่ส่วนที่เกี่ยวข้องของแอปพลิเคชันตระหนักว่าพวกเขากำลังไปในสองทิศทางที่แตกต่างและพิเศษร่วมกัน โอ๊ะโอแก้ไขง่ายกว่าตอนนี้
มันไม่ใช่เรื่องง่ายเลยที่จะแอบเข้าไปในค่าที่มีการกำหนดรหัสตายตัวซึ่งจะเปลี่ยนแปลงตลอดเวลาเพียงเพื่อให้ได้สิ่งที่ใช้ได้ในขณะนี้ สิ่งนี้จะป้องกันข้อผิดพลาดในอนาคตมากมายเช่นสิ่งต่าง ๆ ที่เปลี่ยนแปลงในช่วงต้นปีงบประมาณ
บางครั้งฉันติดอยู่กับวิธีการทำบางสิ่งบางอย่างและเรียนรู้เทคนิคใหม่ที่เป็นเพียงสิ่งที่ฉันต้องการจากการตรวจสอบรหัสของผู้อื่น
หากคุณคุ้นเคยกับความคิดของสมาชิกคนอื่น ๆ ในทีมของคุณ (การตรวจสอบโค้ดที่จะช่วยให้คุณเข้าใจได้) ก็จะง่ายขึ้นในการแก้ไขปัญหาในภายหลังเพราะคุณจะเริ่มด้วยความเข้าใจว่า Joe จะเข้าหาแบบนั้นอย่างไร ปัญหา.
เช่นเดียวกับการแบ่งปันความรู้ที่ผู้อื่นพูดถึงค้นหาตัวอย่างของข้อบกพร่องที่จะพบได้ในระหว่างการตรวจสอบโค้ดและวัดระยะเวลาที่ต้องใช้ในการแก้ไข - ซึ่งรวมถึงเวลาที่ใช้ในการค้นคว้าปัญหาและปล่อยเวอร์ชั่นที่แก้ไข เวลาจริงแก้ไขข้อผิดพลาด
ใช้ค่าใช้จ่ายนี้ซึ่งอาจจะเป็นความพยายามอย่างน้อยสองสามวันและเปรียบเทียบกับเวลาที่คุณใช้ในการตรวจสอบโค้ดและดำเนินการกับผลลัพธ์
นี่จะแสดงให้หัวหน้าของคุณเห็นว่าการตรวจสอบโค้ดนั้นคุ้มค่ากับค่าใช้จ่าย
รหัสรีวิวสามารถ:
จุดด้อย
หากเป็นจริงแล้วทำไมเราถึงมีเวลาทำสิ่งที่สองหรือสามครั้งสำหรับลูกค้ารายเดียวกัน แต่เราไม่มีเวลาเพียงพอที่จะทำสิ่งที่ถูกต้องในครั้งแรก
หากคุณต้องการอ้างอิงเอกสารจากนั้นฉันจะไม่มองไปไกลไปกว่า "Code Complete" ในหนังสือเล่มนี้อธิบายถึงจำนวนข้อผิดพลาดที่ติดกับการทดสอบหน่วยเทียบกับการตรวจสอบโดยเพื่อน มันช่างน่าประหลาดใจ การทดสอบหน่วยถ้าหน่วยความจำทำหน้าที่ฉันถูกต้องจับเพียง 30% ของข้อบกพร่องทั้งหมดในขณะที่การตรวจสอบจากเพื่อนอย่างเป็นทางการจับ ~ 70%
นำข้อมูลนั้นไปแสดงให้เขาเห็นในหนังสือและยื่นอุทธรณ์ต่อฝ่ายการเงิน มันใช้เวลานานกว่าและมีราคาแพงกว่ามากในการอนุญาตให้แมลงผ่านได้มากกว่าที่จะจับมันเร็ว
วิธีการเกี่ยวกับการเรียกใช้การสาธิต (โครงการประเภท "มิกกี้เมาส์" หนึ่งสัปดาห์) ดำเนินการแบบคู่ขนานโดยสองทีมทีมหนึ่งใช้การทบทวนโค้ด
ในตอนท้ายของสัปดาห์ประเมินคุณภาพการทำงานของแต่ละทีมฉันค่อนข้างมั่นใจว่าผู้ตรวจสอบรหัสจะออกมาดีกว่า
จาก Construx ของ Steve Mcconnel กรณีศึกษาทางธุรกิจสำหรับการพัฒนาซอฟต์แวร์ที่ดีขึ้นและการพัฒนาซอฟท์แวร์ผลไม้แขวนต่ำ (LHF) ของการพัฒนาซอฟต์แวร์ จากรายการ "LHF หลังที่จะไม่ถูกต่อต้านโดยผู้บริหารระดับสูง" จะแสดงรายการการตรวจสอบ
เมื่อนำเสนอภาพให้เน้นที่ภาพที่ใหญ่ขึ้น
แสดงรายการสิทธิประโยชน์ (โค้ดที่ดีกว่า, ข้อผิดพลาดน้อยลง, เขียนซ้ำน้อยลง ฯลฯ ) และพูดถึงการตรวจสอบโค้ดเป็นหนึ่งในเทคนิคที่คุณอยากแนะนำ
ฉันจะทำให้มันเป็นส่วนหนึ่งของภาพรวมของการทำงานฝีมือซอฟต์แวร์
เตรียมพร้อมที่จะทำงานมากมายด้วยตัวคุณเองในการส่งเสริมหลักการเหล่านี้
ส่วนใหญ่ทั้งหมดไม่คาดหวังว่าการโน้มน้าวใจจะเป็น "การประชุมหนึ่งครั้งและทำ" สิ่งที่ kinda
คุณควรสร้างเคสเมื่อเวลาผ่านไปด้วยความสงบและสม่ำเสมอ เมื่อคุณรำคาญที่สุดโดยข้อบกพร่องที่จะได้รับการแก้ไขโดยเทคนิคที่ดีกว่ามักจะเป็นเวลาที่เลวร้ายที่สุดที่จะทำให้กรณีของคุณในขณะที่คุณมีแนวโน้มที่จะอารมณ์มากเกินไปและมีเหตุผลน้อยกว่า สิ่งนี้อาจดูเหมือนจะค่อนข้างต่อต้าน แต่มันเป็นสิ่งที่ฉันได้เรียนรู้มานานกว่า 30 ปีของการเขียนโปรแกรม เห็นได้ชัดว่า ymmv