دور جودة الكود: المقاييس المهمة وتأثيرها

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

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

ما هي جودة الكود؟

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

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

لماذا تُعد جودة الكود مهمة؟

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

مقاييس جودة الكود: مرجع كامل

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

مقاييس التعقيد

التعقيد السيكلوماتيكي يقيس هذا المقياس عدد المسارات المستقلة خطيًا عبر دالة أو طريقة. وقد قدمه توماس مكابي عام 1976، ولا يزال المقياس الأكثر استخدامًا في مجال التعقيد. وتعتمد الصيغة على حساب نقاط القرار. if, else if, switch الحالات، شروط الحلقة، catch الكتل، والمعاملات الشرطية، ويضيف 1. الدالة التي ليس لها فروع لها تعقيد حلقي يساوي 1.

التعقيد السيكلوماتيكي	التفسير
1-5	بسيط وسهل الاختبار
6-10	معتدل، يمكن التحكم فيه
11-20	يصبح الاختبار معقدًا وصعبًا.
21-50	مخاطرة عالية جدًا، يوصى بإعادة هيكلة الكود
50+	غير قابل للاختبار، ومن شبه المؤكد أنه يحتوي على عيوب

يرتبط التعقيد الحلقي العالي ارتباطًا وثيقًا بكثافة العيوب. وقد وجدت دراسة نُشرت في مجلة IEEE Transactions on Software Engineering أن الدوال ذات التعقيد الحلقي الذي يزيد عن 10 لديها معدلات عيوب أعلى بكثير من الدوال الأبسط. أما بالنسبة لتحليل التعقيد الحلقي في قواعد البيانات البرمجية القديمة، فيكمن التحدي في إيجاد الدوال التي تراكمت فيها منطق اتخاذ القرار على مر سنوات من الصيانة دون أن يقوم أحد بإعادة هيكلة بنيتها العامة.

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

التعقيد المعرفي تم تقديم هذه التقنية بواسطة SonarSource، وهي تقيس مدى صعوبة فهم الكود بدلاً من عدد المسارات التي يحتويها. وتُعاقب هذه التقنية التداخل بشكل أكبر من التفرع الخطي. if داخل while داخل آخر if درجات أعلى من ثلاثة متتالية if العبارات ذات التعقيد الحلقي نفسه. يتوافق التعقيد الإدراكي بشكل أفضل مع الصعوبة الفعلية التي يواجهها المطورون عند قراءة التعليمات البرمجية. عادةً ما يتم وضع علامة على التعقيد الإدراكي الذي يزيد عن 15 لكل طريقة للمراجعة؛ أما ما يزيد عن 25 فيشير إلى دالة سيجد معظم المطورين صعوبة حقيقية في فهمها.

تستخلص مقاييس هالستيد مجموعة من المقاييس من أربعة إحصاءات في شفرة المصدر: المعاملات المميزة (n1)، والمعاملات المميزة (n2)، وإجمالي المعاملات (N1)، وإجمالي المعاملات (N2). ومن هذه المقاييس، يحسب هالستيد ما يلي:

• الصوت (N × log2(n)): حجم التنفيذ من حيث محتوى المعلومات
• صعوبة (n1/2 × N2/n2): تقدير لمدى صعوبة كتابة أو فهم الكود
• مجهود (الحجم × الصعوبة): إجمالي الجهد الذهني المُقدَّر لتنفيذ أو فهم الكود

تُعدّ مقاييس هالستيد مفيدةً بشكلٍ خاص في مقارنة الدوال ذات التعقيد الحلقي المتقارب لتحديد أيّها أصعب فهمًا. فالدالة التي تحتوي على 10 فروع عبر متغيرات مُسمّاة بوضوح تكون أقل صعوبةً في مقياس هالستيد من تلك التي تحتوي على 10 فروع عبر مؤشرات محسوبة ومعرّفات أحادية الحرف.

مقاييس قابلية الصيانة

مؤشر قابلية الصيانة هو مقياس مركب طُوِّر في الأصل بواسطة بول أومان وجاك هاغمايستر، ثم اعتمدته مايكروسوفت فيجوال ستوديو كمقياس قياسي لقابلية الصيانة. وهو يجمع بين حجم هالستيد، والتعقيد الحلقي، وعدد أسطر التعليمات البرمجية في درجة واحدة.

تُنتج صيغة Visual Studio درجة تتراوح من 0 إلى 100:

مؤشر الصيانة	التقييم
20-100	قابل للصيانة (أخضر)
10-19	مستوى متوسط ​​من الحاجة إلى الصيانة (أصفر)
0-9	يصعب الحفاظ عليه (أحمر)

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

يقيس كل من عدد أسطر الكود (LOC) وعدد أسطر الكود بالآلاف حجم قاعدة الكود. لا يُشير عدد أسطر الكود وحده إلى الجودة، ولكنه يُوفر مُقسِّمات أساسية لمقاييس أخرى: كثافة العيوب (عدد الأخطاء لكل ألف سطر كود)، وكثافة التعليقات (عدد التعليقات لكل سطر كود)، وكثافة الاختبارات (عدد تأكيدات الاختبار لكل سطر كود). كما يُحدد عدد أسطر الكود تكلفة التعقيد: فدالة من 500 سطر ذات تعقيد حلقي 20 تُمثل مشكلة أكبر بكثير من دالة من 50 سطر بنفس النتيجة.

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

مقاييس تغطية الكود

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

المعايير الصناعية لتغطية اختبار الوحدة:

• أقل من 50%: غير كافٍ، ولن يتم اكتشاف معظم العيوب عن طريق الاختبارات.
• 50-75%: متوسط، تم تغطية المسارات الرئيسية، ومن المحتمل عدم رصد الحالات الحدية
• 75-90%: مناسب لمعظم أكواد التطبيقات
• نسبة أعلى من 90%: مناسبة للأنظمة الحساسة للسلامة أو الأنظمة عالية الموثوقية

تخضع تغطية التعليمات البرمجية في التطبيقات بالغة الأهمية لمعايير أكثر صرامة. يحدد معيار DO-178C لبرمجيات الطيران ومعيار IEC 61508 للسلامة الوظيفية متطلبات تغطية (تغطية الحالات الحرجة/القرارات لأعلى مستويات الأهمية) تتجاوز ما يحققه اختبار الوحدة القياسي. يتطلب تحسين جودة التعليمات البرمجية في التطبيقات بالغة الأهمية أدوات تغطية تتبع تغطية الحالات/القرارات، وقادرة على توفير الأدلة الرسمية المطلوبة من جهات الاعتماد.

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

مقاييس العيوب

كثافة الأخطاء (أو كثافة العيوب) هي عدد العيوب المؤكدة لكل ألف سطر من التعليمات البرمجية. وهي المقياس الكمي الأكثر دقة لجودة التعليمات البرمجية. تشير معايير الصناعة الصادرة عن CISQ إلى أن البرامج التجارية الجاهزة للاستخدام تحتوي في المتوسط ​​على ما بين 15 و50 عيبًا لكل ألف سطر من التعليمات البرمجية قبل الاختبار؛ وبعد الاختبار والإصدار، عادةً ما تعمل البرامج التجارية عالية الجودة بأقل من عيب واحد لكل ألف سطر من التعليمات البرمجية.

نتائج التحليل الثابت تقدير كثافة العيوب قبل تأكيدها من خلال الاختبارات أو الاستخدام الإنتاجي. أدوات مثل SonarQube وCheckmarx و SMART TS XL يُحلل الكود البرمجي بحثًا عن أنماط مرتبطة بفئات العيوب والثغرات الأمنية المعروفة، مما يُنتج إحصاءً للمشكلات المحتملة مصنفة حسب خطورتها. وتُوفر نسبة النتائج الحرجة والخطيرة إلى عدد أسطر الكود مؤشرًا مبكرًا على جودة الكود قبل وصوله إلى مرحلة الاختبار.

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

مقاييس سهولة القراءة والأسلوب

