ใช้การวิเคราะห์แบบสแตติกกับกระบวนการ แทนที่จะมองหาจุดบกพร่องกับมัน

ฉันได้รับแรงบันดาลใจในการเขียนบทความนี้จากเนื้อหาจำนวนมากเกี่ยวกับการวิเคราะห์ทางสถิตที่พบเห็นมากขึ้นเรื่อยๆ ประการแรกนี้ บล็อก PVS-สตูดิโอซึ่งโปรโมตตัวเองอย่างแข็งขันบน Habré ด้วยการทบทวนข้อผิดพลาดที่พบโดยเครื่องมือของพวกเขาในโครงการโอเพ่นซอร์ส PVS-studio เพิ่งนำมาใช้ รองรับจาวาและแน่นอน ผู้พัฒนา IntelliJ IDEA ซึ่งตัววิเคราะห์ในตัวน่าจะเป็นตัวที่ล้ำหน้าที่สุดสำหรับ Java ในปัจจุบัน ไม่สามารถอยู่ห่าง.

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

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

วงล้อ (ที่มา: วิกิพีเดีย).

สิ่งที่เครื่องวิเคราะห์แบบคงที่ไม่สามารถทำได้

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

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

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

การวิเคราะห์แบบคงที่ไม่ใช่การค้นหาจุดบกพร่อง

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

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

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

การวิเคราะห์แบบคงที่เป็นมากกว่าการค้นหาจุดบกพร่อง

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

• ตรวจสอบรูปแบบการเข้ารหัสในความหมายที่กว้างที่สุดของคำ ซึ่งรวมถึงการตรวจสอบการจัดรูปแบบและการค้นหาการใช้วงเล็บว่าง/เพิ่มเติม การตั้งค่าเกณฑ์สำหรับเมตริก เช่น จำนวนบรรทัด / ความซับซ้อนของเมธอดแบบ cyclomatic เป็นต้น - ทุกสิ่งที่อาจทำให้โค้ดอ่านและบำรุงรักษาได้มากขึ้น ใน Java เครื่องมือนี้คือ Checkstyle ใน Python คือ flake8 โปรแกรมของคลาสนี้มักจะเรียกว่า "linters"
• ไม่เพียง แต่สามารถวิเคราะห์รหัสปฏิบัติการเท่านั้น ไฟล์ทรัพยากร เช่น JSON, YAML, XML, .properties สามารถ (และควร!) ตรวจสอบความถูกต้องโดยอัตโนมัติ จะดีกว่าไหมหากพบว่าเนื่องจากเครื่องหมายคำพูดที่ไม่ได้จับคู่ โครงสร้าง JSON จึงใช้งานไม่ได้ในช่วงเริ่มต้นของการตรวจสอบความถูกต้องของ Pull Request โดยอัตโนมัติ มากกว่าเมื่อดำเนินการทดสอบหรือขณะรันไทม์ มีเครื่องมือที่เหมาะสม เช่น YAMLlint, JSONLint.
• การคอมไพล์ (หรือการแยกวิเคราะห์สำหรับภาษาการเขียนโปรแกรมแบบไดนามิก) ก็เป็นการวิเคราะห์แบบคงที่เช่นกัน ตามกฎแล้ว คอมไพเลอร์สามารถออกคำเตือนที่ระบุปัญหาเกี่ยวกับคุณภาพของซอร์สโค้ดได้ และไม่ควรเพิกเฉย
• บางครั้งการคอมไพล์ไม่ใช่แค่การคอมไพล์โค้ดสั่งการเท่านั้น ตัวอย่างเช่น หากคุณมีเอกสารประกอบในรูปแบบ AsciiDoctorจากนั้นในขณะที่แปลงเป็นตัวจัดการ HTML/PDF AsciiDoctor (ปลั๊กอิน Maven) สามารถออกคำเตือน เช่น เกี่ยวกับลิงก์ภายในที่เสีย และนี่คือเหตุผลที่ดีที่จะไม่ยอมรับ Pull Request ที่มีการเปลี่ยนแปลงเอกสารประกอบ
• การตรวจสอบการสะกดเป็นประเภทของการวิเคราะห์แบบคงที่ คุณประโยชน์ สะกด สามารถตรวจสอบการสะกดคำได้ไม่เฉพาะในเอกสารเท่านั้น แต่ยังตรวจสอบซอร์สโค้ดของโปรแกรม (ความคิดเห็นและตัวอักษร) ในภาษาโปรแกรมต่างๆ รวมถึง C/C++, Java และ Python การสะกดคำผิดในส่วนติดต่อผู้ใช้หรือเอกสารก็เป็นข้อบกพร่องด้วยเช่นกัน!
• การทดสอบการกำหนดค่า (ดูที่ นี้ и นี้ รายงาน) แม้ว่าจะดำเนินการในรันไทม์การทดสอบหน่วยเช่น pytest แต่จริง ๆ แล้วยังเป็นการวิเคราะห์แบบคงที่เนื่องจากไม่ได้เรียกใช้ซอร์สโค้ดระหว่างการดำเนินการ

