🕟 🌅 🕷️ لماذا يجب عليك اختيار محلل ثابت PVS-Studio لدمجه في عملية التطوير الخاصة بك 😕 🍼 🔘

يعد PVS-Studio أداة للكشف عن الأخطاء ونقاط الضعف المحتملة في التعليمات البرمجية المصدر للبرامج المكتوبة بلغات C أو C ++ أو C # أو Java ، وهي أيضًا أداة اختبار أمان تطبيق ثابت (SAST). من المفترض أن يتم استخدامه كجزء من ممارسة CI ويسمح للمستخدم باكتشاف الأخطاء في مراحل التطوير الأولى ، حيث لا يكلف أي شيء إصلاحها تقريبًا.

تحليل كود ثابت

مع تطور مشاريع البرمجيات ، يزداد حجمها. قارن:

Linux kernel 1.0.0: 176،000 LOC
Linux kernel 5.0: 26،000،000 LOC
Photoshop 1.0: 128،000 LOC
Photoshop CS 6: 10،000،000 LOC

مع نمو المشروع ، ينمو تعقيده بشكل أسرع من الخطي. هذا ما يفسر لماذا كثافة الخطأ ينمو جنبا إلى جنب مع قاعدة الشفرة. إحدى طرق تعويض التعقيد المتزايد هي استخدام أدوات تحليل الشفرة الثابتة.

أداة التحليل الثابتة هي أداة برمجية تقوم بإجراء مراجعة أولية للكود وتشير إلى أجزاء من الكود التي يحتمل أن تحتوي على أخطاء. يسمح هذا للمطورين بإصلاح معظم الأخطاء في مرحلة التطوير الأولى ، حيث يكون الإصلاح أرخص.

لا يحل التحليل الثابت محل ممارسات الكشف عن الأخطاء الأخرى - ولكنه يكملها - مثل مراجعة الكود واختبار الوحدة والتحليل الديناميكي واختبار الانحدار والاختبار اليدوي وما إلى ذلك.

خذ مراجعة الكود ، على سبيل المثال. سيناريو أفضل بكثير هو أن يجد محلل البرامج أكثر الأخطاء تافهة بالنسبة لك حتى تتمكن من التركيز على عمليات فحص عالية المستوى أكثر فائدة للخوارزمية بدلاً من معرفة وظائف المقارنة - أكثر من ذلك ، كما أثبتت تجربتنا ، العين البشرية سيئة في ملاحظة العديد من الأخطاء ومن المرجح جدًا أن يتم تجاهلها أثناء مراجعة التعليمات البرمجية.

ميزة أخرى لأدوات التحليل الثابت هي قاعدة أنماط الأخطاء الواسعة. يمكنهم العثور على عيوب قد لا يعرفها الكثير من المبرمجين ، مثل V698 و V718 و V1023 .

PVS استوديو

نوصي باختيار PVS-Studio ، محلل الكود الثابت الذي طوره فريقنا. إنه يعمل على أنظمة تشغيل Windows و Linux و macOS 64 بت ويمكنه التحقق من الكود المصدري للبرامج لأنظمة ARM 32 بت و 64 بت وأنظمة مضمنة.

حتى كتابة هذه السطور ، يدعم المحلل اللغات والمترجمين التاليين:

النوافذ. Visual Studio 2010-2019 C و C ++ و C ++ / CLI و C ++ / CX (WinRT) و C #
النوافذ. IAR Embb Workbench، C / C ++ Compiler for ARM C، C ++
النوافذ. QNX Momentics ، QCC C ، C ++
ويندوز / لينكس Keil µVision ، DS-MDK ، ARM Compiler 5/6 C، C ++
ويندوز / لينكس Texas Instruments Code Composer Studio، ARM Code Generation Tools C، C ++
ويندوز / لينكس / ماك. GNU Arm Embedded Toolchain ، مترجم Arm Embedded GCC ، C ، C ++
ويندوز / لينكس / ماك. Clang C، C ++
لينكس / ماك. دول مجلس التعاون الخليجي C ، C ++
النوافذ. MinGW C ، C ++
ويندوز / لينكس / ماك. جافا

