كيفية التعامل مع مخرجات المحلل الثابت

Question

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

الخيارات التي ناقشناها حتى الآن هي

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

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

وفي كلتا الحالتين، فإن جلب الكود الخاص بنا إلى حالة يمكن أن يكون فيها المحلل الثابت أداة مفيدة بالنسبة لنا يبدو مهمة ضخمة.

إذًا كيف يمكن العمل مع المحلل الثابت دون إيقاف جهود التطوير الحالية بشكل كامل؟

Answer 1

أول ما يجب فعله هو تعديل من إعدادات التحليل الخاصة بك ؛ ربما تركك دعم الغطاء مع تكوين عام إلى حد ما.

• فرز عينة تمثيلية من العيوب ، وإذا لم يكن المدقق ينتج إشارة أكثر بكثير من الضوضاء ، فقم بإيقاف تشغيله في الوقت الحالي. (معظم مدققات الغطاء جيدة ، لكن لا أحد مثالي ، ويبدو أنك بحاجة إلى القيام ببعض الأولويات القاسية.)
  • على المدى الطويل ، قم بإعادة تشغيل بعض هؤلاء المدققين ، لكن ضع علامة عليها في تقريرك بأولوية منخفضة. (هذا أصعب مما ينبغي أن يكون ؛ لقد جادلت منذ فترة طويلة أن الغطاء يحتاج إلى قراءة بعض الأوراق على تصنيف العيوب من قبل شخص يدعى داوسون إنجلر. :-)
  • في المدى الأطول ، جرب الداما المعطلة بشكل افتراضي ؛ يجد بعضهم أخطاء مثيرة للإعجاب. وتحذيرات التحليل مفيدة بشكل مدهش ، على الرغم من أنك تحتاج إلى إيقاف بعض تلك الزائفة.
• كن واقعيًا بسخرية حول أي جزء من قاعدة قاعدة الشفرة الخاصة بك ستحددها قريبًا. استخدم مكونات لتخطي التحليل على الكود الذي لن تقوم بإصلاح العيوب فيه ، على الأقل في الوقت الحالي. (على سبيل المثال ، من الناحية النظرية ، إذا كان منتجك يتضمن رمز الطرف الثالث ، فأنت مسؤول عن جودته ويجب تصحيح الأخطاء فيه. في الممارسة العملية ، نادراً ما يتم إصلاح هذه الأخطاء. سيكون معدل إيجابي مرتفعًا.)
  • يعد إعداد المكونات والإقصاء أمرًا صعبًا ، ولكن بمجرد الانتهاء من ذلك ، فإنها تعمل بشكل جيد-كان لدى واحد من regexes المظهر السلبي أكثر من مائة انفصال.
  • تساعد المكونات أيضًا في تعيين مسؤولية فردية عن العيوب ، والتي وجدت أنها ضرورية لإصلاحها.
• قم بإعداد تقرير عن عيوب جديدة فقط ، وجعل الناس يشاهدون عنوان URL هذا. العيوب الجديدة في رمز نشط ، ومن الأسهل البدء مع سياسة تحذيرات جديدة.

اسمحوا لي أن أنتهي مع اثنين من إخلاء المسئولية:

• قد ترغب في إعادة توجيه هذا السؤال في منتدى دعم التغطية (http://forums.coverity.com/) ، وهو ليس نشطًا للغاية ، لكن حيث لا داعي للقلق بشأن انتهاك NDA. لدي قائمة هناك من الداما التي وجدتها تستحق التمكين.

• أفعل هذا من أجل لقمة العيش ، وربما تريد توظيفنا (http://codeintegritysolutions.com/) ؛ أنا أتحدث عن هذا الموضوع في ستانفورد اليوم. استئجار مستشار للقيام بالضبط أمر منطقي ؛ إن وجود شخص خارج الشركة يقوم بالثلاثية أمر أصعب. إن وجود شخص غريب يقوم بالإصلاحات أكثر صعوبة ؛ التعلم من أخطائك هو أكثر أهمية من إصلاحها.

  • لقد قمت بتوسيع هذا قليلاً مع بعض أجزاء حديث ستانفورد الخاص بي ، لمدونة الشركات لدينا: http://codeintegrity.blogspot.com/2010/01/handling-embarrassment-of-riches.html.

Answer 2

يوم واحد في الأسبوع: قم بتشغيل التحليل ؛ اختيار 100 تحذيرات مزعجة. أصلحهم؛ قم بإيقاف تشغيل التحليل. باختصار: لا داعي للذعر. الرمز الخاص بك يعمل كما هو (أليس كذلك؟) ؛ العمل من خلال التحذيرات في قطع الحجم.

إذا وجدت أن نفس أنواع التحذيرات تحافظ على الظهور (ممارسات الترميز السيئة) ، فقم بتثقيف فريقك لتجنبها في المستقبل.

لقد فعلت ذلك مع قاعدة رمز قديمة: سأذهب في الصباح الباكر (قبل بقية الفريق) ، وأعمل على مستوى مستوى التحذير/التحليل على المترجم ، وإصلاح بعض التحذيرات ثم أعيدها إلى الإعدادات الافتراضية.

Answer 3

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

Answer 4

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

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

وكن لطيفًا معهم - إنه عمل قحفي ، لذا اجعل أي شيء آخر يمكنك أن يسامه.

Answer 5

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

Answer 6

جرب محللون ثابتون آخرون. اعتدت أن أعمل مع اختبار Parasoft C ++ وكان لديه طريقة مريحة لتصفية التحذيرات وفقًا لشدته.

Answer 7

هل هذا يعني أن لديك مشاكل في تخصيص احتياجاتك؟
مثل

"" تحليل قابل للتخصيص

يوفر التحليل الثابت Coverity القدرة على ضبط التحليلات عن طريق تعديل عدد المدققين الذين تم نشرهم ، أو الإعدادات الخاصة بمتحقق فردي ، مثل عتبة إزالة مؤشرات NULL. تتيح القدرة على تكوين تغطية كتلة رمز معينة ، أو تطبيق ، للمطورين تحديد مستوى الأداء الأنسب لتطبيقهم ، ويؤدي إلى نتائج أكثر دقة وموثوقية. تتيح لك مجموعة تطوير برامج Coverity اكتشاف أنواع عيب فريدة من نوعها في رمز C و C ++ عن طريق إنشاء مداخن مخصصة. هذا بالإضافة إلى إنشاء مدققين مخصصين لإيجاد التزامن ومعالجة الاستثناءات وغيرها من القضايا الحرجة. ""
http://www.coverity.com/products/static-analysis.html

Answer 8

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

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

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