تطوير الشبكة 10 مضادات الترميز يجب تجنبها
إن تصميم بنية موقع ويب أو تطبيق ما ، أو إعداد سير عمل فعال للترميز ، يجعلنا نتعامل دائمًا مع المشكلات المتكررة. لا نحتاج بالضرورة إلى حل مشكلات تصميم البرامج هذه من البداية ، مثل يمكن إعادة استخدام الحلول على المستوى المعماري في نفس الطريقة كما مقتطفات الشفرة على المستوى الجزئي.
أنماط التصميم عموما حلول قابلة لإعادة الاستخدام لسيناريوهات معينة ، يمكن أن تأتي في متناول اليد لحل المشاكل التي تحدث عادة, ويمكن أن تساعدنا بشكل كبير على تحسين كودنا.
على الرغم من أن أنماط التصميم تعد وسيلة رائعة لتحسين عملية التطوير الخاصة بنا من خلال استخدام صيغ تم اختبارها جيدًا ، إلا أننا في بعض الأحيان قد نخطئ في استخدامها. وتسمى هذه antipatterns.
ما هي مضادات?
المصطلح “النموذج المضاد” تم صياغته في كتاب بعنوان AntiPatterns في عام 1998. وهو يشير إلى الحلول المعاد استخدامها والتي تبدو مفيدة في البداية, ولكن في وقت لاحق تبين لتضر أكثر مما تنفع.
يمكن أن يحدث هذا لأسباب مختلفة ، على سبيل المثال إذا لم نستخدم الأنماط في السياق أو الإعداد أو الوقت المناسب (الحلول التي كانت فعالة في الماضي قد لا تعمل دائمًا في الوقت الحاضر) ، أو في الحالات الأخرى ، يكون النموذج بأكمله كان سيئا فقط من البداية.
وغالبا ما تسمى المضادات أنماط الفشل. والخبر السار هو أنه ممكن التعرف عليها وتجنبها.
في هذا المنشور ، سوف نلقي نظرة على 10 مضادات تشفير شائعة في تطوير الويب والتي قد تخدعنا في التفكير في أننا لدينا كود مُحسن. (لاحظ أن العناصر المضادة المدرجة في هذا المنشور ليست بالضرورة هي نفسها التي يمكنك العثور عليها في الكتاب المذكور أعلاه.)
1. من السابق لأوانه الأمثل
التوقيت الجيد هو عامل حاسم في تحسين الكود. يمكننا بسهولة استنساخ المضاد لل “تحسين سابق لأوانه”, في حالة الاهتمام بالكفاءات الصغيرة وتحسينها مبكرًا في عملية التطوير ، قبل أن نعرف بالضبط ما نريد القيام به.
وفقا لاقتباس دونالد نوث الشهير “التحسين السابق لأوانه هو أصل كل الشرور“, التي قد تكون مبالغة ، لكنها لا تزال توضح مدى خطورة القضايا التي قد يسببها التحسين المبكر.
إذا قمنا بتحسين الأداء قبل إعداد بنية فعالة ، فقد نقوم بذلك انخفاض قراءة التعليمات البرمجية, يصنع التصحيح والصيانة أصعب, و إضافة أجزاء زائدة إلى رمز لدينا.
لمنع التحسين المبكر ، من الجيد اتباع مبدأ البرمجة YAGNI (أنت لست بحاجة إلى ذلك) ، والذي ينصح “قم دائمًا بتنفيذ الأشياء عندما تحتاجها فعليًا ، ولا تتنبأ أبدًا بالحاجة إليها.”
2. إعادة اختراع العجلة
ال “إعادة اختراع العجلة” يشار أحيانًا إلى أنتيبيترن “تصميم في فراغ”. يحدث عندما نريد تفعل كل شيء من قبل أنفسنا و اكتب كل شيء من الصفر, دون البحث عن الأساليب الموجودة بالفعل أو واجهات برمجة التطبيقات أو المكتبات.
إعادة اختراع العجلة ليست مجرد شيء يضيع الوقت ، ولكن أيضًا الحلول المخصصة ، وخاصة للوظائف الأساسية ، نادراً ما تكون جيدة مثل تلك القياسية التي تم اختبارها بالفعل من قبل العديد من المطورين والمستخدمين.
3. التبعية الجحيم
عكس “إعادة اختراع العجلة” antipattern هو مضادات شائعة أخرى تسمى “الجحيم التبعية”.
إذا ، بدلا من كتابة كل شيء من الصفر ، نستخدم الكثير من مكتبات الطرف الثالث التي تعتمد على إصدارات محددة من المكتبات الأخرى, يمكننا بسهولة أن نواجه وضعا يصعب التحكم فيه عندما نريد التحديث ، حيث أن هذه التبعيات الفرعية تكون في كثير من الحالات غير متوافق مع بعضها البعض.
يمكن حل جهنم التبعية باستخدام مديري الحزم القادرين على تحديث بذكاء التبعيات المترابطة. إذا غمرتنا المشكلة أكثر من اللازم ، يمكن أن تكون إعادة التوطين فكرة جيدة أيضًا.
4. كود السباغيتي
“كود السباغيتي” ربما هو الأكثر شهرة antipattern الترميز. انها تصف تطبيق يصعب تصحيحه أو تعديله بسبب عدم وجود بنية مناسبة.
نتيجة لضعف تصميم البرنامج هو مجموعة من التعليمات البرمجية التي تشبه في هيكلها وعاء من السباغيتي ، أي. متشابكة وملتوية. إن سهولة قراءة شفرة السباغيتي منخفضة جدًا ، وعادة ما تكون مهمة مستحيلة تقريبًا لفهم كيفية عملها بالضبط.
السباغيتي الكود عادة ينبع من مزيج من مختلف ممارسات الترميز سيئة, مثل الكود الذي لا يحتوي على كتل شرطية مناسبة ، ولديها الكثير من عبارات goto ، والاستثناءات ، والخيوط ، التي تحتوي على أجزاء تنتمي إلى مكان آخر ، ولديها علاقات دنيا بين الكائنات ، ولها وظائف أو طرق لا يمكن إعادة استخدامها ، أو لم يتم توثيقها بشكل صحيح أو على الاطلاق.
5. البرمجة عن طريق التقليب
“البرمجة عن طريق التقليب” أو “البرمجة عن طريق الصدفة” يحدث عندما نحاول إيجاد حل للمشكلة عن طريق إجراء تجارب متتالية على التعديلات الصغيرة واختبارها وتقييمها واحداً تلو الآخر ، وأخيراً تنفيذ التعديل الذي يعمل أولاً.
البرمجة عن طريق التقليب يمكن بسهولة إدخال أخطاء جديدة في التعليمات البرمجية الخاصة بنا, والأسوأ من ذلك ، أنها أخطاء لا نعترف بها بالضرورة مرة واحدة. في العديد من الحالات ، من المستحيل أيضًا توقع ما إذا كان الحل سينجح في جميع السيناريوهات المحتملة أم لا.
6. نسخ ولصق البرمجة
“نسخ ولصق البرمجة” يحدث عندما لا نتبع مبدأ الترميز "عدم تكرار نفسك" (DRY) ، وبدلاً من إنشاء حلول عامة ، نقوم بإدراج مقتطفات برمجية موجودة بالفعل في أماكن مختلفة ، ثم نقوم بتحريرها لاحقًا لتناسب السياق المحدد.
هذه الممارسة ينتج عنه رمز متكرر للغاية, لأن أجزاء الكود المدرجة عادة ما تختلف فقط في التناقضات البسيطة.
لا يقتصر الأمر على برمجة النسخ واللصق من قِبل المطورين المبتدئين ، ولكن أيضًا المبرمجين المتمرسين أيضًا ، حيث أن الكثير منهم عرضة لذلك استخدام مقتطفات الشفرة المكتوبة مسبقًا والمُختبرة جيدًا لمهام محددة, والتي يمكن أن تؤدي بسهولة إلى التكرار غير المقصود.
7. البضائع العبادة البرمجة
اسم ال “البرمجة البضائع عبادة” يأتي من ظاهرة إثنوغرافية محددة تسمى “عبادة البضائع”. ظهرت طوائف الشحن في جنوب المحيط الهادئ بعد الحرب العالمية الثانية ، عندما أدى الاتصال القسري بالحضارات المتقدمة إلى أن يعتقد المواطنون أن المنتجات المصنعة ، مثل Coca-Cola وأجهزة التلفزيون والثلاجات التي تنقلها سفن الشحن إلى الجزر ، تم إنشاؤها بواسطة خارق للطبيعة أساليب؛ وإذا كانوا يؤدون طقوس سحرية مماثلة لعادات الغربيين ، فإن الشحنة المملوءة بالبضائع ستعود مرة أخرى.
عندما نلتزم بمضاد البرمجة البضائع - عبادة ، ونحن نفعل الشيء نفسه أساسا. نحن نستخدم الأطر والمكتبات والحلول وأنماط التصميم ، وما إلى ذلك التي عملت بشكل جيد مع الآخرين, دون فهم لماذا نفعل ذلك, أو كيف تعمل التقنيات بالضبط.
في كثير من الحالات المطورين فقط تفعل طقوس ما هو الورك في ذلك الوقت دون أي غرض حقيقي. هذه الممارسة ليست سيئة فقط لأنها تجعل تطبيقنا منتفخًا بشكل غير ضروري ، ولكن يمكن أيضًا إدخال أخطاء جديدة في الكود بسهولة.
8. تدفق الحمم البركانية
نحن نتحدث عن “تدفق الحمم البركانية” antipattern عندما نحتاج إلى تعامل مع الكود الذي يحتوي على أجزاء زائدة أو منخفضة الجودة أن يبدو أن لا يتجزأ إلى البرنامج ، ومع ذلك لا نفهم تمامًا ما الذي يفعله أو كيف يؤثر على التطبيق بأكمله. هذا يجعل من المخاطرة إزالته.
عادة ما يحدث مع كود قديم, أو عندما رمز كتبه شخص آخر (عادة بدون وثائق مناسبة) ، أو عندما ينتقل المشروع بسرعة كبيرة من التطوير إلى مرحلة الإنتاج.
يأتي اسم المضاد من التشابه مع الحمم البركانية القادمة ، أي في البداية يتحرك بسرعة وسلاسة دون اتخاذ الكثير من الاحتياطات ، لكنه لاحقًا يصبح صلبًا ويصبح من الصعب إزالته.
من الناحية النظرية ، يمكننا التخلص من تدفقات الحمم البركانية اختبار واسع النطاق و إعادة بناء التعليمات البرمجية, لكن في الممارسة العملية, التنفيذ في كثير من الأحيان صعب أو حتى مستحيل. نظرًا لأن تدفقات الحمم البركانية عادة ما تكون لها تكاليف أداء عالية ، فمن الأفضل منعها عن طريق إنشاء بنية جيدة التصميم وسير عمل سليم من البداية.
9. الترميز الثابت
“الترميز الصعب” هو مضاد معروف ومعروف تحذرنا معظم كتب تطوير الويب من البداية. الترميز الثابت هو الممارسة المؤسفة التي نحن تخزين التكوين أو إدخال البيانات, مثل مسار ملف أو اسم مضيف بعيد, في شفرة المصدر بدلاً من الحصول عليها من ملف تكوين أو قاعدة بيانات أو إدخال مستخدم أو مصدر خارجي آخر.
المشكلة الرئيسية مع رمز الثابت هو ذلك أنها لا تعمل إلا بشكل صحيح في بيئة معينة, و في في أي وقت تتغير الظروف, نحن بحاجة إلى تعديل شفرة المصدر ، وعادة في أماكن منفصلة متعددة.
10. لينة الترميز
إذا حاولنا جاهدين تجنّب ترميز الترميز الصلب ، فيمكننا أن نواجه بسهولة مضادًا آخر يسمى “الترميز لينة”, وهو عكس ذلك تماما.
في الترميز لينة, نضع الأشياء التي يجب أن تكون في شفرة المصدر في مصادر خارجية, على سبيل المثال نقوم بتخزين منطق العمل في قاعدة البيانات. السبب الأكثر شيوعًا وراء قيامنا بذلك ، هو الخوف من تغيير قواعد العمل في المستقبل ، وبالتالي سنحتاج إلى إعادة كتابة الكود.
في الحالات القصوى ، يمكن لبرنامج مشفر لينة تصبح مجردة وملتوية بحيث يكاد يكون من المستحيل فهمها (خاصة بالنسبة لأعضاء الفريق الجدد) ، للغاية من الصعب الحفاظ عليها وتصحيحها.
