فحص الآثار السلبية لتكرار التعليمات البرمجية

مكتمل

يشير الرمز المكرر إلى منطق متطابق أو مشابه يتكرر عبر أجزاء مختلفة من قاعدة التعليمات البرمجية. يمكن أن يكون:

  • الازدواجية الدقيقة: نسخ كتل التعليمات البرمجية الملصقة.
  • الازدواجية الدلالية: التعليمات البرمجية التي تؤدي نفس الوظيفة ولكن تتم كتابتها بشكل مختلف.

يعد التطوير المتسرع وضعف التواصل ونقص الوثائق والفرق المنعزلة من الأسباب الشائعة لتكرار التعليمات البرمجية.

التكاليف المخفية للتعليمات البرمجية المكررة

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

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

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

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

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

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

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

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

تزيد التعليمات البرمجية المكررة من وقت صيانة الكود ، وتهيمن تكاليف الصيانة على دورة حياة البرنامج (حتى 80% من التكلفة الإجمالية).

مبدأ "لا تكرر نفسك" (DRY)

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

الهدف من DRY هو الحصول على مصدر واحد للحقيقة لأي جزء من المنطق أو المعرفة. مصدر واحد للحقيقة يجعل الصيانة أسهل ، ويقلل من الأخطاء ، ويحسن وضوح الكود.

Note

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

فوائد الدمج

ضع قائمة بالنتائج الإيجابية لإعادة بناء التعليمات البرمجية المكررة:

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

علامات التعليمات البرمجية المكررة

فيما يلي بعض القواعد والأنماط الأساسية التي يمكن أن تساعدك في اكتشاف الازدواجية.

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

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

  • أنماط البريد الإلكتروني أو التسجيل المتشابهة: يعد تسجيل التدقيق وتنسيق البريد الإلكتروني من المجالات الشائعة للتكرار. إذا رأيت أساليب SendEmail() أو LogActivity() مماثلة عبر الخدمات، ففكر في مركزيتها في أداة مساعدة مشتركة أو طبقة خدمة.

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

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

الملخص

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