باختصار
التحليل الساكن للبرامج (Static Program Analysis) فحص الكود دون تشغيله، بحثًا عن أخطاء محتملة وأنماط مريبة ومشكلات في الأسلوب، قبل أن يصل البرنامج إلى المستخدم.
بالتفصيل
بحسب Wikipedia، يقابل التحليلُ الساكن التحليلَ الديناميكي الذي يجري أثناء تشغيل البرنامج. ويُستخدم المصطلح عادة للتحليل الذي تقوم به أدوات آلية، أما الفحص البشري فيُسمّى مراجعة الكود أو فهم البرنامج.
ويتراوح عمق هذه الأدوات بين فحص كل سطر على حدة، وتحليل الكود المصدري كاملًا، وصولًا إلى الطرق الصورية التي تثبت رياضيًا أن البرنامج يطابق مواصفته. وأخفّ صوره ما يُسمّى المدقّق (Linter): أداة تفحص الكود بحثًا عن أخطاء البرمجة والتراكيب المريبة ومخالفات الأسلوب.
وفي زمن مساعدات البرمجة صار لهذه الأدوات دور جديد. فهندسة Grab تشغّل Android Lint وSwiftLint على كل طلب دمج، وتمنع الدمج إذا ظهرت نتيجة عالية الخطورة. وتقول إن القواعد المخصّصة تزداد أهمية مع الكود المولّد، لأن المساعد قد يكتب كودًا يبدو صحيحًا دون أن يعرف أي الأنماط أسقطت التطبيق من قبل.
مثال عملي
قبل أن يُطبع كتاب، يقرؤه المدقّق اللغوي بحثًا عن الأخطاء الإملائية والنحوية والجمل الملتبسة. لا يحتاج أن يرى القرّاء وهم يقرؤون الكتاب كي يكتشف خطأً في الإعراب.
التحليل الساكن هو المدقّق اللغوي للكود. لا يضمن أن الكتاب ممتع، لكنه يضمن ألّا يخرج إلى المطبعة بأخطاء كان يمكن اكتشافها على المكتب.
مصطلحات مرتبطة
- الطرح المرحلي للتحديثات (Staged Rollout)
- المواصفة الصورية (Formal Specification)
- مفتاح الميزة (Feature Flag)
- مراجعة الكود (Code Review)
