ฉันจะเลือกรหัสที่จะตรวจสอบได้อย่างไร


14

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

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

นี่คือปัจจัยบางอย่างที่ฉันสามารถคิดได้ซึ่งอาจส่งผลกระทบต่อตัวเลือก:

  • ภาษา: C, Java, SQL, PL / SQL
  • อายุรหัส: รหัสใหม่กับรหัสเก่า
  • การใช้รหัส: รหัสที่ใช้บ่อยเทียบกับรหัสที่ใช้งานได้ไม่เต็มประสิทธิภาพ
  • ความสำคัญของรหัส: รหัสที่สำคัญกับรหัสที่ไม่สำคัญ
  • ผู้พัฒนา: รหัสนักพัฒนาซอฟต์แวร์ระดับสูงและรหัสผู้พัฒนาอาวุโส

ฉันเข้าใจว่านี่ไม่ใช่คำถามที่มีคำตอบที่ชัดเจน แต่คำแนะนำใด ๆ ที่มีประโยชน์

บางคำถามที่เกี่ยวข้องกับอุปกรณ์ต่อพ่วง:

คำตอบ:


12

โดยทั่วไปคุณต้องตรวจสอบทุกอย่าง หากแอปพลิเคชันใหม่มี 2 000 LOC จะต้องตรวจสอบทั้งหมด 2 000 LOC

นั่นเป็นสาเหตุที่ไม่มีวิธีปฏิบัติที่ดีที่สุดเกี่ยวกับวิธีเลือกสิ่งที่จะตรวจสอบ

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

  • บน codebase (รหัสเสาหินเดี่ยวจะยากต่อการเขียน / ตรวจทานมากกว่าชุดของส่วนประกอบแยกต่างหาก ฯลฯ )

  • บริบทของคุณ (คุณสามารถหยุดทุกสิ่งที่คุณทำงานและใช้เวลาสามเดือน (สามปี?) ทำงานเฉพาะในการเขียน / ตรวจทานใหม่หรือคุณต้องทำโดยใช้เวลาน้อยเมื่อคุณมีเวลาว่าง)?

  • ประเภทของการตรวจสอบที่คุณทำ (คุณมีรายการตรวจสอบสิ่งที่ต้องตรวจสอบหรือไม่ขึ้นอยู่กับรายการของรายการตรวจสอบคุณอาจต้องการตรวจสอบบางส่วนก่อน)

ถ้าฉันเป็นคุณฉันจะ:

  • ปฏิบัติตามหลักการ 80% -20% ที่กล่าวถึงในความคิดเห็นแรกของคำถามที่สองที่คุณเชื่อมโยง

  • พิจารณาว่า 100% เป็นอุดมคติไม่คุ้มค่า มันเหมือนกับการครอบคลุมโค้ด 100% สำหรับการทดสอบหน่วยยกเว้นว่าการครอบคลุมโค้ดนั้นเป็นไปไม่ได้หรือแพงมาก

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

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


หากคุณทำ TDD อย่างถูกต้องความคุ้มครอง 100% ไม่ใช่แค่ง่ายมันเป็นสิ่งที่หลีกเลี่ยงไม่ได้และจริง ๆ แล้วกลายเป็นแถบต่ำมาก
Jonathan Hartley

4

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

คุณจะต้องหาวิธีที่จะติดตามว่าคุณได้ตรวจสอบส่วนของรหัสเพื่อให้คุณสามารถวิเคราะห์ความครอบคลุมการตรวจทานของรหัสของคุณที่เกี่ยวข้องกับข้อกังวลอื่น ๆ

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


3

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

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

หากคุณปรับโครงสร้างใหม่อย่างไม่ลดละการตรวจสอบโค้ดจะมีประโยชน์ มิฉะนั้นมันจะเสียเวลา

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

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


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

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

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

@BurhanAli - มันเหมือนจริงมาก ๆ ลูกค้าของเราเป็นลูกค้าที่มีโปรไฟล์สูง (คิดว่า Microsoft) และรอบการเผยแพร่ของเรานั้นรวดเร็วมาก ควรใช้เวลาทั้งหมดประมาณ 30 นาทีอาจจะใช้เวลาประมาณหนึ่งชั่วโมงในการพัฒนาเพื่อตรวจสอบการเปลี่ยนแปลง หากใช้เวลานานกว่านั้นแสดงว่าคุณมักจะไม่แบ่งงานของคุณออกเป็นชิ้นเล็กชิ้นน้อยซึ่งเป็นปัญหาที่แตกต่างออกไปโดยสิ้นเชิง
Charles Lambert

2
@gbjbaanb คุณปล่อยให้โค้ดที่ยังไม่ผ่านการตรวจสอบเข้าสู่การผลิตหรือไม่ ว้าว. มันไม่เกี่ยวกับการไม่ไว้วางใจนักพัฒนาของคุณ (คุณสามารถรับหนึ่งในนักพัฒนาของคุณเพื่อตรวจสอบรหัสของคนอื่น) มันเกี่ยวกับการค้นหาข้อผิดพลาดที่เห็นได้ชัดอย่างแจ่มแจ้ง
Rob

2

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

เมื่อตรวจสอบการแก้ไขโค้ดที่มีอยู่ผู้พัฒนาควรปฏิบัติตามกฎ boyscout ปล่อยให้โค้ดดีกว่าที่เขาพบ

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

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

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

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


+1 สำหรับ "ปล่อยให้โค้ดดีกว่าที่เขาพบ" ฉันพยายามให้กำลังใจเสมอ สำหรับการตรวจสอบโค้ดเก่า 10 ปีเพื่อประโยชน์ของมันฉันเห็นด้วยกับสิ่งที่คุณพูด แต่อาจมีประโยชน์บางอย่างในการทำเช่นนี้แม้ว่าจะทำให้ทีมรู้สึกสะดวกสบายมากขึ้นกับแนวคิดในการตรวจสอบหรือไม่? ไม่มีอันตรายมากนักที่จะป้องกันรหัสที่พวกเขาไม่ได้เขียน (หรืออายุมากจนลืมที่จะเขียน)
Burhan Ali

1

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

เราใช้การวิเคราะห์Atlassian FishEyeกับการตรวจสอบรหัสเบ้าหลอมรวมกับ JIRA + SVN เพื่อจุดประสงค์นี้

เมื่อนักพัฒนาตรวจสอบรหัสในเรื่องที่เฉพาะเจาะจงเขาจะสร้างบทวิจารณ์ใหม่ใน FishEye ซึ่งเขาเลือกสมาชิกคนอื่น ๆ ของทีมเพื่อทำการตรวจสอบ

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

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

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

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.