เป็นเรื่องง่ายที่จะลองใช้เครื่องวิเคราะห์โค้ดแบบคงที่ แต่การจะนำไปปฏิบัติโดยเฉพาะอย่างยิ่งในการพัฒนาโครงการเก่าขนาดใหญ่นั้นต้องใช้ทักษะ หากทำไม่ถูกต้อง เครื่องวิเคราะห์สามารถเพิ่มงาน ชะลอการพัฒนา และลดระดับทีมได้ เรามาพูดคุยสั้นๆ เกี่ยวกับวิธีการรวมการวิเคราะห์แบบคงที่เข้ากับกระบวนการพัฒนาอย่างเหมาะสม และเริ่มใช้การวิเคราะห์ดังกล่าวเป็นส่วนหนึ่งของ CI/CD
การแนะนำ
เมื่อเร็ว ๆ นี้ความสนใจของฉันถูกดึงไปที่สิ่งพิมพ์ "" ในอีกด้านหนึ่งนี่เป็นบทความที่ดีที่ควรค่าแก่การทำความคุ้นเคย ในทางกลับกันสำหรับฉันดูเหมือนว่ายังไม่ได้ให้คำตอบที่สมบูรณ์เกี่ยวกับวิธีการนำการวิเคราะห์แบบคงที่ไปใช้ในโครงการที่มีจำนวนมากอย่างไม่ลำบาก ของ Legacy Code บทความบอกว่า คุณสามารถรับหนี้ทางเทคนิคและทำงานได้เฉพาะกับโค้ดใหม่เท่านั้น แต่ไม่มีคำตอบว่าจะทำอย่างไรกับหนี้ทางเทคนิคนี้ในภายหลัง
ทีมงาน PVS-Studio ของเราเสนอมุมมองในหัวข้อนี้ มาดูกันว่าปัญหาในการใช้ตัววิเคราะห์โค้ดแบบสแตติกเกิดขึ้นตั้งแต่แรกอย่างไร วิธีแก้ไขปัญหานี้ และวิธีค่อยๆ กำจัดหนี้ทางเทคนิคอย่างไม่ลำบาก
ปัญหา
โดยปกติแล้วการเปิดใช้งานและดูว่าเครื่องวิเคราะห์แบบคงที่ทำงานอย่างไรนั้นไม่ใช่เรื่องยาก [] คุณอาจเห็นข้อผิดพลาดที่น่าสนใจหรือแม้แต่ช่องโหว่ที่อาจน่ากลัวในโค้ด คุณสามารถแก้ไขบางสิ่งบางอย่างได้ แต่แล้วโปรแกรมเมอร์หลายคนก็ยอมแพ้
เครื่องวิเคราะห์แบบคงที่ทั้งหมดก่อให้เกิดผลบวกลวง นี่เป็นคุณลักษณะของวิธีการวิเคราะห์โค้ดแบบคงที่ และไม่สามารถดำเนินการใดๆ เกี่ยวกับเรื่องนี้ได้ ในกรณีทั่วไป นี่เป็นปัญหาที่แก้ไขไม่ได้ ตามที่ยืนยันโดยทฤษฎีบทของไรซ์ [] อัลกอริธึมการเรียนรู้ของเครื่องจะไม่ช่วย [] แม้ว่าบุคคลจะไม่สามารถบอกได้เสมอไปว่ารหัสนี้หรือรหัสนั้นผิด แต่คุณไม่ควรคาดหวังสิ่งนี้จากโปรแกรม :)
ผลบวกลวงจะไม่เป็นปัญหาหากมีการกำหนดค่าเครื่องวิเคราะห์แบบคงที่ไว้แล้ว:
- ปิดใช้งานชุดกฎที่ไม่เกี่ยวข้อง
- การวินิจฉัยที่ไม่เกี่ยวข้องบางอย่างถูกปิดใช้งาน
- หากเรากำลังพูดถึง C หรือ C++ แมโครจะถูกมาร์กอัปซึ่งมีโครงสร้างเฉพาะที่ทำให้เกิดคำเตือนที่ไม่มีประโยชน์ปรากฏขึ้นในทุกที่ที่ใช้แมโครดังกล่าว
- ฟังก์ชั่นของตัวเองถูกทำเครื่องหมายว่าดำเนินการคล้ายกับฟังก์ชั่นระบบ (อะนาล็อกของตัวเอง เมมปี้ หรือ printf) [];
- ผลบวกลวงถูกปิดใช้งานโดยเฉพาะโดยใช้ความคิดเห็น
- เป็นต้น
ในกรณีนี้ เราคาดว่าอัตราผลบวกลวงจะต่ำประมาณ 10-15% [] กล่าวอีกนัยหนึ่ง คำเตือนเครื่องวิเคราะห์ 9 ใน 10 รายการจะบ่งชี้ถึงปัญหาที่แท้จริงในโค้ด หรืออย่างน้อยก็ "โค้ดมีกลิ่นแรง" เห็นด้วยสถานการณ์นี้น่าพอใจอย่างยิ่งและผู้วิเคราะห์เป็นเพื่อนแท้ของโปรแกรมเมอร์
ในความเป็นจริงในโครงการขนาดใหญ่ภาพเริ่มต้นจะแตกต่างไปจากเดิมอย่างสิ้นเชิง ตัววิเคราะห์จะออกคำเตือนนับร้อยหรือนับพันสำหรับรหัสเดิม เป็นไปไม่ได้ที่จะเข้าใจอย่างรวดเร็วว่าคำเตือนใดที่เกี่ยวข้องและไม่เกี่ยวข้อง ไม่มีเหตุผลที่จะนั่งลงและเริ่มจัดการกับคำเตือนเหล่านี้ทั้งหมดเนื่องจากงานหลักในกรณีนี้จะหยุดเป็นเวลาหลายวันหรือหลายสัปดาห์ โดยปกติแล้ว ทีมไม่สามารถรับสถานการณ์ดังกล่าวได้ จะมีความแตกต่างจำนวนมากที่ทำให้ประวัติศาสตร์การเปลี่ยนแปลงเสียไป และการแก้ไขส่วนย่อยจำนวนมากอย่างรวดเร็วในโค้ดจะส่งผลให้เกิดการพิมพ์ผิดและข้อผิดพลาดครั้งใหม่อย่างหลีกเลี่ยงไม่ได้
และที่สำคัญที่สุด ความสำเร็จในการต่อสู้กับคำเตือนนั้นไม่สมเหตุสมผลเลย ยอมรับว่าเนื่องจากโครงการดำเนินไปอย่างประสบความสำเร็จมาหลายปีแล้ว ข้อผิดพลาดร้ายแรงส่วนใหญ่จึงได้รับการแก้ไขแล้ว ใช่ การแก้ไขเหล่านี้มีราคาแพงมาก ต้องแก้ไขจุดบกพร่อง ได้รับคำติชมจากผู้ใช้เชิงลบเกี่ยวกับจุดบกพร่อง และอื่นๆ เครื่องวิเคราะห์แบบคงที่จะช่วยแก้ไขข้อผิดพลาดเหล่านี้ในขั้นตอนการเขียนโค้ดได้อย่างรวดเร็วและประหยัด แต่ในขณะนี้ไม่ทางใดก็ทางหนึ่งข้อผิดพลาดเหล่านี้ได้รับการแก้ไขแล้วและเครื่องวิเคราะห์จะตรวจพบข้อผิดพลาดที่ไม่สำคัญในโค้ดเก่าเป็นหลัก รหัสนี้อาจใช้ไม่ได้ อาจใช้น้อยมาก และข้อผิดพลาดในรหัสอาจไม่นำไปสู่ผลลัพธ์ที่เห็นได้ชัดเจน บางทีเงาจากปุ่มอาจเป็นสีที่ไม่ถูกต้อง แต่ก็ไม่ได้รบกวนการใช้ผลิตภัณฑ์ของใครก็ตาม
แน่นอนว่าแม้แต่ความผิดพลาดเล็กๆ น้อยๆ ก็ยังถือว่าผิดพลาด และบางครั้งความผิดพลาดก็สามารถซ่อนจุดอ่อนที่แท้จริงได้ อย่างไรก็ตาม การละทิ้งทุกสิ่งทุกอย่างและใช้เวลาเป็นวัน/สัปดาห์ในการจัดการกับข้อบกพร่องที่แทบไม่ปรากฏให้เห็นนั้นดูเหมือนเป็นความคิดที่น่าสงสัย
โปรแกรมเมอร์ดู ดู ดูคำเตือนเหล่านี้ทั้งหมดเกี่ยวกับโค้ดการทำงานแบบเก่า... และพวกเขาคิดว่า: เราสามารถทำได้โดยไม่ต้องวิเคราะห์แบบคงที่ มาเขียนฟังก์ชันใหม่ที่มีประโยชน์กันดีกว่า
ในแบบของพวกเขาเอง พวกเขาพูดถูก พวกเขาคิดว่าก่อนอื่นพวกเขาจะต้องกำจัดคำเตือนเหล่านี้ออกไปเสียก่อน เมื่อนั้นพวกเขาจึงจะสามารถได้รับประโยชน์จากการใช้งานตัววิเคราะห์โค้ดเป็นประจำ มิฉะนั้นคำเตือนใหม่จะจมอยู่กับคำเตือนเก่าและจะไม่มีใครสนใจคำเตือนเหล่านั้น
นี่เป็นการเปรียบเทียบแบบเดียวกับคำเตือนของคอมไพเลอร์ ไม่ใช่โดยไม่มีเหตุผลที่พวกเขาแนะนำให้คงจำนวนคำเตือนของคอมไพเลอร์ไว้ที่ 0 หากมี 1000 คำเตือน เมื่อมี 1001 ครั้งจะไม่มีใครสนใจคำเตือนนั้น และยังไม่ชัดเจนว่าจะค้นหาคำเตือนใหม่ล่าสุดนี้ได้ที่ไหน
สิ่งที่แย่ที่สุดในเรื่องนี้คือถ้ามีคนจากเบื้องบนในขณะนี้บังคับให้คุณใช้การวิเคราะห์โค้ดแบบคงที่ สิ่งนี้จะลดแรงจูงใจของทีมเท่านั้น เนื่องจากจากมุมมองของพวกเขาจะมีความซับซ้อนของระบบราชการเพิ่มเติมที่ขวางทางเท่านั้น จะไม่มีใครดูรายงานของเครื่องวิเคราะห์ และการใช้งานทั้งหมดจะ "บนกระดาษ" เท่านั้น เหล่านั้น. อย่างเป็นทางการแล้ว การวิเคราะห์ถูกสร้างขึ้นในกระบวนการ DevOps แต่ในทางปฏิบัติสิ่งนี้ไม่เป็นประโยชน์ต่อใครเลย เราได้ยินเรื่องราวโดยละเอียดที่บูธจากผู้เข้าร่วมการประชุม ประสบการณ์ดังกล่าวสามารถกีดกันโปรแกรมเมอร์จากการใช้เครื่องมือวิเคราะห์แบบคงที่เป็นเวลานานหรือตลอดไป
การดำเนินการและขจัดหนี้ทางเทคนิค
ที่จริงแล้ว ไม่มีอะไรยากหรือน่ากลัวในการแนะนำการวิเคราะห์แบบคงที่ แม้แต่ในโปรเจ็กต์เก่าขนาดใหญ่ก็ตาม
CI / ซีดี
นอกจากนี้ เครื่องวิเคราะห์ยังสามารถเป็นส่วนหนึ่งของกระบวนการพัฒนาอย่างต่อเนื่องได้ทันที ตัวอย่างเช่น การแจกจ่าย PVS-Studio มียูทิลิตี้สำหรับการดูรายงานในรูปแบบที่คุณต้องการได้อย่างสะดวก และการแจ้งเตือนไปยังนักพัฒนาที่เขียนส่วนที่มีปัญหาของโค้ด สำหรับผู้ที่สนใจเปิดตัว PVS-Studio จากระบบ CI/CD ฉันขอแนะนำให้คุณทำความคุ้นเคยกับระบบที่เกี่ยวข้อง เอกสารและชุดบทความ:
แต่กลับมาที่ปัญหาผลบวกลวงจำนวนมากในขั้นตอนแรกของการนำเครื่องมือวิเคราะห์โค้ดไปใช้
แก้ไขหนี้ทางเทคนิคที่มีอยู่และจัดการกับคำเตือนใหม่
เครื่องวิเคราะห์คงที่เชิงพาณิชย์สมัยใหม่ช่วยให้คุณศึกษาเฉพาะคำเตือนใหม่ที่ปรากฏในโค้ดใหม่หรือโค้ดที่เปลี่ยนแปลง การดำเนินการตามกลไกนี้จะแตกต่างกันไป แต่สาระสำคัญก็เหมือนกัน ในเครื่องวิเคราะห์แบบคงที่ PVS-Studio ฟังก์ชันนี้จะถูกนำไปใช้ดังนี้
หากต้องการเริ่มใช้การวิเคราะห์แบบคงที่อย่างรวดเร็ว เราขอแนะนำให้ผู้ใช้ PVS-Studio ใช้กลไกในการปราบปรามคำเตือนจำนวนมาก [] แนวคิดทั่วไปมีดังต่อไปนี้ ผู้ใช้เปิดเครื่องวิเคราะห์และได้รับคำเตือนมากมาย เนื่องจากโครงการที่ได้รับการพัฒนามาหลายปียังมีชีวิตอยู่ กำลังพัฒนา และสร้างรายได้ จึงมีแนวโน้มว่าจะไม่มีคำเตือนมากมายในรายงานที่บ่งบอกถึงข้อบกพร่องร้ายแรง กล่าวอีกนัยหนึ่ง จุดบกพร่องที่สำคัญได้รับการแก้ไขแล้วไม่ทางใดก็ทางหนึ่งโดยใช้วิธีการที่มีราคาแพงกว่า หรือต้องขอบคุณคำติชมจากลูกค้า ดังนั้นทุกสิ่งที่เครื่องวิเคราะห์พบในปัจจุบันถือได้ว่าเป็นหนี้ทางเทคนิคซึ่งเป็นไปไม่ได้ที่จะพยายามกำจัดทันที
คุณสามารถบอกให้ PVS-Studio พิจารณาว่าคำเตือนเหล่านี้ไม่เกี่ยวข้องในตอนนี้ (เก็บหนี้ทางเทคนิคไว้ใช้ภายหลัง) และคำเตือนจะไม่แสดงอีกต่อไป เครื่องวิเคราะห์จะสร้างไฟล์พิเศษที่จะบันทึกข้อมูลเกี่ยวกับข้อผิดพลาดที่ยังไม่น่าสนใจ และตอนนี้ PVS-Studio จะออกคำเตือนเฉพาะรหัสใหม่หรือรหัสที่เปลี่ยนแปลงเท่านั้น ยิ่งไปกว่านั้น ทั้งหมดนี้ถูกนำมาใช้อย่างชาญฉลาด ตัวอย่างเช่น หากมีการเพิ่มบรรทัดว่างที่จุดเริ่มต้นของไฟล์ซอร์สโค้ด ผู้วิเคราะห์จะเข้าใจว่าอันที่จริงไม่มีอะไรเปลี่ยนแปลง และจะยังคงเงียบต่อไป ไฟล์มาร์กอัปนี้สามารถใส่ลงในระบบควบคุมเวอร์ชันได้ ไฟล์มีขนาดใหญ่ แต่ก็ไม่เป็นปัญหา เนื่องจากไม่มีประโยชน์ที่จะจัดเก็บบ่อยๆ
ตอนนี้โปรแกรมเมอร์ทุกคนจะเห็นคำเตือนที่เกี่ยวข้องกับรหัสใหม่หรือรหัสที่เปลี่ยนแปลงเท่านั้น ดังนั้นคุณสามารถเริ่มใช้เครื่องวิเคราะห์ได้ตามที่กล่าวไว้ตั้งแต่วันถัดไป และคุณสามารถกลับไปเป็นหนี้ทางเทคนิคได้ในภายหลัง และค่อยๆ แก้ไขข้อผิดพลาดและกำหนดค่าเครื่องวิเคราะห์
ดังนั้นปัญหาแรกในการใช้งานเครื่องวิเคราะห์ในโครงการเก่าขนาดใหญ่จึงได้รับการแก้ไขแล้ว ทีนี้เรามาดูกันว่าจะทำอย่างไรกับหนี้ทางเทคนิค
การแก้ไขข้อบกพร่องและการปรับโครงสร้างใหม่
สิ่งที่ง่ายที่สุดและเป็นธรรมชาติที่สุดคือการจัดสรรเวลาเพื่อวิเคราะห์คำเตือนของเครื่องวิเคราะห์ที่ถูกระงับอย่างหนาแน่น และค่อยๆ จัดการกับคำเตือนเหล่านั้น ที่ใดที่คุณควรแก้ไขข้อผิดพลาดในโค้ด ที่ใดที่หนึ่งคุณควรปรับโครงสร้างใหม่เพื่อแจ้งให้ผู้วิเคราะห์ทราบว่าโค้ดนั้นไม่มีปัญหา ตัวอย่างง่ายๆ:
if (a = b)คอมไพเลอร์และตัววิเคราะห์ C++ ส่วนใหญ่บ่นเกี่ยวกับโค้ดดังกล่าว เนื่องจากมีความเป็นไปได้สูงที่พวกเขาต้องการเขียนจริงๆ (ก == ข). แต่มีข้อตกลงที่ไม่ได้พูดและมักจะระบุไว้ในเอกสารประกอบว่าหากมีวงเล็บเพิ่มเติมจะถือว่าโปรแกรมเมอร์จงใจเขียนโค้ดดังกล่าวและไม่จำเป็นต้องสาบาน ตัวอย่างเช่น ในเอกสารประกอบ PVS-Studio สำหรับการวินิจฉัย มีเขียนไว้ชัดเจนว่าบรรทัดต่อไปนี้ถือว่าถูกต้องและปลอดภัย:
if ((a = b))ตัวอย่างอื่น. มันถูกลืมในรหัส C ++ นี้หรือไม่? ทำลาย หรือไม่?
case A:
foo();
case B:
bar();
break;เครื่องวิเคราะห์ PVS-Studio จะออกคำเตือนที่นี่ . นี่อาจไม่ใช่ข้อผิดพลาด ในกรณีนี้ คุณควรให้คำแนะนำแก่ parser โดยการเพิ่มแอตทริบิวต์ หรือตัวอย่างเช่น __แอตทริบิวต์__((ผิดพลาด)):
case A:
foo();
[[fallthrough]];
case B:
bar();
break;อาจกล่าวได้ว่าการเปลี่ยนแปลงโค้ดดังกล่าวไม่สามารถแก้ไขข้อบกพร่องได้ ใช่ นี่เป็นเรื่องจริง แต่มันมีประโยชน์สองประการ ประการแรก รายงานเครื่องวิเคราะห์จะกำจัดผลบวกลวง ประการที่สอง โค้ดจะเข้าใจได้ง่ายขึ้นสำหรับผู้ที่เกี่ยวข้องกับการบำรุงรักษา และนี่เป็นสิ่งสำคัญมาก! สำหรับสิ่งนี้เพียงอย่างเดียว ก็คุ้มค่าที่จะดำเนินการปรับโครงสร้างใหม่เล็กน้อยเพื่อทำให้โค้ดมีความชัดเจนและง่ายต่อการบำรุงรักษา เนื่องจากเครื่องวิเคราะห์ไม่เข้าใจว่าจำเป็นต้อง "หยุด" หรือไม่ จึงทำให้เพื่อนโปรแกรมเมอร์ไม่ชัดเจนเช่นกัน
นอกเหนือจากการแก้ไขข้อบกพร่องและการปรับโครงสร้างใหม่แล้ว คุณยังสามารถระงับคำเตือนตัววิเคราะห์ที่ผิดพลาดอย่างเห็นได้ชัดได้อีกด้วย คุณสามารถปิดใช้งานการวินิจฉัยที่ไม่เกี่ยวข้องบางอย่างได้ เช่น มีคนคิดว่าคำเตือนไม่มีประโยชน์ เกี่ยวกับการเปรียบเทียบค่าทศนิยม/ค่าสองเท่า และบางส่วนก็จัดว่ามีความสำคัญและควรค่าแก่การศึกษา [] คำเตือนใดที่ถือว่าเกี่ยวข้องและคำเตือนใดที่ไม่ขึ้นอยู่กับทีมพัฒนาในการตัดสินใจ
มีวิธีอื่นในการระงับการแจ้งเตือนที่ผิดพลาด ตัวอย่างเช่น มีการกล่าวถึงมาร์กอัปมาโครก่อนหน้านี้ ทั้งหมดนี้อธิบายไว้ในรายละเอียดเพิ่มเติมในเอกสารประกอบ สิ่งที่สำคัญที่สุดคือการเข้าใจว่าหากคุณค่อยๆ เข้าใกล้การทำงานด้วยผลบวกลวงอย่างเป็นระบบ ก็ไม่มีอะไรผิดปกติ คำเตือนที่ไม่น่าสนใจส่วนใหญ่จะหายไปหลังการกำหนดค่า และมีเพียงส่วนที่ต้องมีการศึกษาอย่างรอบคอบและการเปลี่ยนแปลงโค้ดบางส่วนเท่านั้นที่ยังคงอยู่
นอกจากนี้ เรายังช่วยเหลือลูกค้าของเราในการตั้งค่า PVS-Studio เสมอหากเกิดปัญหาใดๆ ขึ้น ยิ่งไปกว่านั้น มีหลายกรณีที่พวกเราเองกำจัดคำเตือนที่ผิดพลาดและแก้ไขข้อผิดพลาด [] ในกรณีที่ฉันตัดสินใจที่จะพูดถึงว่าตัวเลือกสำหรับการขยายความร่วมมือนี้ก็เป็นไปได้เช่นกัน :)
วิธีวงล้อ
มีอีกวิธีหนึ่งที่น่าสนใจในการค่อยๆ ปรับปรุงคุณภาพโค้ดโดยกำจัดคำเตือนตัววิเคราะห์แบบคงที่ ประเด็นสำคัญคือจำนวนคำเตือนสามารถลดลงได้เท่านั้น
จำนวนคำเตือนที่ออกโดยเครื่องวิเคราะห์แบบคงที่จะถูกบันทึกไว้ ประตูคุณภาพได้รับการกำหนดค่าในลักษณะที่ขณะนี้คุณสามารถป้อนรหัสที่ไม่เพิ่มจำนวนการดำเนินการเท่านั้น เป็นผลให้กระบวนการค่อยๆ ลดจำนวนการแจ้งเตือนเริ่มต้นโดยการปรับเครื่องวิเคราะห์และแก้ไขข้อผิดพลาด
แม้ว่าบุคคลหนึ่งต้องการโกงเล็กน้อยและตัดสินใจที่จะผ่านประตูคุณภาพไม่ใช่โดยการกำจัดคำเตือนในโค้ดใหม่ของเขา แต่ด้วยการปรับปรุงโค้ดของบุคคลที่สามเก่า สิ่งนี้ก็ไม่น่ากลัว ในทำนองเดียวกัน วงล้อจะหมุนไปในทิศทางเดียว และจำนวนข้อบกพร่องจะลดลงเรื่อยๆ แม้ว่าบุคคลจะไม่ต้องการแก้ไขข้อบกพร่องใหม่ของตนเอง แต่เขาก็ยังต้องปรับปรุงบางอย่างในโค้ดข้างเคียง เมื่อถึงจุดหนึ่ง วิธีง่ายๆ ในการลดจำนวนคำเตือนจะสิ้นสุดลง และเมื่อถึงจุดบกพร่องที่แท้จริงจะได้รับการแก้ไข
วิธีการนี้อธิบายรายละเอียดเพิ่มเติมในบทความที่น่าสนใจมากโดย Ivan Ponomarev ""ซึ่งฉันแนะนำให้อ่านกับทุกคนที่สนใจในการปรับปรุงคุณภาพโค้ด
ผู้เขียนบทความยังมีรายงานในหัวข้อนี้: "".
ข้อสรุป
ฉันหวังว่าหลังจากบทความนี้ ผู้อ่านจะยอมรับเครื่องมือวิเคราะห์แบบคงที่มากขึ้น และต้องการนำไปใช้ในกระบวนการพัฒนา หากคุณมีคำถามใด ๆ เราพร้อมเสมอ ผู้ใช้เครื่องวิเคราะห์แบบคงที่ PVS-Studio ของเราและช่วยเหลือในการใช้งาน
มีข้อสงสัยทั่วไปอื่นๆ เกี่ยวกับว่าการวิเคราะห์แบบคงที่จะสะดวกและมีประโยชน์จริงหรือไม่ ฉันพยายามขจัดข้อสงสัยเหล่านี้ส่วนใหญ่ในสิ่งพิมพ์ “เหตุผลที่แนะนำตัววิเคราะห์โค้ดคงที่ PVS-Studio ในกระบวนการพัฒนา” [].
ขอบคุณสำหรับความสนใจของคุณและมา และลองใช้เครื่องวิเคราะห์ PVS-Studio
ลิงค์เพิ่มเติม
- อันเดรย์ คาร์ปอฟ.
- วิกิพีเดีย .
- อันเดรย์ คาร์ปอฟ, วิกตอเรีย คาเนียวา .
- PVS-สตูดิโอ เอกสารประกอบ .
- อันเดรย์ คาร์ปอฟ. .
- PVS-สตูดิโอ เอกสารประกอบ .
- อีวาน อันดรีอาชิน. .
- พาเวล เอเรเมเยฟ, สเวียโตสลาฟ ราซมีสลอฟ .
- อันเดรย์ คาร์ปอฟ. .
หากคุณต้องการแบ่งปันบทความนี้กับผู้ชมที่พูดภาษาอังกฤษ โปรดใช้ลิงก์การแปล: Andrey Karpov .
ที่มา: will.com