بناء البرمجيات

فيما يلي بعض الجوانب الرئيسية لنشاط البرمجة : ^{[ 2 ]}

تسمية

اختيار اسم لكل مُعرِّف. أظهرت إحدى الدراسات أن الجهد المطلوب لتصحيح أخطاء البرنامج يكون في حده الأدنى عندما تتراوح أسماء المتغيرات بين 10 و 16 حرفًا. ^{[ 3 ]}

منطق

التنظيم ^في عبارات وروتينات [ ^{4 ]}

• أثبتت البرامج ذات التماسك العالي أنها أقل عرضة للأخطاء من البرامج ذات التماسك المنخفض. فقد وجدت دراسة أجريت على 450 برنامجًا أن 50% من البرامج ذات التماسك العالي كانت خالية من الأخطاء، مقارنةً بـ 18% فقط من البرامج ذات التماسك المنخفض. وفي دراسة أخرى أجريت على 450 برنامجًا مختلفًا، وُجد أن البرامج ذات أعلى نسب اقتران إلى تماسك كانت بها أخطاء أكثر بسبع مرات من تلك ذات أدنى نسب اقتران إلى تماسك، وكانت تكلفة إصلاحها أعلى بعشرين مرة.
• على الرغم من أن الدراسات أظهرت نتائج غير حاسمة بشأن العلاقة بين حجم الروتين ومعدل الأخطاء فيه، إلا أن إحدى الدراسات وجدت أن تكلفة إصلاح الروتينات التي تحتوي على أقل من 143 سطرًا من التعليمات البرمجية أقل بمقدار 2.4 مرة من تكلفة إصلاح الروتينات الأكبر حجمًا. وأظهرت دراسة أخرى أن التعليمات البرمجية تحتاج إلى أقل قدر من التغيير عندما يتراوح متوسط ​​عدد أسطر التعليمات البرمجية بين 100 و150 سطرًا. كما وجدت دراسة ثالثة أن التعقيد الهيكلي وكمية البيانات في الروتين يرتبطان بالأخطاء بغض النظر عن حجمه.
• تُعدّ نقاط التداخل بين الإجراءات من أكثر أجزاء البرنامج عرضةً للأخطاء. وقد أظهرت إحدى الدراسات أن 39% من جميع الأخطاء كانت أخطاءً في التواصل بين الإجراءات.
• ترتبط المعاملات غير المستخدمة بزيادة معدل الخطأ. في إحدى الدراسات، لم تتجاوز نسبة العمليات التي لم تُسجّل فيها أخطاء 17 إلى 29% من العمليات التي تحتوي على أكثر من متغير غير مُشار إليه، مقارنةً بنسبة 46% في العمليات التي لا تحتوي على أي متغيرات غير مستخدمة.
• ينبغي ألا يتجاوز عدد معايير الروتين 7 معايير كحد أقصى، حيث وجدت الأبحاث أن الناس عمومًا لا يستطيعون تتبع أكثر من سبع معلومات في وقت واحد.
• أظهرت إحدى التجارب أن التصاميم التي تصل إلى المصفوفات بشكل تسلسلي، بدلاً من الوصول إليها بشكل عشوائي، تؤدي إلى عدد أقل من المتغيرات وعدد أقل من مراجع المتغيرات. ^{[ 5 ]}
• أظهرت إحدى التجارب أن الحلقات ذات نقاط الخروج أكثر قابلية للفهم من أنواع الحلقات الأخرى. ^{[ 6 ]}
• فيما يتعلق بمستوى التداخل في الحلقات والشروط، أظهرت الدراسات أن المبرمجين يجدون صعوبة في فهم أكثر من ثلاثة مستويات من التداخل. ^{[ 6 ] [ 7 ]}
• لقد ثبت أن تعقيد تدفق التحكم يرتبط بانخفاض الموثوقية وكثرة الأخطاء. ^{[ 7 ]}

نمطية التصميم

إعادة هيكلة الكود وإعادة تنظيمه في فئات وحزم وبنى أخرى . عند مراعاة الاحتواء ، يجب ألا يتجاوز الحد الأقصى لعدد عناصر البيانات في الفئة 7±2. وقد أظهرت الأبحاث أن هذا العدد هو عدد العناصر المنفصلة التي يمكن للشخص تذكرها أثناء أداء مهام أخرى. عند مراعاة الوراثة ، يجب الحد من عدد المستويات في شجرة الوراثة. وقد وُجد أن أشجار الوراثة العميقة ترتبط ارتباطًا وثيقًا بزيادة معدلات الأخطاء. عند مراعاة عدد الإجراءات في الفئة، يجب إبقاؤها في أصغر حجم ممكن. وقد وجدت دراسة أجريت على برامج C++ ارتباطًا بين عدد الإجراءات وعدد الأخطاء. ^{[ 8 ]} وأظهرت دراسة أجرتها وكالة ناسا أن وضع الكود في فئات مُهيكلة جيدًا يمكن أن يُضاعف إمكانية إعادة استخدام الكود مقارنةً بالكود المُطور باستخدام التصميم الوظيفي. ^{[ 8 ] [ 4 ]}