يأتي المحلل مع وثائق مفصلة باللغتين الإنجليزية والروسية. تتضمن أوصاف قواعد التشخيص أمثلة للرمز الصحيح وغير الصحيح. تتضمن أيضًا روابط إلى مقتطفات برمجية من برامج حقيقية مفتوحة المصدر.

بالنسبة لأولئك المتخصصين الذين سيستخدمون PVS-Studio كأداة SAST ، يتم تعيين التشخيصات وفقًا لمعايير تعداد الضعف الشائعة ومعايير ترميز SEI CERT ومعيار MISRA. فيما يلي جداول تعيين تشخيصات PVS-Studio وفقًا لمعايير مختلفة:

يمكن استخدام المحلل كأداة قائمة بذاتها وكمكون إضافي لبرنامج Visual Studio و IntelliJ IDEA. يستخدم بعض عملائنا أيضًا PVS-Studio كجزء من SonarQube مؤخرًا. عند استخدامه كبرنامج إضافي لبرنامج SonarQube ، يوفر المحلل رسائل تشخيصية إضافية.

لقد قمنا بتطوير عدد من السيناريوهات لاستخدام PVS-Studio مع أنظمة CI. نظرًا لأن مراقبة جميع السيناريوهات خارج نطاق هذه المقالة ، يرجى الرجوع إلى الوثائق. فيما يلي بعض الروابط القليلة لتعطيك الفكرة العامة:

يكتشف PVS-Studio بفعالية مجموعة واسعة من العيوب من الأخطاء المطبعية إلى تسرب الذاكرة . هذا ممكن بفضل تحليل تدفق البيانات ، والتنفيذ الرمزي ، ومطابقة الأنماط ، والتعليق على الطريقة (بما في ذلك التعليق التوضيحي الآلي). لمعرفة المزيد حول مبادئ العمل وراء المحلل ، راجع مقالة " التقنيات المستخدمة في محلل كود PVS-Studio للعثور على الأخطاء ونقاط الضعف المحتملة ".

لماذا يجب عليك استخدام PVS-Studio

إن دمج PVS-Studio في عملية التطوير الخاصة بك سيجعل العديد من الأخطاء أرخص لإصلاحها ، مما يساعد على توفير الوقت ، والتي ستتمكن من الاستثمار في تنفيذ ميزة جديدة أو إجراء اختبارات أكثر شمولًا على مستوى عالٍ.

إذا تم استخدامه بانتظام ، فسيساعدك المحلل في نهاية المطاف على تحسين جودة الكود ، مما يسهل الحفاظ عليه. إصلاح الأخطاء بشكل منتظم وممارسة كتابة التعليمات البرمجية عالية الجودة سيجعلها أقل عرضة لنقاط الضعف في اليوم صفر. تمت مناقشة هذا الموضوع بمزيد من التفصيل في المقالة " كيف يمكن لـ PVS-Studio المساعدة في اكتشاف نقاط الضعف؟ ".

PVS-Studio هو الأكثر فعالية من حيث التكلفة عند استخدامه من قبل فرق من خمسة أعضاء وأكثر من ذلك. ويرد تقدير العائد على الاستثمار في المقال " PVS-Studio ROI ".

قد يكون دمج PVS-Studio في المشاريع التي طورها عدد من المتحمسين أمرًا غير عملي ، لكن حتى المشاريع الصغيرة يمكنها الاستفادة منه - خاصة وأننا نقدم خيارات ترخيص مجانية للطلاب والمطورين ذوي المصادر المفتوحة وما إلى ذلك.

سيقوم عملاؤنا الجدد عادة بشراء ترخيص لمدة عام واحد. عندما تنتهي صلاحيته ، يكونون سعداء بالفعل بقدرات محللنا وخدمة دعم المستخدم وسيجددون الترخيص لمدة عامين أو ثلاثة أعوام ، وهو أرخص بكثير من الترخيص لمدة عام. يمكنك طلب الأسعار وطلب المشورة بشأن الترخيص هنا .

كن عملائنا ، ودع PVS-Studio يجعل عملية التطوير الخاصة بك أكثر نضجًا ، وإصلاح الأخطاء ، ورمزك بشكل أفضل.

