البرمجة الدفاعية: هل هي جنون العظمة أم الترميز الذكي؟

لماذا البرمجة الدفاعية هي أفضل طريقة لترميز قوي

البرمجة الدفاعية هي البرمجة الحقيقية الوحيدة.

ائتمانات الصورة: Pixabay.com

البرمجة الدفاعية هي عندما يتوقع مبرمج المشاكل ويكتب رمز للتعامل معها.

هو مثل رؤية حادث سيارة في المستقبل ... والبقاء هادئا لأنك مؤمن عليه.

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

· فشل مبكرًا: يجب أن تضمن الشفرة الخاصة بك إنهاء جميع العمليات الهامة مقدمًا خاصةً إذا كانت تلك العمليات مكلفة أو قد تؤثر على البيانات بشكل لا رجعة فيه.

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

· فشل بوضوح: عندما يتم كسر شيء ما ، يجب أن يُرجع رسالة خطأ واضحة جدًا ووصفًا يمكن أن يمكّن فريق الدعم من حل الخطأ.

حسنا. قد يجادل هنا.

لا توجد مشاكل في الوقت الحاضر. كود بلدي يعمل بشكل جميل. لماذا يجب أن أستثمر الوقت والجهد في مشكلة "مستقبل متوقع"؟ بعد كل شيء ، لقد تعلمنا مرارًا وتكرارًا استخدام "لن تحتاجها" (YAGNI). وأنت مبرمج محترف وليس هواة يستطيعون الإضافة إلى الكود كما تشاء.

المفتاح هنا هو البراغماتية.

أندرو هانت في كتابه براغماتيك مبرمج يصف البرمجة الدفاعية بأنها "بارانويا البراغماتية".

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

البرمجة الصحية بجنون العظمة هي النوع الصحيح من البرمجة. ولكن يمكن أن تؤخذ جنون العظمة بعيدا جدا. المفتاح هو تحقيق التوازن الصحيح.

وهنا بعض الطرق للقيام ببرمجة دفاعية.

اسأل نفسك: إذا فشل هذا؟

كل سطر من التعليمات البرمجية يقوم بشيء ما ، لذا فإن نقطة الدفاع الأولى تسأل نفسك إذا ما فشل الرمز ، ثم ماذا.

على سبيل المثال ، ضع في الاعتبار التعليمات البرمجية غير المتوافقة التالية.

حالة SY-INDEX. // غير متوافق ؛ في عداد المفقودين عندما جملة أخرى
عند واحد.
اكتب "واحد".
متى 2.
اكتب "اثنين".
ENDCASE.

هنا يمكننا طرح الأسئلة التالية.

ماذا يحدث إذا كان مؤشر sy ليس 1.

ماذا يحدث إذا كان مؤشر sy ليس 2.

لحل هذه المشكلة ، نضيف عبارة أخرى.

حالة SY-INDEX.
عند واحد.
اكتب "واحد".
متى 2.
اكتب "اثنين".
عندما غيرهم. // متوافق
اكتب "نتيجة غير متوقعة"
ENDCASE.

بسيط. أليس كذلك؟

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

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

تحقق من شروط الحدود بعناية.

الاختيار الأول هو التأكد مما إذا كنت بحاجة إلى شرط حدودي بعد كل شيء لأن الحلقات باهظة الثمن.

شروط الحدود (أو الحافة) هي حيث يحدث كل الإجراء. حلقة من 0 إلى 100 والقيم حلقة من 1 إلى 98 هي إلى حد كبير هي نفسها (باستثناء الشرطية في رمز بالطبع). ولكن loop 0 هي المكان الذي يدخل فيه الرمز في الحلقة ، ويتم إعداد شروط التهيئة (وربما يتم إعدادها بشكل خاطئ). وبالمثل ، فإن الحلقة الأخيرة هي المكان الذي تترك فيه الأشياء ، ويتوقف كل ما تفعله الحلقة للقيم.

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

اطلع على الكود التالي غير المتوافق والمتوافق. لا نحتاج إلى حلقة على الإطلاق في هذه الحالة. بسيطة إذا سوف تفعل.

            مثال رمز غير متوافق