معالجة الأخطاء

منطق التشفير للتعامل مع الأخطاء والاستثناءات المخطط لها وغير المخطط لها .

إدارة الموارد

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

حماية

منع الاختراقات الأمنية على مستوى التعليمات البرمجية مثل تجاوز سعة المخزن المؤقت وتجاوز سعة فهرس المصفوفة .

تحسين

التحسين مع تجنب التحسين المبكر .

الوثائق

كلاهما مضمن في الكود كتعليقات وكمستندات خارجية .

تتمحور عملية التكامل حول دمج الأجزاء المصممة بشكل منفصل. وتشمل الاعتبارات تخطيط تسلسل دمج المكونات ، وإنشاء بنية أساسية لدعم الإصدارات المؤقتة للبرنامج، وتحديد مستوى الاختبار وجودة العمل الذي يتم إجراؤه على المكونات قبل دمجها، وتحديد نقاط في المشروع يتم فيها اختبار الإصدارات المؤقتة. ^{[ 1 ]}

يُمكن للاختبار تقليل الوقت بين إدخال منطق خاطئ في الكود واكتشافه. في بعض الحالات، يُجرى الاختبار بعد كتابة الكود، ولكن في البرمجة القائمة على الاختبار أولاً ، تُنشأ حالات الاختبار قبل كتابة الكود. يتضمن البناء نوعين على الأقل من الاختبار، وغالبًا ما يُجريهما المطور الذي كتب الكود: ^{[ 1 ]} اختبار الوحدة واختبار التكامل .

لا يقتصر إعادة استخدام البرمجيات على إنشاء المكتبات واستخدامها فحسب ، بل يتطلب إضفاء الطابع الرسمي على ممارسة إعادة الاستخدام من خلال دمج عمليات وأنشطة إعادة الاستخدام في دورة حياة البرمجيات. قد تشمل المهام المتعلقة بإعادة الاستخدام في بناء البرمجيات أثناء كتابة التعليمات البرمجية واختبارها ما يلي: ^{[ 1 ]} اختيار التعليمات البرمجية القابلة لإعادة الاستخدام، وتقييم قابلية إعادة استخدام التعليمات البرمجية أو الاختبار، وإعداد تقارير عن مقاييس إعادة الاستخدام.

تشمل تقنيات ضمان الجودة أثناء بناء البرمجيات ما يلي: ^{[ 9 ]}

الاختبار

وجدت إحدى الدراسات أن متوسط ​​معدلات اكتشاف العيوب في اختبارات الوحدة واختبارات التكامل يبلغ 30% و35% على التوالي. ^{[ 10 ]}

فحص البرمجيات

فيما يتعلق بفحص البرمجيات ، وجدت إحدى الدراسات أن متوسط ​​معدل اكتشاف العيوب في عمليات فحص الكود الرسمية يبلغ 60%. أما بالنسبة لتكلفة اكتشاف العيوب، فقد وجدت دراسة أخرى أن قراءة الكود تكشف عن أخطاء أكثر بنسبة 80% في الساعة مقارنةً بالاختبار. وأظهرت دراسة أخرى أن تكلفة اكتشاف عيوب التصميم باستخدام الاختبار تزيد ستة أضعاف عن تكلفة اكتشافها باستخدام الفحص. وأظهرت دراسة أجرتها شركة IBM أن اكتشاف عيب واحد من خلال فحص الكود يستغرق 3.5 ساعات فقط، مقابل 15-25 ساعة باستخدام الاختبار. ووجدت مايكروسوفت أن اكتشاف عيب واحد وإصلاحه يستغرق 3 ساعات باستخدام فحص الكود، بينما يستغرق 12 ساعة باستخدام الاختبار. وفي برنامج مكون من 700 ألف سطر، أفيد بأن مراجعات الكود كانت أكثر فعالية من حيث التكلفة بعدة مرات من الاختبار. ^{[ 10 ]} ووجدت الدراسات أن عمليات الفحص تؤدي إلى تقليل العيوب بنسبة 20-30% لكل 1000 سطر من الكود مقارنةً بممارسات المراجعة الأقل رسمية، وأنها تزيد الإنتاجية بنحو 20%. تُخصص عادةً ما بين 10% و15% من ميزانية المشروع لعمليات التفتيش الرسمية، مما يُساهم في خفض التكلفة الإجمالية للمشروع. وقد وجد الباحثون أن وجود أكثر من 2-3 مُراجعين في عملية التفتيش الرسمية لا يزيد من عدد العيوب المكتشفة، على الرغم من أن النتائج تبدو مُختلفة باختلاف نوع المادة التي يتم فحصها. ^{[ 11 ]}