بدورنا ، سوف نقدم لك دعمًا سريعًا ومختصًا. سيتم طرح أسئلتك مباشرةً بواسطة المبرمجين الذين يقومون بتطوير الوحدات المعينة المعنية. هذا يضمن الحصول على إجابة حتى في المواقف الأكثر تعقيدًا. فيما يلي مثال واحد: " الإيجابيات الخاطئة في PVS-Studio: ما مدى عمق حفرة الأرنب ."

الرد على النقد

المبرمجون يكونون أحيانًا سلبيين حول فكرة تضمين تحليل الكود الثابت في عملية التطوير الخاصة بهم وانتقاد طريقة التحليل الثابت بشكل عام أو PVS-Studio بشكل خاص. مع بدء الحفر بشكل أعمق ، اتضح أن نقدهم لا أساس له من الصحة وهو ببساطة نتاج ترددهم في تغيير أي شيء في عملية التطوير القائمة. دعونا نرى الحجج النمطية لعدم تغيير الموقف الذي يلجأون إليه وما هو الخطأ في ذلك.

"التحليل الثابت سيستغرق بعض الوقت في عملك"

خارج السياق ، العبارة "التحليل الثابت ستتناول قدرًا من وقت العمل" صحيحة. يستغرق الأمر وقتًا طويلاً لدراسة إخراج التحذيرات من قبل المحلل بحثًا عن رمز مكتوب أو تم تعديله حديثًا. لكن هذه الفكرة يجب أن تستمر: "لكنها ستستغرق وقتًا أقل بكثير مما تتطلبه طرق اكتشاف الأخطاء الأخرى."

لماذا يعتقد الناس أن فحص تقرير محلل ثابت يستغرق وقتًا طويلاً؟

هؤلاء المبرمجون الذين لم يكونوا على دراية بأسلوب تحليل الشفرة يخلطون بين تشغيل الاختبار لمرة واحدة والاستخدام المنتظم. عند التشغيل لأول مرة ، سينتج أي محلل قائمة ضخمة من التحذيرات ، مع ارتفاع معدل الإيجابيات الخاطئة. يحدث هذا بسبب عدم تخصيص الأداة بعد. مع ضبط الإعدادات للوفاء باحتياجاتك المحددة ، لن ترى العديد من الإيجابيات الخاطئة إذا كنت تدير المحلل بانتظام. بمعنى آخر ، مع الاستخدام المنتظم ، ستكتشف معظم تشخيصات المحلل وجود عيوب حقيقية أو كود شم. عليك فقط أن تفعل التغيير والتبديل.

تتناول المقالة " معالجة الاعتراضات: التحليل الثابت جزءًا من وقت العمل ".

"المحللون الثابتون ينتجون ضوضاء أكثر من اللازم (أي الكثير من الإيجابيات الخاطئة)"

مرة أخرى ، يكون هذا البيان صحيحًا عندما لا تقوم بتخصيص الأداة بشكل صحيح. بمجرد تعديل إعدادات PVS-Studio حسب الحاجة ، يمكنك توقع انخفاض معدل الإيجابيات الخاطئة إلى 10-20٪. وهذا يعني أنه من بين كل خمسة تحذيرات ، سيشير أربعة إلى أخطاء أو تعليمات برمجية أصلية من المحتمل جدًا أن تصبح مصدر الأخطاء في المستقبل. يوضح المقال " خصائص محلل PVS-Studio بواسطة مثال مكتبات EFL الأساسية ، 10-15٪ من إيجابيات كاذبة " مثالًا على تخصيص المحلل.

مصدر آخر من المفاهيم الخاطئة هو إغراء تشغيل أكبر عدد ممكن من التشخيصات ، دون معرفة الغرض الدقيق منها. على سبيل المثال ، إذا قمت بتشغيل مجموعة قواعد MISRA ، التي تم تصميمها للأنظمة المضمنة ، عند التحقق من تطبيق Windows كلاسيكي ، فإن المحلل سيولد مئات الآلاف من التحذيرات ، ولن يكون أي منها مفيدًا لك. تعتبر التشخيصات غير الملائمة ضارة بشكل خاص عندما تبدأ في تشغيل الأداة فقط نظرًا لأنك قد تحصل على انطباع خاطئ عن قدراتها التشخيصية. المقال " كيفية التحقق بسرعة من التحذيرات المثيرة للاهتمام التي قدمها محلل PVS-Studio لرمز C و C ++؟ " سوف تساعدك على تجنب خيبة الأمل.

