عند التحدث إلى الأشخاص في المؤتمرات وفي التعليقات على المقالات ، نواجه الاعتراض التالي: التحليل الثابت يقلل من الوقت لاكتشاف الأخطاء ، ولكنه يأخذ وقت المبرمجين ، مما يلغي فوائد استخدامه وحتى يبطئ عملية التطوير. دعنا نستعيد هذا الاعتراض ونحاول إظهار أنه لا أساس له من الصحة.
العبارة "التحليل الثابت ستأخذ جزءًا من وقت العمل" المأخوذة من السياق صحيحة. من المؤكد أن الأمر يستغرق بعض الوقت لمراجعة تحذيرات المحلل بانتظام ، والتي يتم إصدارها لرمز جديد أو معدل. ومع ذلك ، يجب أن نستمر في الفكرة: لكن الوقت المستغرق في ذلك أقل بكثير من الوقت اللازم للعثور على الأخطاء بطرق أخرى. من الأسوأ معرفة الأخطاء من المستخدمين.
يمكن أن تكون اختبارات الوحدة تشبيهًا جيدًا هنا. تستغرق اختبارات الوحدة أيضًا وقتًا من المطورين ، ولكن هذا ليس سبب عدم استخدامها. فوائد كود أكثر أمانا من نوعية أفضل عند استخدام اختبارات الوحدة تفوق تكلفة كتابتها.
تشبيه آخر: تحذيرات مترجم. يعد هذا موضوعًا وثيقًا بشكل عام ، حيث يمكن اعتبار تحذيرات أدوات التحليل الثابت امتدادًا لتحذيرات برنامج التحويل البرمجي إلى حد ما. بطبيعة الحال ، عندما يرى مبرمج تحذيراً مترجمًا ، فإنه يمضي بعض الوقت في التعامل معه. عليه إما تغيير الكود أو قضاء بعض الوقت بوضوح في قمع التحذيرات ، على سبيل المثال ، باستخدام # pragma. ومع ذلك ، لم يكن الالتزام هذه المرة سبب تعطيل تحذيرات برنامج التحويل البرمجي. وإذا فعل شخص ما ذلك ، فسيتم تفسيره بشكل لا لبس فيه من قبل الآخرين على أنه شاهد غير محترف.
ومع ذلك ، من أين يأتي الخوف من إضاعة الوقت للتحذيرات من محللات الكود الثابت؟
الجواب بسيط جدا. المبرمجون الذين لم يكونوا على دراية بهذه المنهجية يخلطون بين الإطلاقات التجريبية والاستخدام المنتظم. في الجولة الأولى ، يقدم أي محلل قائمة ضخمة من التحذيرات ، والتي هي أمر مخيف للنظر في. السبب هو أن المحلل لم يتم تكوينه بعد. في حين أن محلل تكوين يصدر عدد صغير من ايجابيات كاذبة تستخدم بانتظام. بمعنى آخر ، تشير معظم التحذيرات إلى وجود عيوب حقيقية أو رائحة الكود. من المهم فقط القيام بهذا التكوين. هذه هي الحيلة التي تحول محلل ثابت من شر يضيع الوقت إلى صديق ومساعد.
سيقوم أي محلل ثابت أولاً بإصدار العديد من الإيجابيات الخاطئة. هناك العديد من الأسباب لذلك ، وهذا الموضوع يستحق مقالة منفصلة. بطبيعة الحال ،
يحارب كل من مطوري التحليل الآخرين وفريقنا ضد الإيجابيات الخاطئة. ولكن لا يزال سيكون هناك العديد من التحذيرات ، إذا كنت تأخذ وتشغيل المحلل في مشروع لأول مرة. بالمناسبة ، نفس الموقف مع تحذيرات مترجم. لنفترض أن لديك مشروعًا كبيرًا كنت تقوم ببنائه دائمًا ، على سبيل المثال ، باستخدام برنامج التحويل البرمجي Visual C ++. دعنا نقول ، لقد تحول المشروع بأعجوبة إلى أنه تم تجميعه وتجميعه باستخدام دول مجلس التعاون الخليجي. ومع ذلك ، سوف تحصل على مجموعة من التحذيرات من دول مجلس التعاون الخليجي. الناس الذين عانوا من تغيير المترجمين في مشروع كبير يفهمون ما أتحدث عنه.
ومع ذلك ، لا أحد يجبرك على الحفر باستمرار في أكوام من التحذيرات بعد تغيير المترجم أو بعد تشغيل المحلل. الخطوة التالية الواضحة هي إعداد مترجم أو محلل. أولئك الذين يقولون إن "تحليل التحذيرات يستهلك الكثير من الوقت" يقيمون مدى تعقيد تبني الأداة ، ولا يفكرون إلا في كل هذه التحذيرات التي يجب التغلب عليها في البداية ، لكنهم لا يفكرون في الاستخدام المنتظم غير المستعجل.
إعداد المحللين ، وكذلك المترجمين ، ليس بالأمر الصعب والكثافة التي يحتاجها العاملون مثلما يحلو للمبرمجين. إذا كنت مديرًا ، فلا تستمع إليهم. انهم مجرد كسول. يمكن للمبرمج أن يقول بفخر كيف كان يبحث عن خطأ عثر عليه المختبر / العميل لمدة 3 أيام. وهذا جيد بالنسبة له. ومع ذلك ، من وجهة نظره ، من غير المقبول قضاء يوم واحد في إعداد الأداة ، وبعد ذلك سيتم اكتشاف مثل هذا الخطأ قبل دخوله إلى نظام التحكم في الإصدار.
نعم ، سوف تكون ايجابيات كاذبة موجودة بعد الإعداد. لكن عددهم مبالغ فيه. من الممكن تمامًا إعداد محلل بحيث تكون النسبة المئوية للإيجابيات الخاطئة 10٪ -15٪. بمعنى أنه بالنسبة لـ 9 عيوب تم العثور عليها ، سيتطلب تحذير واحد فقط قمعًا كإجراء خاطئ. فأين هو "مضيعة للوقت" هنا؟ في الوقت نفسه ، 15 ٪ قيمة حقيقية جدا. يمكنك قراءة المزيد عنها في هذا
المقال .
هناك شيء آخر متبقي. قد يعترض المبرمج على:
حسنًا ، دعنا نقول أن عمليات التحليل الثابتة المنتظمة فعالة حقًا. لكن ماذا أفعل بالضوضاء التي أحصل عليها في المرة الأولى؟ في مشروعنا الكبير ، لن نتمكن من إعداد الأداة ليوم واحد مُعد. مجرد إعادة تجميع للتحقق من الدفعة التالية من الإعدادات يستغرق عدة ساعات. لسنا مستعدين لقضاء أسبوعين على ذلك.وهذه ليست مشكلة ، ولكن محاولة لإيجاد سبب لعدم تقديم شيء جديد. بالطبع ، في مشروع كبير ، كل شيء صعب دائمًا. لكن أولاً ، نحن نقدم الدعم ونساعد على دمج PVS-Studio في عملية التطوير. وثانيا ، ليس من الضروري البدء فوراً في فرز جميع التحذيرات.
إذا كان تطبيقك يعمل ، فإن الأخطاء الموجودة هناك ، ليست مهمة للغاية وربما تعيش في كود نادر الاستخدام. تم بالفعل العثور على أخطاء واضحة خطيرة وإصلاحها باستخدام طرق أبطأ وأكثر تكلفة. سأكتب عن ذلك أدناه في
المذكرة . هذا ليس ما هو مهم للغاية الآن. ليس هناك فائدة من إجراء تعديلات ضخمة في الكود ، مما يؤدي إلى تصحيح الكثير من الأخطاء البسيطة. مع مثل هذا إعادة البناء الكبيرة ، من السهل كسر شيء ما ، وسيكون الضرر أكثر من جيد.
فمن الأفضل أن تنظر التحذيرات الموجودة الديون الفنية. يمكنك العودة إلى الديون في وقت لاحق والعمل تدريجيا مع التحذيرات القديمة. باستخدام آلية منع التحذيرات الجماعية ، يمكنك البدء في استخدام PVS-Studio بسرعة في مشروع كبير. فيما يلي وصف موجز لما يحدث:
- يمكنك استبعاد الدلائل المكررة بشكل واضح (مكتبات الجهات الخارجية) من التحليل. من الأفضل أن تفعل ذلك في البداية من أجل تقليل وقت التحليل.
- يمكنك تجربة PVS-Studio والتحقيق في التحذيرات الأكثر إثارة للاهتمام . يعجبك النتائج ، وتظهر الأداة للزملاء وأصحاب العمل. يقرر الفريق البدء في استخدامه بانتظام.
- المشروع قيد الفحص. يتم تعطيل جميع التحذيرات المكبوتة باستخدام آلية القمع الشامل. بمعنى آخر ، تعتبر جميع التحذيرات التي لديك في هذه المرحلة بمثابة دين تقني يمكن مراجعته لاحقًا.
- الملف الناتج مع التحذيرات المكبوتة يدخل نظام التحكم في الإصدار. هذا الملف كبير ، لكن هذا جيد. تقوم بهذه الإجراءات مرة واحدة فقط (أو على الأقل نادراً ما). والآن سيكون لدى جميع المطورين هذا الملف.
- يرى جميع المطورين الآن تحذيرات مرتبطة فقط بالرمز الجديد أو المعدل. من تلك اللحظة فصاعدا ، يبدأ الفريق في الاستفادة من التحليل الثابت. بعد ذلك ، قمت بإعداد المحلل بالتدريج والتعامل مع الديون الفنية.
بالمناسبة ، نظام التخزين للتحذيرات غير المثيرة للاهتمام ذكي للغاية. يتم حفظ علامات التجزئة للخط مع وجود خطأ محتمل ، بالإضافة إلى السطر السابق والخط التالي. نتيجة لذلك ، إذا أضفت سطرًا في بداية أحد الملفات ، فلن يضيع شيء وسيبقى المحلل صامتًا على الكود ، والذي يعتبر دينًا تقنيًا.
آمل ، تمكنت من تبديد أحد الأفكار المسبقة حول التحليل الثابت. تعال ، قم
بتنزيل وتجربة محلل الكود الثابت PVS-Studio. سيكتشف العديد من الأخطاء في المراحل المبكرة ويجعل الكود أكثر موثوقية وأفضل بشكل عام.
مذكرةأثناء تطوير أي مشروع ، تظهر أخطاء جديدة باستمرار وتصبح ثابتة. الأخطاء غير الصالحة "تسوية" في الكود لفترة طويلة ، ومن ثم يمكن اكتشاف الكثير منها عند تطبيق تحليل الكود الثابت. هذا يعطي في بعض الأحيان انطباعًا خاطئًا بأن المحللين الاستاتيكيين لا يجدون سوى بعض الأخطاء غير المفيدة في أجزاء من الكود التي نادراً ما تستخدم. حسنًا ، هذا صحيح - في حالة استخدام المحلل بطريقة غير صحيحة وتشغيله فقط من وقت لآخر ، على سبيل المثال ، قبل وقت قصير من الإصدار. المزيد عن هذا الموضوع مكتوب
هنا . نعم ، نحن أنفسنا نقوم بفحص لمرة واحدة لمشاريع مفتوحة المصدر عند كتابة المقالات. لكن لدينا غرض مختلف. نحن نركز على إظهار قدرات محلل الكود لاكتشاف العيوب. بشكل عام ، هذه المهمة ليس لها علاقة بتحسين جودة رمز المشروع وتقليل تكلفة إصلاح الأخطاء.
روابط إضافية- PVS-Studio ROI .
- لماذا التحليل الثابت يمكن تحسين C ++ معقدة Codebase .
- إيفان بونوماريف. قدّم تحليلًا ثابتًا في هذه العملية ، لا تبحث فقط عن الأخطاء باستخدامه .