مراجعة فنية

فيما يتعلق بالمراجعة الفنية ، وجدت إحدى الدراسات أن متوسط ​​معدلات اكتشاف العيوب في مراجعات الكود غير الرسمية والفحص المكتبي يبلغ 25% و40% على التوالي. ^{[ 10 ]} وُجد أن عمليات التدقيق البرمجي (Walkings) تتمتع بمعدل اكتشاف عيوب يتراوح بين 20% و40%، ولكنها مكلفة، خاصةً مع ازدياد ضغوط المشروع. ووجدت وكالة ناسا أن قراءة الكود تكشف 3.3 عيوب في الساعة الواحدة من الجهد، مقابل 1.8 عيوب في الساعة للاختبار. كما أنها تكشف أخطاءً أكثر بنسبة تتراوح بين 20% و60% على مدار عمر المشروع مقارنةً بأنواع الاختبار الأخرى. ووجدت دراسة شملت 13 مراجعة لاجتماعات المراجعة أن 90% من العيوب تم اكتشافها أثناء التحضير للاجتماع، بينما لم يتم اكتشاف سوى 10% منها أثناء الاجتماع. ^{[ 11 ]}

التحليل الثابت

فيما يتعلق بالتحليل الثابت (IEEE1028)، أظهرت الدراسات أن الجمع بين هذه التقنيات ضروري لتحقيق معدل عالٍ لاكتشاف العيوب. كما أظهرت دراسات أخرى أن الأشخاص المختلفين يميلون إلى اكتشاف عيوب مختلفة. ووجدت إحدى الدراسات أن ممارسات البرمجة المتطرفة ، مثل البرمجة الثنائية ، والفحص المكتبي ، واختبار الوحدات ، واختبار التكامل ، واختبار الانحدار ، يمكن أن تحقق معدل اكتشاف عيوب يصل إلى 90%. ^{[ 10 ]} وأظهرت تجربة شملت مبرمجين ذوي خبرة أنهم تمكنوا، في المتوسط، من اكتشاف 5 أخطاء (9 كحد أقصى) من أصل 15 خطأً عن طريق الاختبار. ^{[ 12 ]}

تتركز 80% من الأخطاء عادةً في 20% من فئات وروتينات المشروع. وتُكتشف 50% من الأخطاء في 5% من فئات المشروع. تمكنت شركة IBM من خفض العيوب التي أبلغ عنها العملاء بنسبة عشرة إلى واحد، وخفض ميزانية الصيانة بنسبة 45% في نظام إدارة المعلومات (IMS) الخاص بها، وذلك بإصلاح أو إعادة كتابة 31 فئة فقط من أصل 425 فئة. تُساهم حوالي 20% من روتينات المشروع في 80% من تكاليف التطوير. وقد وجدت دراسة كلاسيكية أجرتها IBM أن بعض الروتينات المعرضة للأخطاء في نظام التشغيل OS/360 كانت الأكثر تكلفة، حيث احتوت على حوالي 50 عيبًا لكل 1000 سطر من التعليمات البرمجية، وتكلفة إصلاحها تعادل عشرة أضعاف تكلفة تطوير النظام بأكمله. ^{[ 12 ]}

من أجل معالجة الثغرات غير المتوقعة في تصميم البرمجيات ، يمكن إجراء تعديلات على التصميم أثناء عملية البناء. ^{[ 13 ]}

يرجع الدافع الرئيسي لتقليل تعقيد البرمجة إلى محدودية قدرة الأفراد على معالجة المعلومات المعقدة بفعالية. ويمكن تقليل التعقيد من خلال تقنيات الجودة التي تركز على عملية البناء . ^{[ 16 ]}