อย่างที่คุณเห็น การค้นหาจุดบกพร่องในรายการนี้มีบทบาทสำคัญน้อยที่สุด และทุกอย่างอื่นๆ สามารถทำได้ผ่านการใช้เครื่องมือโอเพ่นซอร์สฟรี

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

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

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

1. การวิเคราะห์แบบคงที่
2. การรวบรวม
3. การทดสอบหน่วย
4. การทดสอบการรวม
5. การทดสอบ UI
6. ตรวจสอบด้วยตนเอง

การเปลี่ยนแปลงที่ถูกปฏิเสธในขั้นตอนที่ N ของไปป์ไลน์จะไม่แพร่กระจายไปยังขั้นตอนที่ N+1

ทำไมถึงเป็นแบบนี้และไม่เป็นอย่างอื่น? ในส่วนการทดสอบของไปป์ไลน์ ผู้ทดสอบจะรู้จักพีระมิดการทดสอบที่รู้จักกันดี

ปิรามิดทดสอบ แหล่งที่มา: บทความ มาร์ติน ฟาวเลอร์.

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

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

ตัวกรองหลายขั้นตอน แหล่งที่มา: วิกิพีเดีย

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

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

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

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

การดำเนินการในโครงการมรดก

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

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

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

รู้จักวิธีการแนะนำประตูคุณภาพดังต่อไปนี้:

• กำหนดขีดจำกัดของจำนวนคำเตือนทั้งหมด หรือจำนวนคำเตือนหารด้วยจำนวนบรรทัดของโค้ด สิ่งนี้ไม่ได้ผลเนื่องจากเกตดังกล่าวข้ามการเปลี่ยนแปลงที่มีข้อบกพร่องใหม่อย่างอิสระจนกว่าจะเกินขีด จำกัด
• ในบางจุด การแก้ไขคำเตือนเก่าทั้งหมดในโค้ดว่าถูกละเว้น และทำให้บิลด์ล้มเหลวเมื่อมีคำเตือนใหม่เกิดขึ้น ฟังก์ชันนี้จัดทำโดย PVS-studio และแหล่งข้อมูลออนไลน์บางส่วน เช่น Codacy ฉันไม่มีโอกาสทำงานใน PVS-studio สำหรับประสบการณ์ของฉันกับ Codacy ปัญหาหลักของพวกเขาคือคำจำกัดความของข้อผิดพลาด "เก่า" และ "ใหม่" คืออะไร เป็นอัลกอริทึมที่ค่อนข้างซับซ้อนซึ่งไม่ ทำงานอย่างถูกต้องเสมอ โดยเฉพาะอย่างยิ่งหากไฟล์ถูกแก้ไขหรือเปลี่ยนชื่ออย่างมาก ในความทรงจำของฉัน Codacy สามารถข้ามคำเตือนใหม่ในคำขอดึง และในขณะเดียวกันก็ข้ามคำขอดึงไม่ได้เนื่องจากคำเตือนที่ไม่เกี่ยวข้องกับการเปลี่ยนแปลงรหัสของ PR นี้
• ในความคิดของฉัน วิธีแก้ปัญหาที่มีประสิทธิภาพที่สุดได้อธิบายไว้ในหนังสือเล่มนี้ การจัดส่งแบบต่อเนื่อง วิธีการ "วงล้อ" แนวคิดหลักคือคุณสมบัติของแต่ละรีลีสคือจำนวนคำเตือนการวิเคราะห์แบบสแตติก และอนุญาตให้ทำการเปลี่ยนแปลงที่ไม่เพิ่มจำนวนคำเตือนทั้งหมดเท่านั้น

