บทวิจารณ์โค้ดข้อดีคืออะไร [ปิด]

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

เราควรพิจารณาทำรีวิวรหัสอย่างเป็นทางการ? อะไรคือข้อดี

เราทำรีวิวรหัสแตกต่างกันเล็กน้อย (อาจ)

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

ข้อดี:

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

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

ฉันหวังว่ามันจะนำอาหารมาคิด โชคดี.

คุณอาจต้องการอ่านหนังสือฟรีเล่มนี้:

http://smartbear.com/best-kept-secrets-of-peer-code-review/

แน่นอนว่าพวกเขามีผลิตภัณฑ์ที่จะผลักดัน แต่ยังมีข้อมูลที่เป็นประโยชน์มากมายอยู่ในนั้น

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

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

จุดสองจุดแรกนั้นค่อนข้างดีโดยการเขียนโปรแกรมคู่ข้อที่สามนั้นขึ้นอยู่กับคู่นั้น ๆ และจะดีขึ้นจากการทบทวนรหัสอย่างเป็นทางการ

คุณควรทำรีวิวรหัสอย่างเป็นทางการ?

อย่างแน่นอน

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

ฉันแนะนำบทวิจารณ์โค้ดสองรูปแบบ:

ความคิดเห็นรหัสเพียร์

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

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

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

ความคิดเห็นรหัสกลุ่ม

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

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

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

ฉันพบว่าการใช้สองวิธีนี้จะช่วยเพิ่มอัตราความก้าวหน้าของวิศวกรและการนับบั๊กที่ต่ำกว่า :)

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

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

โดยเฉลี่ยเราทำการเรียนหนึ่งครั้งต่อสัปดาห์โดยมีผู้เข้าร่วมประมาณ 3-5 คน แต่ละเซสชันใช้เวลาประมาณ 3-4 ชั่วโมงต่อคน (รวมถึงการเตรียมการ) และตรวจสอบรหัส 200-300 บรรทัด (LOC) * ในขั้นตอนนี้ในช่วงระยะเวลากว่า 6 เดือนเราสามารถตรวจสอบประมาณ 5K LOC จากประมาณ 50K

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

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

* นี่เป็นขั้นตอนปกติของการรีวิวโค้ดอย่างเป็นทางการ

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

อ้างจากWikipedia (เน้นโดยฉัน)

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

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

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

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

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

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

ประโยชน์คืออะไร มันจะดีกว่าถ้าคุณพิจารณาความเสี่ยงที่จะไม่ทำ

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

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

สำหรับฉันข้อได้เปรียบหลักของรีวิวโค้ดคือทำให้ผู้คนเขียนโค้ดได้ดีขึ้น

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