จุดประสงค์ของการตรวจสอบรหัสคืออะไร


76

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

ดังนั้นจุดประสงค์ของการตรวจสอบรหัสคืออะไร


16
ที่เกี่ยวข้อง (บนสแต็กล้น): วัตถุประสงค์ของการวิจารณ์โค้ด
yannis

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

3
"จุดประสงค์ของการตรวจสอบรหัสคืออะไร" เพื่อป้องกันนักพัฒนาไม่ให้เขียนโค้ด terribadและควบคุมพวกมันในทิศทางที่ถูกต้อง
zzzzBov

7
Seems Code Reviewอาจมีคำตอบทางอ้อมสำหรับคำถามนี้ .. เพียงแค่ดูคำถามและคำตอบที่นั่นจุดประสงค์ของการตรวจสอบรหัสนั้นค่อนข้างชัดเจน :)
Mathieu Guindon

3
ฉันสงสัยว่ากี่ครั้งที่โปรแกรมเมอร์ค้นพบข้อผิดพลาดในรหัสของตัวเองผ่านกระบวนการง่ายๆในการอธิบายรหัสในระหว่างการตรวจสอบ?
ขวานที่ไม่ทำงาน

คำตอบ:


75

มีสาเหตุหลายประการที่ทำให้คุณต้องการตรวจสอบโค้ด:

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

มีหลายกรณีธุรกิจสำหรับการทำรีวิว:

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

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


7
+1 ฉันคิดว่าคุณเห็นประเด็นหลักอย่างชัดเจนพร้อมลำดับความสำคัญที่ถูกต้อง การออกแบบให้สอดคล้องกันเมื่อต้องรับมือกับผู้ร่วมงานที่พบโซลูชัน "WTF" ที่สร้างสรรค์มาก ๆ สามารถทำได้โดยการตรวจสอบรหัสปกติเท่านั้น
Doc Brown

เราทำการตรวจสอบโค้ดในโค้ด JavaScript ของเราส่วนใหญ่เพื่อให้แน่ใจว่านักพัฒนาใช้มาตรฐานที่กำหนดไว้โดยใช้รูปแบบที่กำหนดไว้เมื่อออกแบบโมดูลโดยใช้ส่วนประกอบที่ให้มาและไม่เริ่มทำการเข้ารหัสนินจา (โดยเจตนาหรือไม่) สำหรับ. พวกเขายังเป็นคนที่ยอดเยี่ยมในการมองเห็นบางคนเขียนทับthisบริบทโดยไม่ตั้งใจไม่ได้ใช้.hasOwnPropertyในสถานที่ที่ควรอยู่ ฯลฯ ฯลฯ - ดังนั้นสำหรับมาตรฐานส่วนใหญ่ ในภาษาที่มีการจัดการเช่น C # คุณปิดหลักสูตรมีเหตุผลน้อยกว่าหลายประการสำหรับภาษาแบบไดนามิก
Nope

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

51

ความคิดเห็นเกี่ยวกับโค้ดที่มีเครื่องมือสำหรับการถ่ายทอดความรู้

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

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

    การตรวจสอบรหัสอย่างละเอียดจะต้องมีการตรวจสอบบ่อยครั้งกับเอกสารต่างๆ มันเป็นวิธีที่ยอดเยี่ยมในการเรียนรู้ภาษาหรือ API

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

บทวิจารณ์โค้ดไม่ได้เกี่ยวกับ:

  • ... การค้นหาข้อบกพร่อง นั่นคือสิ่งที่การทดสอบมีไว้สำหรับ มันจะยังคงเกิดขึ้นบ่อยครั้งที่การตรวจสอบรหัสพบปัญหาบางอย่าง

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


2
ประเด็นสุดท้ายของคุณเกี่ยวกับปัญหาสไตล์ nitpicking ฉันไม่เห็นด้วยทั้งหมด - เราเพิ่งมีประสบการณ์ที่น่ารำคาญในการตรวจสอบโค้ดของนักพัฒนารุ่นรองและการร้องเรียนที่เห็นได้ชัดที่สุดนั้นเป็นเรื่องจริง แต่ไม่ใช่ปัญหาสไตล์ที่เป็นโปรแกรมได้อย่างง่ายดาย บังคับใช้ .... waaaaaay มากเกินไปถ้าข้อความสั่งสำหรับ edgecases ฯลฯ ; ปัญหาที่ใช่คุณสามารถทำให้คอมพิวเตอร์ค้นหาได้ในบางกรณี แต่ส่วนใหญ่ไม่ได้มีปัญหาที่ควรค่าแก่การค้นหาโดยสคริปต์ ใช้เวลา 30 วินาทีในการอ่านเพื่อให้เราเริ่มเห็นมันและอีก 30 เพื่ออธิบายให้กับนักพัฒนา & หวังว่าจะทำให้เป็นปัญหา ยังคงตกใจอยู่: /
ผู้รักความสงบ

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

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