"دمج التحليل الثابت في عملية التطوير مكلف للغاية من حيث الجهد والوقت والمال"

يتضح هذا القلق بوضوح من خلال التعليق التالي:

لسوء الحظ ، لا يعتبر المحللون الثابتون أكثر من مجرد ألعاب. إنها مهمة تسعى إلى جعلها جزءًا من عملية عملك الروتينية ، وتتطلب تعيين بعض الموظفين لفحص نتائج التحليل وتصفيتها. أي محاولة لوضع هذا العبء على المطورين العاديين عادة ما تكون بلا جدوى.

هذا ليس فظيعا. هناك ثلاث ممارسات على الأقل لدمج التحليل الثابت بسلاسة حتى في المشروعات القديمة الكبيرة.

التمرين 1. "السقوط" ، وهو ما أوضحه جيدًا إيفان بونوماريف في مقالته " تقديم تحليل ثابت في هذه العملية ، لا تبحث فقط عن الأخطاء باستخدامه ".

التمرين 2. لمساعدة مستخدمينا على البدء بسرعة ، نوصي باستخدام " قاعدة الكبت ". باختصار ، الفكرة هي أن تقوم بتشغيل المحلل والحصول على تحذيرات متعددة. نظرًا لأن المشروع ظل قيد التطوير لسنوات عديدة وما زال حيا ومتطورًا ومربحًا ، فمن غير المحتمل أن تحصل على العديد من التحذيرات التي تشير إلى عيوب حرجة. بمعنى آخر ، تم إصلاح معظم الأخطاء الهامة بالفعل باستخدام وسائل أخرى - أكثر تكلفة - أو استجابة لتعليقات المستخدمين. في هذه الحالة ، بغض النظر عن الأخطاء التي تم العثور عليها أثناء الفحص الأول ، يمكن اعتبارها دينًا تقنيًا ، وسيكون من غير المعقول التعجيل بإصلاحه على الفور.

يمكنك إخبار PVS-Studio بمعالجة هذه التحذيرات على أنها غير ذات صلة (وبالتالي تأجيل حل الدين الفني إلى وقت لاحق) وعدم إظهارها مرة أخرى. سيقوم المحلل بإنشاء ملف خاص لتخزين المعلومات حول الأخطاء غير ذات الصلة حاليًا وسيتم إخراج التحذيرات فقط لرمز مكتوب أو تم تعديله حديثًا. آلية ذكية جدا. على سبيل المثال ، إذا أضفت سطرًا فارغًا في بداية بعض ملفات .cpp ، فسوف يفهم المحلل أن هذا الخط لا يحدث أي فرق ، ويلتزم الصمت. يمكن أن يكون الملف قمع التحكم الإصدار. إنه كبير ، لكن لا يهم لأنك لا تحتاج إلى التحكم في الإصدار كثيرًا.

بعد ذلك ، سيحصل كل مبرمج على فريقك فقط على التحذيرات التي تحدثها الشفرة المكتوبة حديثًا أو المعدلة. بدءًا من اليوم التالي ، ستتمكن من استخدام أداة التحليل كجزء من عملك الروتيني. بالنسبة للديون الفنية ، ستتمكن من الوصول إليها لاحقًا وتصحيح الأخطاء تدريجياً وضبط إعدادات المحلل حسب الحاجة.

الممارسة 3. يمكنك تفويض مهمة إعداد ودمج PVS-Studio لفريقنا عن طريق إبرام عقد معنا. تم توضيح مثال واحد لهذه الممارسة في المقالة " كيف قام فريق PVS-Studio بتحسين رمز محرك غير واقعي ".

"لقد أدارنا المحلل لكن لم نجد شيئًا يثير الاهتمام"

