💜 😓 🕌 أسباب إدخال محلل الكود الثابت PVS-Studio في عملية التطوير 🥉 👒 🖼️

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

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

مشاريع البرمجيات في عملية تطويرها أصبحت أكثر وأكثر. الأمثلة على ذلك:

Linux kernel 1.0.0: 176،000 سطر من التعليمات البرمجية
Linux kernel 5.0: 26،000،000 line of code
Photoshop 1.0: 128000 سطر من التعليمات البرمجية
Photoshop CS 6: 10،000،000 سطر من التعليمات البرمجية

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

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

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

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

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

PVS استوديو

نوصي بتنفيذ محلل الكود الثابت PVS-Studio الذي قمنا بتطويره في عملية التطوير. يعمل المنتج على أنظمة 64 بت على أنظمة Windows و Linux و macOS ويمكنه تحليل الشفرة المصممة لأنظمة 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. PVS-Studio ، كونه متصلاً كمكون إضافي لبرنامج SonarQube ، هو مصدر إضافي لرسائل التشخيص.

تم وضع سيناريوهات تكامل مختلفة في 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 Core Libraries ، 10-15٪ من الإيجابيات الخاطئة ".

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

"إدخال تحليل ثابت في عملية التطوير أمر صعب للغاية وطويل ومكلف"

جيد جدًا ، تنعكس هذه المخاوف في هذا التعليق:

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

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

النهج الأول. "طريقة السقاطة" ، والتي يتحدث بها إيفان بونوماريف جيدًا في تقريره " تحليل الكود الثابت المستمر ".

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

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

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

النهج الثالث. يمكنك إبرام عقد معنا وتفويض فريقنا لعمل إعداد ودمج التحليل الثابت. مثال على هذه الممارسة: " كيف قام فريق PVS-Studio بتحسين كود Unreal Engine ."

"أطلقنا المحلل ولم نجد أي شيء مثير للاهتمام"

هذا ممكن تمامًا ، لكن هذا لا يعني أن المحلل لن يكون مفيدًا. الشيء هو أنه تم تصحيح الأخطاء عن طريق أساليب أكثر تكلفة. هذه هي الطريقة التي تأخذ بها نص كتاب ، قرأه بالفعل العديد من المراجعين ، ومعرفة ما يمكن لمدقق الإملاء المدمج في 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 ، فراجع ما هي الأخطاء وفي المشاريع التي تمكنا من اكتشافها .

روابط مفيدة

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

أسباب إدخال محلل الكود الثابت PVS-Studio في عملية التطوير