🥄 👨🏾‍🎓 ♍️ قدّم تحليلًا ثابتًا في هذه العملية ، لا تبحث فقط عن الأخطاء باستخدامه 💤 🍪 🕵️

هذه المقالة هي ترجمة معتمدة للنشر الأصلي . تمت الترجمة بمساعدة عينية من PVS-Studio. شكرا يا شباب!

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

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

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

اسئلة (المصدر: ويكيبيديا ).

ما محللون ثابت لن تكون قادرة على القيام به

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

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

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

التحليل الثابت ليس بحثًا عن الأخطاء

فيما يلي استنتاج يأتي مما سبق: التحليل الثابت ليس الطريقة لتقليل عدد العيوب في البرنامج. سأغامر بالمطالبة بما يلي: بعد التقديم لأول مرة على مشروعك ، ستجد أماكن "مسلية" في الكود ، ولكن على الأرجح لن تجد أي عيوب تؤثر على جودة برنامجك.

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

هل هذا يعني أنه ليس من الضروري تطبيق التحليل الثابت؟ بالطبع لا! يجب تطبيقه لنفس السبب الذي قد ترغب في التحقق من كل كلمة مرور جديدة به في قائمة كلمات المرور غير الآمنة.

التحليل الثابت أكثر من البحث عن الأخطاء

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

فحص لنمط الترميز بالمعنى الأوسع لهذه الكلمة. يتضمن كلاً من التحقق من التنسيق والبحث عن استخدام الأقواس الفارغة / غير الضرورية ، وتحديد قيم العتبات للمقاييس مثل عدد من الخطوط / التعقيد السيكلومي لطريقة وما إلى ذلك - كل الأشياء التي تعقد إمكانية قراءة التعليمات البرمجية وإمكانية صيانتها. في Java ، يمثل Checkstyle أداة مع هذه الوظيفة ، في Python - flake8 . وعادة ما تسمى هذه البرامج "linters".
ليس فقط رمز قابل للتنفيذ يمكن تحليله. يمكن لمصادر مثل ملفات JSON و YAML و XML و .properties (ويجب)! أن يتم التحقق من صحتها تلقائيًا. السبب في ذلك هو أنه من الأفضل معرفة حقيقة أن هيكل JSON ، على سبيل المثال ، قد تم كسره بسبب علامات الاقتباس غير المزاوجة في المرحلة المبكرة من الفحص الآلي لطلب السحب أكثر من أثناء تنفيذ الاختبارات أو في وقت التشغيل ، هو؟ هناك بعض الأدوات ذات الصلة ، على سبيل المثال ، YAMLlint ، JSONLint و xmllint .
التجميع (أو تحليل لغات البرمجة الديناميكية) هو أيضًا نوع من التحليل الثابت. عادةً ، يمكن للمترجمين إصدار تحذيرات تشير إلى مشاكل في جودة الكود المصدري ، ويجب عدم تجاهلها.
في بعض الأحيان يتم تطبيق التصنيف ليس فقط على التعليمات البرمجية القابلة للتنفيذ. على سبيل المثال ، إذا كان لديك وثائق بتنسيق AsciiDoctor ، ثم في عملية تجميعها في HTML / PDF ، يمكن لـ AsciiDoctor ( Maven plugin ) إصدار تحذيرات ، على سبيل المثال ، على الروابط الداخلية المعطلة. هذا سبب مهم لعدم قبول طلب السحب مع تغييرات الوثائق.
التدقيق الإملائي هو أيضًا نوع من التحليل الثابت. أداة aspell قادرة على التحقق من الهجاء ليس فقط في الوثائق ، ولكن أيضًا في شفرة المصدر للبرامج (التعليقات والحرف اليدوية) بلغات البرمجة المختلفة بما في ذلك C / C ++ و Java و Python. خطأ إملائي في واجهة المستخدم أو الوثائق هو أيضا عيب!
تمثل اختبارات التكوين فعلًا شكلاً من أشكال التحليل الثابت ، حيث إنها لا تنفذ شفرة المصدر أثناء عملية تنفيذها ، على الرغم من أن اختبارات التكوين يتم تنفيذها pytest وحدة pytest .

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

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

خط أنابيب التسليم كمرشح متعدد المراحل وتحليل ثابت كمرحلة أولى

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

تحليل ثابت
تجميع
اختبارات الوحدة
اختبارات التكامل
اختبارات واجهة المستخدم
التحقق اليدوي

لا يتم تمرير التغييرات المرفوضة في المرحلة N من خط الأنابيب في المرحلة N + 1.

لماذا ذلك وليس غير ذلك؟ في جزء من خط الأنابيب ، الذي يتعامل مع الاختبار ، يتعرف المختبرون على هرم الاختبار المعروف:

اختبار الهرم. المصدر: مقالة مارتن فاولر.

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

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

مرشح متعدد المراحل. المصدر: ويكيميديا كومنز

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

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

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

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

مقدمة في مشروع قديم

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

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

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

فيما يلي الطرق المعروفة لإدخال بوابات الجودة:

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

اسئلة

