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

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

يكمن التحدي في أن مقاييس جودة الكود ليست قابلة للتبادل ولا يمكن تفسيرها عالميًا. فمؤشر قابلية الصيانة العالي في برنامج 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 لديها معدلات عيوب أعلى بكثير من الدوال الأبسط. تحليل التعقيد الحلقي في قواعد البيانات القديمة، يكمن القلق في العثور على وظائف تراكمت فيها منطق اتخاذ القرار على مر سنوات من الصيانة دون أن يقوم أي شخص بإعادة هيكلة البنية العامة.

تعقيد مسار NP يحسب عدد مسارات التنفيذ الفريدة عبر دالة، بما في ذلك المسارات الناتجة عن الشروط المتداخلة والحلقات. بينما يحسب التعقيد الحلقي التفرعات خطيًا، فإن تعقيد 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) وعدد أسطر التعليمات البرمجية (KLOC) يقيس عدد أسطر الكود حجم قاعدة البيانات، سواءً بالأسطر أو بآلاف الأسطر. لا يُخبرك عدد الأسطر وحده شيئًا عن الجودة، ولكنه يُوفّر مُقسّمات أساسية لمقاييس أخرى: كثافة العيوب هي الأخطاء لكل ألف سطر من الكود، وكثافة التعليقات هي التعليقات لكل سطر من الكود، وكثافة الاختبارات هي تأكيدات الاختبار لكل سطر من الكود. كما يُقاس عدد الأسطر بتكلفة التعقيد: فدالة من 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). فعندما يُضيف تعديلٌ برمجيٌّ دالةً ذات تعقيد حلقي يتجاوز الحدّ المُحدد، أو يُقلل التغطية عن الحدّ الأدنى المُحدد، أو يُضيف نتيجةً حرجةً في التحليل الثابت، يُمكن لمسار التطوير إيقاف عملية البناء مع إصدار تشخيص مُحدد يُوضح للمطور ما تم قياسه بالضبط وسبب عدم تجاوزه الحدّ المُحدد. هذا يُحوّل عملية ضمان الجودة من عمليات التدقيق بعد الإصدار إلى التغذية الراجعة أثناء التطوير، مما يُقلل من تكلفة مشاكل الجودة من خلال اكتشافها في المرحلة التي يكون فيها إصلاحها أقل تكلفة.

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

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

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