2
นอกเหนือจาก @DocBrown แล้วยังมีกรณีที่ไม่สามารถทดสอบได้อย่างง่ายดาย - การแข่งขันข้อมูล, การหยุดชะงักบางประเภท, livelocks, พฤติกรรม / ค่าที่ไม่ได้กำหนด (ส่วนใหญ่ใน C / C ++ แต่ลำดับขององค์ประกอบในตารางแฮชใน undefined เช่นกัน) (การเปิดไฟล์ในลูปอาจเป็นความคิดที่ไม่ดีแม้กับ GC) บางส่วนของสิ่งเหล่านั้นสามารถตรวจพบโดยการวิเคราะห์แบบคงสมาร์ทพอ -compiler-
Maciej Piechotka

2
@pacifist ตัวอย่างเฉพาะของคุณจะถูกทำลายอย่างสิ้นเชิงในการตรวจสอบโค้ด มันจะเป็นค่าสถานะสีแดงสำหรับตัววิเคราะห์โค้ดแบบคงที่ (ความซับซ้อน Cyclomatic 17!) การตรวจสอบโค้ดจะระบุฟังก์ชันนี้อย่างรวดเร็วว่าเป็นปัญหาในรูปแบบความหมาย (หรือแม้แต่อัลกอริทึม!) อย่างไรก็ตาม ปัญหาประเภทนี้ไม่ได้เป็นเพียงปัญหา "สไตล์" หากคุณปฏิบัติกับมันคุณจะมีโค้ดที่น่ารังเกียจในที่เก็บของคุณในไม่ช้า มันเป็นเพียง "สไตล์" หลังจากทั้งหมด
Pimgd

12

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


2
สิ่งนี้ดูเหมือนจะไม่เสนออะไรมากมายใน 4 คำตอบก่อนหน้านี้
ริ้น

2
@gnat: คำตอบอื่น ๆ ที่อยู่การถ่ายโอนความรู้และข้อบกพร่องที่พบ สิ่งเหล่านี้มีความสำคัญ แต่มีมากกว่าการตรวจสอบรหัส

1
เท่าที่ฉันสามารถบอกได้มีคำตอบที่สมเหตุสมผลมากกว่านี้ในส่วนของคำตอบ : "หากคุณกำลังมองหาการอภิปรายที่ครอบคลุมเกี่ยวกับประโยชน์และกลยุทธ์การใช้งานสำหรับการแสดงความคิดเห็นเพื่อนฉันขอแนะนำให้ตรวจสอบ Peer Reviews ในซอฟต์แวร์: คู่มือปฏิบัติโดย Karl Wiegers " คำตอบนี้ยังครอบคลุมถึงมัน "แก้ไขกับรหัสที่ซับซ้อนมากเกินไปเป็น"
ริ้น

2
@gnat มันเน้นมุมมองที่แตกต่างของคะแนนที่เพิ่มขึ้นในคำตอบอื่น ๆ คุณเคยสับสนกับรหัสของคุณที่คุณเขียนเมื่อหกเดือนก่อนหรือไม่? ตรวจสอบรหัสช่วยให้คุณเร่งกระบวนการนั้น หากเพื่อนร่วมงานของคุณงงงวยโดยรหัสของคุณคุณยังสามารถชี้แจงได้ในขณะที่ปัญหายังคงสดในหน่วยความจำของคุณ
200_success

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

7

ฉันต้องการเพิ่มสองด้านที่ไม่ครอบคลุมโดยคำตอบที่ยอดเยี่ยมอื่น ๆ :

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

อีกเหตุผลที่ดีคือการพัฒนาความปลอดภัยที่ดีขึ้น หนึ่งต้องดูที่การข้ามไปของ Apple ล้มเหลว (บรรทัดของรหัสซ้ำโดยบังเอิญ) หรือHeartbleed bug (ความล้มเหลวขั้นพื้นฐานในการตรวจสอบอินพุต) เพื่อทำความเข้าใจถึงความสำคัญของการตรวจสอบรหัสที่เหมาะสมในวงจรการพัฒนาที่ปลอดภัย

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