วงล้อ

มันทำงานดังนี้:

1. ในระยะเริ่มต้น เรกคอร์ดในข้อมูลเมตาของการเปิดตัวของจำนวนคำเตือนในโค้ดที่ตัววิเคราะห์พบจะถูกนำไปใช้ ดังนั้น เมื่อคุณสร้างอัพสตรีม ผู้จัดการพื้นที่เก็บข้อมูลของคุณไม่ได้เขียนเพียงแค่ "รีลีส 7.0.2" แต่ "รีลีส 7.0.2 ที่มีคำเตือน Checkstyle 100500 รายการ" หากคุณใช้ตัวจัดการพื้นที่เก็บข้อมูลขั้นสูง (เช่น Artifactory) คุณจะสามารถจัดเก็บข้อมูลเมตาเกี่ยวกับรีลีสของคุณได้อย่างง่ายดาย
2. ตอนนี้คำขอดึงแต่ละรายการในบิลด์จะเปรียบเทียบจำนวนคำเตือนที่ได้รับกับจำนวนในรีลีสปัจจุบัน หาก PR นำไปสู่การเพิ่มจำนวนนี้ รหัสจะไม่ผ่านประตูคุณภาพในการวิเคราะห์แบบคงที่ หากจำนวนคำเตือนลดลงหรือไม่เปลี่ยนแปลง ก็จะผ่านไป
3. ในรุ่นถัดไป จำนวนคำเตือนที่คำนวณใหม่จะถูกเขียนกลับไปยังข้อมูลเมตาของรุ่น

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

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

ฉันใช้วิธีนี้ในเวอร์ชันแก้ไข โดยนับคำเตือนแยกกันตามโมดูลโครงการและเครื่องมือวิเคราะห์ ส่งผลให้ไฟล์ YAML พร้อมข้อมูลเมตาของแอสเซมบลีที่มีลักษณะดังนี้:

celesta-sql:
  checkstyle: 434
  spotbugs: 45
celesta-core:
  checkstyle: 206
  spotbugs: 13
celesta-maven-plugin:
  checkstyle: 19
  spotbugs: 0
celesta-unit:
  checkstyle: 0
  spotbugs: 0

ในระบบ CI ขั้นสูงใด ๆ วงล้อสามารถนำไปใช้กับเครื่องมือวิเคราะห์แบบคงที่ใด ๆ โดยไม่ต้องพึ่งปลั๊กอินและเครื่องมือของบุคคลที่สาม เครื่องมือวิเคราะห์แต่ละรายการสร้างรายงานในรูปแบบข้อความธรรมดาหรือ XML ที่แยกวิเคราะห์ได้ง่าย มันยังคงลงทะเบียนเฉพาะตรรกะที่จำเป็นในสคริปต์ CI คุณสามารถดูวิธีการดำเนินการนี้ในโครงการโอเพ่นซอร์สที่ใช้ Jenkins และ Artifactory ได้ ที่นี่ หรือ ที่นี่. ทั้งสองตัวอย่างขึ้นอยู่กับห้องสมุด วงล้อ: วิธี countWarnings() นับแท็ก xml ในไฟล์ที่สร้างโดย Checkstyle และ Spotbugs ตามปกติ และ compareWarningMaps() ใช้วงล้อเดียวกัน โยนข้อผิดพลาดเมื่อจำนวนคำเตือนในหมวดหมู่ใด ๆ เพิ่มขึ้น

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

เกี่ยวกับความสำคัญของการแก้ไขเวอร์ชันเครื่องวิเคราะห์

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

ผลการวิจัย

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

การอ้างอิง

1. การจัดส่งแบบต่อเนื่อง
2. A. Kudryavtsev: การวิเคราะห์โปรแกรม: จะเข้าใจได้อย่างไรว่าคุณเป็นโปรแกรมเมอร์ที่ดี รายงานเกี่ยวกับวิธีการวิเคราะห์โค้ดแบบต่างๆ (ไม่เฉพาะแบบคงที่เท่านั้น!)

ที่มา: will.com