كثافة التعليق هي نسبة أسطر التعليقات إلى أسطر الكود. تختلف النطاقات المثلى باختلاف اللغة واتفاقية الفريق، ولكنها تتراوح عادةً بين 10-30%. قد تشير النسبة الأقل من 10% إلى كود غير موثق بشكل كافٍ؛ بينما قد تشير النسبة الأعلى من 50% إلى كود معقد للغاية لدرجة أنه يتطلب شرحًا مطولًا لمنطق غير بديهي. جودة التعليقات أهم من كميتها: فالتعليق الذي يعيد صياغة ما يفعله الكود (// increment i by 1) لا يضيف شيئاً، بينما يضيف التعليق الذي يشرح سبب اختيار خوارزمية معينة قيمة كبيرة.

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

يقيس معدل تكرار الكود النسبة المئوية لقاعدة الكود المكررة في مواقع متعددة. وعادةً ما يتم الإبلاغ عن التكرار الذي يتجاوز 5%. يُضاعف الكود المكرر جهد الصيانة: إذ يجب العثور على أي خطأ في منطق مكرر وإصلاحه في كل نسخة، كما يجب تطبيق التغييرات في السلوك بشكل متسق على جميع النسخ. يُخفي التكرار أيضًا الحجم الحقيقي لقاعدة الكود: فقد يحتوي نظام يبدو أنه يتكون من 100,000 سطر على 40,000 سطر من المنطق الفريد و60,000 سطر من النسخ.

مقاييس الأمن والديون التقنية

يُعرّف برنامج SonarQube نسبة الدين التقني بأنها نسبة تكلفة الإصلاح المُقدّرة إلى تكلفة تطوير قاعدة البيانات المُقدّرة. تُعتبر قاعدة البيانات نظيفة إذا كانت نسبة الدين التقني أقل من 5%، بينما تشير النسبة التي تتجاوز 20% إلى تراكم دين كبير سيُعيق عملية التطوير المستقبلية بشكل ملحوظ.

يقيس مؤشر كثافة النقاط الساخنة الأمنية عدد النقاط الساخنة الأمنية، وهي أنماط برمجية تتطلب مراجعة أمنية، وليست ثغرات مؤكدة، لكل ألف سطر من التعليمات البرمجية. تشمل الأمثلة استعلامات SQL غير المُعَلمة، واستخدام وظائف تشفير قديمة، ومعالجة المدخلات غير المُدققة. تحدد أدوات التحليل الثابت هذه الأنماط وتعرضها كعناصر تتطلب مراجعة أمنية يدوية.

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

كيفية قياس جودة الكود: منهج عملي

لا يُعدّ قياس جودة الكود إجراءً منفردًا، بل ممارسة مستمرة مُدمجة في سير عمل التطوير. ويُعدّ اتباع نهج عملي من أربع مراحل مناسبًا للفرق التي تبدأ من قاعدة بيانات كود غير مُقاسة.

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

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

المرحلة الثالثة: التكامل مع التكامل المستمر/التسليم المستمر (CI/CD). قم بتهيئة مسار التكامل المستمر لحساب المقاييس الرئيسية مع كل عملية إيداع أو طلب سحب. ضع علامة على التغييرات التي تُخرج أحد المقاييس عن نطاقه المقبول. امنع عمليات الدمج التي تُدخل شيفرة جديدة ذات تعقيد حلقي يتجاوز الحد المسموح به، أو التي تُقلل التغطية عن الحد المسموح به، أو التي تُدخل نتائج تحليل ثابت حرجة. هذا يحوّل حدود المقاييس من مجرد إرشادات إلى معايير مُلزمة.

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

مقاييس جودة الكود في سياقات المؤسسات، والمنهجيات الرشيقة، والأنظمة الحساسة للسلامة

مقاييس جودة الكود في تطوير البرمجيات الرشيقة

تواجه فرق العمل الرشيقة تحديًا خاصًا فيما يتعلق بمقاييس جودة الكود: فالتركيز على تسليم برمجيات عاملة في دورات قصيرة قد يُولّد ضغطًا لإطلاقها قبل حلّ مشاكل الجودة. والحل ليس التخلي عن المقاييس، بل إدراجها في تعريف الاكتمال. لا تُعتبر المهمة مكتملة بمجرد عمل الميزة، بل عندما تعمل الميزة ويلبي الكود الجديد معايير الجودة التي يحددها الفريق.

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

جودة الكود لأغراض التدقيق الفني

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

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

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

جودة البرمجيات في التطبيقات الحساسة للسلامة وتطبيقات التكنولوجيا المالية

تتطلب التطبيقات بالغة الأهمية للسلامة في مجالات الطيران والسيارات والأجهزة الطبية والتحكم الصناعي معايير جودة برمجية تتجاوز معايير البرامج التجارية التقليدية. أهم الاختلافات:

• تُحدد حدود التعقيد الحلقي عادةً عند 10 أو أقل، وتتطلب الاستثناءات تبريراً رسمياً.
• تستخدم متطلبات التغطية تغطية MC/DC (تغطية الحالة/القرار المعدلة) بدلاً من تغطية الخط أو الفرع
• يجب إجراء التحليل الثابت باستخدام أدوات معتمدة، ويجب توثيق المخالفات وحلها أو قبولها رسميًا.
• تتم مراقبة معدل تغيير التعليمات البرمجية كمؤشر للسلامة: حيث تؤدي معدلات التغيير المرتفعة في الوحدات النمطية ذات الأهمية البالغة للسلامة إلى مراجعة إضافية وإعادة التحقق.

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

مقاييس جودة الكود حسب اللغة

مقاييس جودة كود بايثون يمكن حسابها باستخدام radon (مؤشر التعقيد والصيانة في الأنظمة الحلقية)، pylint (عيوب في الكود ومخالفات في أسلوب البرمجة)، coverage.py (تغطية الاختبار)، bandit (قضايا أمنية)، و mypy or pyright (صحة النوع). مؤشر قابلية الصيانة في radon يستخدم صيغة هالستيد المعدلة والمعايرة للغة بايثون. الدرجة أ أعلى من 20، والدرجة ب من 10 إلى 20، والدرجة ج أقل من 10.

جودة كود RPG يتطلب نظام IBM i أدوات متخصصة لأن أدوات قياس الجودة القياسية لا تحلل بناء جملة RPG. SMART TS XL يوفر تحليل التعقيد الحلقي، وعدد أسطر التعليمات البرمجية، وتحليل التبعية لبرامج RPG، وهو أمر ذو قيمة خاصة لشركات IBM i التي تدير قواعد بيانات قديمة كبيرة حيث كان من المستحيل سابقًا أتمتة قياس الجودة.

مقاييس مراجعة التعليمات البرمجية

تُعد مراجعة الكود نشاطًا لمراقبة الجودة، ويمكن قياس فعاليته الخاصة:

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

تتميز الفرق عالية الأداء عادةً بتغطية مراجعة تتجاوز 90%، ومتوسط ​​عيوب مكتشفة لكل مراجعة يتراوح بين 1 و3 عيوب لكل مئة سطر مُراجع، وأوقات استجابة سريعة. تساعد مقاييس المراجعة في تحديد ما إذا كانت مراجعة التعليمات البرمجية تعمل كبوابة جودة أم مجرد إجراء شكلي.

مراقبة جودة الكود بشكل مستمر

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

تشمل المراقبة الفعالة والمستمرة لجودة الكود ما يلي:

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

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

كيفية SMART TS XL يقيس ويحسن جودة الكود

SMART TS XL يحسب هذا البرنامج مجموعة كاملة من مقاييس جودة الكود الموضحة في هذه المقالة عبر جميع اللغات والمنصات في بيئة التطوير: كوبول، وJCL، وجافا، و.NET، وبايثون، وجافا سكريبت، وتايب سكريبت، وRPG، وSQL، وغيرها. في حين أن معظم أدوات الجودة تعمل على لغة واحدة في كل مرة، SMART TS XL يقوم ببناء نموذج جودة موحد للنظام بأكمله، مما يجعل من الممكن مقارنة الجودة عبر اللغات، وتتبع المقاييس على مستوى النظام بدلاً من مستوى الملف، وتحديد مشاكل الجودة عبر المكونات التي لا تستطيع أدوات اللغة الواحدة رؤيتها.

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

SMART TS XLتتكامل مقاييس جودة الكود الخاصة بـ [اسم النظام] مع مسارات DevOps عبر واجهة برمجة التطبيقات (API)، مما يُمكّن من تطبيق معايير الجودة على مستوى التكامل المستمر/التسليم المستمر (CI/CD). فعندما يُضيف تعديلٌ برمجيٌّ دالةً ذات تعقيد حلقي يتجاوز الحدّ المُحدد، أو يُقلل التغطية عن الحدّ الأدنى المُحدد، أو يُضيف نتيجةً حرجةً في التحليل الثابت، يُمكن لمسار التطوير إيقاف عملية البناء مع إصدار تشخيص مُحدد يُوضح للمطور ما تم قياسه بالضبط وسبب عدم تجاوزه الحدّ المُحدد. هذا يُحوّل عملية ضمان الجودة من عمليات التدقيق بعد الإصدار إلى التغذية الراجعة أثناء التطوير، مما يُقلل من تكلفة مشاكل الجودة من خلال اكتشافها في المرحلة التي يكون فيها إصلاحها أقل تكلفة.

جودة الكود هي مسؤولية الفريق، وليست مجرد تقرير.

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

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