يساعد توقع التغيير المطورين على بناء برمجيات قابلة للتوسيع - أي برمجيات يمكن تحسينها دون المساس بالتصميم الأساسي. ^{[ 16 ]} تُظهر الأبحاث التي أُجريت على مدى 25 عامًا أن تكلفة إعادة العمل قد تكون أعلى من 10 إلى 100 مرة (من 5 إلى 10 مرات للمشاريع الصغيرة) من تكلفة تحديد المتطلبات بشكل صحيح من المرة الأولى. ونظرًا لأن 25% من المتطلبات تتغير أثناء التطوير في المشروع العادي، فإن الحاجة إلى تقليل تكلفة إعادة العمل تُبرز أهمية توقع التغيير. ^{[ 17 ]}

يعني بناء البرمجيات لغرض التحقق تصميمها بطريقة تُمكّن المطورين من اكتشاف الأخطاء بسهولة، سواءً أثناء الاختبارات المستقلة أو العمليات التشغيلية. تشمل التقنيات المحددة التي تدعم بناء البرمجيات لغرض التحقق اتباع معايير البرمجة لدعم مراجعات الكود ، واختبار الوحدات ، وتنظيم الكود لدعم الاختبار الآلي ، والحد من استخدام هياكل اللغة المعقدة أو صعبة الفهم ، وغيرها. ^{[ 16 ]}

أثبت إخفاء المعلومات أنه أسلوب تصميم مفيد في البرامج الكبيرة، مما سهّل تعديلها بمقدار أربعة أضعاف. ويُعدّ انخفاض التفرع أحد خصائص التصميم التي وجد الباحثون أنها مفيدة. ^{[ 18 ]}

يمكن لإعادة استخدام البرمجيات أن تحقق فوائد كبيرة في الإنتاجية والجودة والتكلفة. وتتحقق الفوائد الأساسية من خلال إعادة استخدام أصول البرمجيات الموجودة، ويتم دعم إعادة الاستخدام من خلال إنشاء برمجيات مصممة لإعادة الاستخدام في المستقبل. ^{[ 16 ]}

تشمل المعايير، سواء كانت خارجية (تم إنشاؤها بواسطة منظمات دولية) أو داخلية (تم إنشاؤها على مستوى الشركات)، التي تؤثر بشكل مباشر على قضايا البناء ما يلي: ^{[ 16 ]}

• معايير التوثيق للشكل والمحتوى
• معايير النمذجة مثل UML
• معايير الترميز

يُعدّ تجريد البيانات سمةً من سمات الشيفرة المصدرية، حيث يُمثّل المعلومات بشكلٍ يُشابه معناها، مع إخفاء تفاصيل التنفيذ. ^{[ 19 ]} وقد أظهرت الأبحاث الأكاديمية أن تجريد البيانات يجعل البرامج أسهل فهمًا بنسبة 30% تقريبًا من البرامج الوظيفية. ^{[ 8 ]}

تدعم لغات البرمجة كائنية التوجه سلسلة من آليات وقت التشغيل التي تزيد من مرونة البرامج وقابليتها للتكيف، مثل تجريد البيانات ، والتغليف ، والنمطية ، والوراثة ، وتعدد الأشكال ، والانعكاس . ^{[ 20 ] [ 21 ]}

البرمجة الدفاعية هي حماية روتين برمجي من التعطل بسبب مدخلات غير صالحة. ^{[ 22 ]} التأكيدات هي شروط تنفيذية تُوضع في البرنامج للسماح بإجراء فحوصات أثناء التشغيل. ^{[ 20 ]} التصميم التعاقدي هو منهج تطوير يتضمن شروطًا مسبقة ولاحقة لكل روتين برمجي.

يشير مصطلح معالجة الأخطاء إلى ممارسة برمجة النظام للتعامل مع حالات الخطأ التي قد تنشأ أثناء تشغيل البرنامج. أما معالجة الاستثناءات فهي بنية برمجية أو آلية برمجية مصممة للتعامل مع حدوث الاستثناءات، وهي حالات خاصة تُغير مسار تنفيذ البرنامج الطبيعي. ^{[ 23 ]} وتُعرف خاصية تحمل الأعطال بأنها مجموعة من التقنيات التي تزيد من موثوقية البرمجيات من خلال اكتشاف الأخطاء، ثم التعافي منها إن أمكن، أو احتواء آثارها إن تعذر التعافي. ^{[ 22 ]}

تعتمد البرمجة القائمة على الحالة على استخدام آلة ذات حالة محدودة لتنفيذ المنطق. ^{[ 22 ]}

تستخدم المنطق القائم على الجداول المعلومات المنسقة على شكل جدول لتوجيه التنفيذ. ^{[ 24 ]}

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

التدويل والتوطين هما نشاط إعداد برنامج لدعم لغات متعددة ودعم لغات مختلفة. ^{[ 24 ]}