ประโยชน์ที่แท้จริงของการวิเคราะห์รหัสคงที่คืออะไร?

เครื่องมือเช่นpc-lintหรือQACสามารถใช้เพื่อทำการวิเคราะห์รหัสแบบคงที่บนฐานรหัส

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

ประโยชน์ที่แท้จริงของการวิเคราะห์รหัสคงที่คืออะไร?

ฉันทำงานในสถานที่ที่ใช้ระบบวิเคราะห์โค้ดเชิงพาณิชย์ที่เรียกว่า Coverity Prevent และมันก็น่าทึ่งมาก! มันซับซ้อนและชาญฉลาดจริงๆ

เราโยนทั้งรหัสโอเพ่นซอร์สและรหัส C และ C ++ ที่มีความจุประมาณ 18 GB และมันจะติดตามผ่านเส้นทางของรหัสและค้นหาข้อบกพร่องที่ลึกซึ้งที่จะทำให้มนุษย์ตลอดไปติดตามได้อย่างรวดเร็ว มันก็ยอดเยี่ยมในการหาสิ่งต่าง ๆ ที่มักจะเป็น Heisenbugs

มันวิ่งทุกสองสามวันกับฐานรหัสของเราและฟีเจอร์ที่ดีก็คือเราสามารถบอกได้ว่า "นี่ไม่ใช่ข้อผิดพลาดจริงๆ" และมันจะจำได้ว่าในอนาคต

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

หลังจากมีประสบการณ์นั้นฉันดูค่อนข้างดีในการวิเคราะห์รหัสแบบคงที่

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

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

ยกตัวอย่างเช่นผู้เขียนได้ตั้งใจทำงานตามเงื่อนไขนี้จริง ๆ หรือไม่?

if (x = 1) {
    ...
}

หรือบางทีมือใหม่สับสนการคัดเลือกคำศัพท์:

char* number = "123";
int converted = number;

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

จากมุมมองของผู้ให้คำปรึกษาเครื่องมือวิเคราะห์แบบคงที่ทุกตัวจะมีเสียงรบกวนบ้าง แต่ไม่ใช่ว่าเครื่องมือวิเคราะห์แบบคงที่ทั้งหมดจะถูกสร้างขึ้นเท่ากัน เครื่องมือวิเคราะห์แบบคงที่เช่น Coverity, Klocwork, Grammatech มีเทคนิคการวิเคราะห์ที่ดีที่ควรให้ผลลัพธ์ที่แม่นยำยิ่งขึ้น หากคุณปรับแต่งและปรับแต่งเพิ่มเติมคุณจะได้รับผลลัพธ์ที่ดีกว่าโดยทั่วไป (หลังจากทั้งหมดเครื่องมือวิเคราะห์แบบคงที่จะต้องสามารถทำงานกับรหัสประเภทต่าง ๆ ทั้งหมดจากอุปกรณ์การแพทย์ขนาดเล็กไปจนถึงระบบปฏิบัติการเครือข่าย) การกำหนด "สัญญาณรบกวน" นั้นขึ้นอยู่กับเกณฑ์ของคุณสำหรับสิ่งที่ถือว่าเป็นรายงานที่มีค่า ที่ปลายด้านหนึ่งของสเปกตรัมนักพัฒนาบางคนทำเครื่องหมายรายงานทั้งหมดที่พวกเขาไม่ได้แก้ไขว่าเป็น "เท็จ" (แม้แต่รหัสที่เขียนไม่ดีซึ่งพวกเขาไม่มีเวลาแก้ไข) และอีกด้านหนึ่ง

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

ใน บริษัท ก่อนหน้าของฉันเราใช้ตัววิเคราะห์แบบคงที่โดย Parasoft และเชื่อกันว่าภายในทีมนั้นมีข้อผิดพลาดอย่างน้อย 60% ของเวลาทำงานก่อนที่จะรวบรวม

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

ตัวเลือกที่ดีที่สุดอันดับที่สองคือการลงทุนสำหรับเครื่องมือวิเคราะห์แบบคงที่ระดับสูงอย่างน้อยหนึ่งรายการ (เช่น Coverity ที่กล่าวถึงก่อนหน้าหรือ KLOCwork) เนื่องจากเครื่องมือเหล่านี้ทำการวิเคราะห์ที่ลึกกว่าผ้าสำลีมากเช่นอัตราส่วนสัญญาณต่อสัญญาณรบกวนจึงดีกว่ามาก

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

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

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

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

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