هذا السيناريو ممكن تمامًا ، لكنه لا يزال لا يعني أن المحلل لن يكون مفيدًا. المشكلة هي أنه تم بالفعل اكتشاف الأخطاء وإصلاحها باستخدام وسائل أخرى أكثر تكلفة. إنه يشبه تغذية نص تم فحصه بالفعل بواسطة مجموعة من المراجعين إلى Microsoft Word لمعرفة ما إذا كان التدقيق الإملائي المدمج به قد يجد شيئًا أم لا. قد تجد بعض الأخطاء ، إن وجدت على الإطلاق ، لكن هذا لا يعني أن التدقيق الإملائي الخاص بـ Word غير مجدي عند كتابة نصوص جديدة.

تمت مناقشة هذا الموضوع بمزيد من التفصيل في مقالة " فلسفة تحليل الشفرة الثابتة: لدينا 100 مطور ، وجد المحلل عددًا قليلاً من الأخطاء ، هل محلل عديم الفائدة؟ ".

"محلل ثابت هو أداة باهظة الثمن. من الأفضل أن نوظف مبرمجاً / مختبراً إضافياً »

ما تقوله هذه الحجة حقًا هو أن الشخص لا يريد تغيير أي شيء. بعد كل شيء ، كان فريقهم ينمو ويوظف مبرمجين جدد واختبارًا لبعض الوقت بالفعل ، لكن هذا لم يساعد في تحقيق عملية تطوير أكثر نضجًا. ومع ذلك ، لا يزال يتعين علينا توضيح هذه الحجة.

أولاً ، إن توظيف شخص آخر للبحث عن الأخطاء يعد أكثر تكلفة من شراء محلل ثابت. ما عليك سوى حساب الرواتب السنوية للموظف الجديد وإضافة الضرائب والنفقات على إنشاء مساحة عمل جديدة. بالنظر إلى الأرقام الناتجة ، فإن الجدال حول كون محلل البرامج باهظ التكلفة لا يبدو حجة على الإطلاق. إلى جانب ذلك ، فإن المحلل الثابت ، على عكس البشر ، لن يأخذ إجازة أو يذهب في إجازة مرضية أو يترك الشركة تمامًا. بالنسبة لفريق كبير ، على سبيل المثال ، 100 شخص ، سيتعين عليك تعيين موظف واحد ولكن عدة موظفين جدد لتحقيق أي نتيجة ملحوظة. في هذه الحالة ، يصبح شراء محلل ثابت حلاً أكثر ملاءمة.

ثانياً ، يتم تحقيق أفضل نتيجة من خلال التآزر بين مختلف تقنيات اكتشاف الأخطاء المستخدمة في توليفة. يتم تشخيص بعض الأخطاء بشكل أفضل من خلال اختبار الوحدة ، والبعض الآخر من خلال الاختبار اليدوي ، وهلم جرا. تخيل وجود 10 مبرمجين يعملون في مشروع ، مع الكثير من اختبارات الوحدة ولكن ليس من خلال اختبار واحد. لا يشعر المستخدمون بالرضا عن جودة المشروع ، لذلك يحدث لك أن توظف مختبراً ، لكنك لا تفعل ذلك لأنه "من الأفضل أن نوظف مبرمجًا إضافيًا ، فليكن هناك المزيد من اختبارات الوحدات!" يمكن أن يطلق عليه قرار حكيم ، أليس كذلك؟ في هذا السيناريو ، من الواضح أن عملية ضمان الجودة واحدة ذات أرجل ولن تكسب سوى بإضافة اختبار يدوي. وينطبق الشيء نفسه على التحليل الثابت.

"التحليل الديناميكي أفضل من التحليل الثابت"

يتم تشخيص بعض الأخطاء بشكل أفضل بواسطة أجهزة التحليل الثابتة ، والبعض الآخر بواسطة أجهزة التحليل الديناميكية. هذه الأنواع من الأدوات تكمل بعضها البعض ، لذلك ليس عليك اختيار واحدة فقط.

على سبيل المثال ، لا يمكن للمحللات الديناميكية اكتشاف رمز يتعذر الوصول إليه والعديد من الأخطاء التي تسببها الأخطاء المطبعية. بعض أنواع الأخطاء التحليل الديناميكي لديه صعوبة في العثور على وقت موصوف في المقال " التحقق من رمز Valgrind محلل ديناميكي من قبل محلل ثابت ".

"اختبار الوحدة أفضل من التحليل الثابت"