يعمل بالطريقة التالية:

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

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

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

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

 celesta-sql: checkstyle: 434 spotbugs: 45 celesta-core: checkstyle: 206 spotbugs: 13 celesta-maven-plugin: checkstyle: 19 spotbugs: 0 celesta-unit: checkstyle: 0 spotbugs: 0

في أي نظام CI متقدم ، يمكن تنفيذ "السقاطة" لأي أدوات تحليل ثابتة ، دون الاعتماد على المكونات الإضافية وأدوات الطرف الثالث. يصدر كل محلل تقريره بنسق بسيط أو بتنسيق XML ، وسيتم تحليله بسهولة. الشيء الوحيد الذي يجب القيام به بعد ذلك هو كتابة المنطق المطلوب في سيناريو CI. يمكنك إلقاء نظرة خاطفة ونرى هنا أو هنا كيف يتم تنفيذها في مشاريعنا المصدر على أساس جنكينز و Artifactory. يعتمد كلا المثالين على مكتبة ratchetlib : طريقة countWarnings() بالطريقة المعتادة تقوم بحساب علامات xml في الملفات التي تم إنشاؤها بواسطة Checkstyle و Spotbugs ، compareWarningMaps() تلك السقاطة ، compareWarningMaps() خطأ في الحالة ، إذا كان عدد التحذيرات في أي من الفئات في ازدياد.

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

أهمية إصلاح نسخة محلل

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

الاستنتاجات

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

المراجع

تسليم مستمر
أليكسي كودريافتسيف: تحليل البرنامج: هل أنت مطور جيد؟ تقرير عن طرق التحليل المختلفة من التعليمات البرمجية ، وليس فقط ثابت!

مقتطفات من مناقشة المقال الأصلي

يفغيني ريجكوف

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

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

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

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

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

إيفان بونوماريف
يفغيني ، شكراً جزيلاً على المراجعة الإعلامية للمقال! نعم ، شعرت بقلق في المنشور حول التأثير على "العقول غير الناضجة" بشكل صحيح تمامًا!

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

يفغيني ريجكوف
كما ذكر أعلاه ، سوف أعلق على ثلاث نقاط من المقال. وهذا يعني أنني أتفق مع تلك ، وأنا لا أعلق.

1. يبدو التسلسل القياسي لمراحل خط الأنابيب كما يلي ...

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

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

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

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

3. بغض النظر عن الطريقة التي تختارها لتقديم تحليل خط أنابيب التسليم الخاص بك ، يجب إصلاح إصدار محلل

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

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

إذا كان لديك العديد من التحذيرات الجديدة بعد ترقية إصدار المحلل ، فقمعها ، كما كتبت أعلاه ، من خلال هذه الوظيفة. ولكن ليس لتحديث الإصدار ... وكقاعدة عامة ، لا يقوم هؤلاء العملاء (من المؤكد أن هناك بعضهم) بتحديث إصدار المحلل لسنوات. لا وقت لذلك. انهم يدفعون لتجديد الترخيص ، ولكن لا تستخدم الإصدارات الجديدة. لماذا؟ لأنه بمجرد أن قرروا تثبيت إصدار. المنتج اليوم وقبل ثلاث سنوات هو الليل والنهار. اتضح مثل "سأشتري التذكرة ، لكنني لن أحضر".

إيفان بونوماريف

1. هنا أنت على حق. أنا على استعداد للاتفاق مع مترجم / محلل في البداية وهذا حتى يجب تغييره في المقال! على سبيل المثال ، لا تستطيع spotbugs السيئة السمعة التصرف بطريقة مختلفة على الإطلاق ، حيث تقوم بتحليل الشفرة المترجمة. هناك حالات غريبة ، على سبيل المثال ، في خط أنابيب Ansible playbooks ، من الأفضل ضبط التحليل الثابت قبل التحليل لأنه أخف وزنا هناك. ولكن هذا هو الغريب نفسه)

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

فيما يتعلق بالنقطة 3 ، إليك مثال حقيقي من تجربتي. انظر إلى هذا الالتزام . من أين أتت؟ وضعنا في linters البرنامج النصي TravisCI. كانوا يعملون هناك كبوابات الجودة. لكن فجأة ، عندما بدأ إصدار جديد من Ansible-lint والذي كان يجد المزيد من التحذيرات ، بدأت بعض طلبات السحب قد فشلت بسبب التحذيرات في الكود ، والتي لم تتغير! في النهاية ، تم كسر العملية وتم دمج طلبات السحب العاجلة دون تمرير بوابات الجودة.

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

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

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

إيفان بونوماريف
رأيي هو أنه لا يوجد شيء اسمه "نحتاج إلى الالتزام بسرعة". هذه كلها مجرد عملية سيئة. العملية الجيدة تولد السرعة ليس لأننا كسر بوابات العملية / الجودة ، عندما نحتاج إلى "القيام بذلك بسرعة".

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

الالتزام المفضل لدي حول موضوع "بسرعة".

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

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

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

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

قدّم تحليلًا ثابتًا في هذه العملية ، لا تبحث فقط عن الأخطاء باستخدامه