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