إذا أردت الاختيار بين كتابة اختبارات الوحدة واستخدام التحليل الثابت ، فأنا أقول أن الاختبارات أكثر أهمية وقيمة. لكن ليس عليك أن تختار. يجب عليك استخدام كل من وحدة الاختبار والتحليل الثابت. هذه التقنيات تعمل بشكل جيد للغاية معا.

فيما يلي الحجج لاستخدام التحليل الثابت مع اختبار الوحدة:

لا يتم اختبار الاختبارات نفسها وغالبًا ما تحتوي على أخطاء. في مقالاتنا ، نعرض الكثير من الأمثلة على الأخطاء الموجودة في اختبارات الوحدة في المشروعات الحقيقية. يمكن أن يكتشف التحليل الثابت الأخطاء في الاختبارات ، والتي بدورها يمكنها العثور على الأخطاء في الرمز الرئيسي.
من الصعب تغطية الشفرة بالكامل من خلال الاختبارات ، خاصة الأجزاء التي تتعامل مع الاستثناءات. على عكسهم ، يقوم المحللون الثابتون بفحص الكود بأكمله.
يصعب للغاية اكتشاف بعض الأخطاء ، إن أمكن على الإطلاق ، من خلال اختبارات الوحدة. V597 (CWE-14) هو أحد هذه الأمثلة.
تظهر بعض الأخطاء فقط عندما يعمل البرنامج مع كميات كبيرة من البيانات ، لذلك من غير العملي محاكاة مثل هذه المواقف في اختبارات الوحدة. مثال واحد هو تجاوز سعة متغير 32 بت في برنامج 64 بت ( V108 ، V127 ).
عندما لا ينجح الاختبار ، يمكن العثور على الخطأ بسهولة أكبر وبسرعة عن طريق تشغيل أداة التحليل الثابتة بدلاً من تصحيح الأخطاء. بالتأكيد ، ستجد اختبارات الوحدة المزيد من الأخطاء ولكن عندما يمكنك التقاطها باستخدام تقنية أرخص (أي التحليل الثابت) ، لماذا لا تفعل ذلك؟
نجد أكوام من الحشرات في مشاريع مختلفة. تمت تغطية العديد منهم باختبارات شديدة ، ولكن ، كما ترون ، فإنها لا تساعد كثيرًا. لذلك ليس هناك سبب يمنعك من اعتماد تحليل ثابت بالإضافة إلى اختبار الوحدة لتحسين جودة وموثوقية الشفرة.

"يمكن للمترجمين المعاصرين المجانية العثور على نفس الأخطاء التي يمكن لـ PVS-Studio"

من المؤكد أن المترجمين يتطورون ويحصلون على تحذيرات جديدة ، والتي يمكنها اكتشاف الأخطاء. لكن لا يمكنك توقع الكثير من المجمعين بالمقارنة مع الحلول الاحترافية الخاصة مثل PVS-Studio.

أسباب للذهاب إلى PVS-Studio:

دعم المستخدم الفعال
بنية تحتية متطورة للغاية (التكامل مع المنتجات الأخرى)
قدرات التشخيص قوية

السببان الأوليان يكفيان بالفعل لتوجيه المقياس نحو اختيار PVS-Studio ، لكن دعنا نتحدث عن التشخيص أيضًا. نعمل باستمرار على تحسين منتجاتنا للبقاء في مقدمة البائعين الآخرين. على سبيل المثال ، يمكن لأدواتنا اكتشاف خلل مثير للاهتمام تم وصفه في المقالة " 31 فبراير ".

مع العلم أن كل ما ذكر أعلاه لا يكفي لجعل المتشككين يغيرون رأيهم ، فإننا نتحقق من المترجمين بين الحين والآخر لإظهار أن لديهم أيضًا أخطاء ، والتي يمكن لـ PVS-Studio اكتشافها:

PS

إذا كنت لا تزال تشك فيما إذا كان عليك استخدام PVS-Studio ، فما عليك سوى إلقاء نظرة على هذه القائمة من الأخطاء التي عثر عليها في العديد من المشاريع .

لماذا يجب عليك اختيار محلل ثابت PVS-Studio لدمجه في عملية التطوير الخاصة بك