البيانات المتبقية TYPE i.
هل 20 مرات.
الباقي = sy-index MOD 2.
cl_demo_output => write_text ().
خروج. "غير متوافق ، يتم تنفيذ الحلقة مرة واحدة فقط. يمكننا استخدام IF
ENDDO.
          مثال التعليمات البرمجية المتوافقة
البيانات المتبقية TYPE i.
هل 20 مرات.
الباقي = مؤشر sy وزارة الدفاع 2.
cl_demo_output => write_text ().
ENDDO.

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

استخدام TDD (اختبار يحركها التنمية)

الفكرة الأساسية لـ TDD هي "اختبارات وحدة الكتابة الأولى ، ثم كتابة الكود ، ثم ريفاكتور ، ثم تكرار".

اختبارات الوحدة عبارة عن اختبارات آلية تتحقق مما إذا كانت الوظائف تعمل كما هو متوقع. يجب أن يفشل اختبار الوحدة الأول نظرًا لأنه مكتوب قبل أن يكون لديك أي قاعدة بيانات.

قمت بإضافة قليلا إلى رمز حالة الاختبار. قمت بإضافة قليلا إلى رمز الإنتاج. تدفقات رمز اثنين تنمو في وقت واحد إلى مكونات تكميلية. تتناسب الاختبارات مع رمز الإنتاج مثل أن الجسم المضاد يناسب المستضد.

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

هذا يخلق تصميمًا أفضل مفصولًا تتحكم فيه بشكل أفضل في الأشياء أثناء تطوير الشفرة.

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

على عكس ممارسات الترميز القديمة ، يسمح TDD للمطورين بالعودة إلى لوحة الرسم والتركيز على تصميم بنية خفيفة الوزن ومرنة في المقدمة.

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

دائما كتابة التعليمات البرمجية الأمثل.

بعض البرامج (والمبرمجين) تحب الموارد كثيرًا. ولكن كلما استطعت ، استخدم الحد الأدنى. ولاستخدام الحد الأدنى من التعليمات البرمجية يجب أن يكون الأمثل قدر الإمكان.

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

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

إلى جانب تحسينات المحول البرمجي القياسية ، هناك العديد من تقنيات الضبط الأخرى التي يمكن استخدامها.

اجمع التعبيرات الفرعية الشائعة.

في حالة حدوث حساب مكلف في أماكن متعددة ، فمن الأفضل أن يتم حسابه في مكان واحد وتذكر النتيجة. لا تضع مثل هذه الحسابات في حلقة ما لم يكن ذلك مطلوبًا.

استبدال عمليات باهظة الثمن من قبل تلك الرخيصة.

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

القضاء على الحلقات.

الحلقات هي في معظمها النفقات العامة. حاول تجنب الحلقات كلما كان ذلك ممكنًا إذا لم تكن التكرارات كبيرة.

ذاكرة التخزين المؤقت كثيرا ما تستخدم القيم.

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

أعد كتابة بلغة أقل مستوى.

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

تذكر في التحسين ، قد يكون الاختيار 90٪ من اللعبة. يجدر بنا أن نأخذ الوقت الكافي لتحديد ما تفعله والقيام بذلك بشكل صحيح. بالطبع: هذا هو المكان الذي يكمن فيه السحر الأسود!

وأخيرا ، لا تثق في أحد.

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

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

من الواضح أن بيانات المستخدم مشبوهة دائمًا. يمكن للمستخدمين إساءة فهم ما تعتقد أنه واضح تمامًا. حاول وتوقع المشكلات وتحقق من أو رتب أي شيء يأتي.

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

باختصار ، يجب أن تكون البيانات الواردة نظيفة إذا كان لديك أي أمل في أن تقوم الشفرة الخاصة بك بالقيام بما هو المقصود القيام به. إذا سمعت يومًا عبارة "Garbage in ، Garbage Out" ، فهذا هو المكان الذي جاءت منه.

كما قال إدوارد ديمينج بحق.

"نثق في الله. يجب على جميع الآخرين جلب البيانات ".
عن المؤلف-:
رافي راجان هو مدير عالمي لبرنامج تكنولوجيا المعلومات ومقره مومباي ، الهند. وهو أيضًا مدون متعطش ، وكاتب شعر هايكو ، وعشاق علم الآثار ، وهوس التاريخ. تواصل مع رافي على LinkedIn و Twitter و Medium.