هناك 3 مشاكل في التعليمات البرمجية التي تواجهها في البرمجة: Hardcode و Govnokod و Schizokod.
لنتحدث عنه.
كود صلب
هذه مشكلة معروفة جيدًا عندما يكتب المبرمج ، بسبب الاندفاع أو الكسل ، التعليمات البرمجية دون اعتبار للمتغيرات. ولعل الحالة الأكثر شيوعًا هي نطاق الموقع. يمكن أن تختلف من بيئة إلى أخرى وغالبا ما تسبب الكثير من المتاعب. كل شيء بسيط هنا. في منصات مختلفة ، يتم حل هذا بطرق مختلفة. الشيء الرئيسي هو الامتثال للاتفاقيات والقواعد المعتمدة داخل المنصة.
عادة ، يتم اكتشاف مشاكل هذه الفئة بسرعة ومعالجتها بسهولة.
جوفنوكود
هذه مشكلة أكثر صعوبة. غالبًا ما تكون ذاتية. من الناحية التقريبية ، يعد هذا انتهاكًا لأسلوب التعليمات البرمجية المعتمد في الرأس أو الفريق أو المجتمع.
هناك أنماط مختلفة من التعليمات البرمجية اعتمادًا على النظام الأساسي وحتى في بعض الأحيان داخل النظام الأساسي:
هذا من عالم php. في مجتمعات أخرى ، الوضع مشابه. يتضمن هذا أيضًا قصصًا حول علامة التبويب أو علامة التبويب بعد مسافتين أو علامة التبويب بعد 4 مسافات ، إلخ.
هنا تنشأ مشكلة الشفرة الخالصة ... على سبيل المثال ، الوظائف الطويلة من 3-4 صفحات ، والتي يتم انتقادها. هذا ليس دائمًا سيئًا بالتأكيد ، ولكن غالبًا ما يكون من الممكن جعل هذه الوظائف أقصر ، لتقسيمها إلى سلسلة من الوظائف القصيرة ، كل منها يحل مشكلته الخاصة.
عادة ، يتم معالجة هذه المشاكل بسهولة من خلال البرمجيات والتحكم في المعايير المقبولة في فريق معين.
الأكروبات ، عندما يمكن للمطور التبديل بين أنماط مختلفة من التعليمات البرمجية اعتمادًا على المشروع.
إنه أمر سيئ عندما ينتهك مطور البرامج نمط الشفرة الذي يتبناه الفريق أو يعتبر أن نمط الشفرة المفضل لديه (غالبًا ما يكون الوحيد الذي تم تعلمه) هو الرمز الصحيح الوحيد.
لا توجد أنماط رمز صحيحة. هناك أنماط معتمدة في الفريق أو أنماط مقبولة بشكل عام.
أيضا مشكلة بسيطة نسبيا وحلها بسهولة.
الفصام
هذه مشكلة أقل شيوعًا ، ولكن غالبًا ما تكون الأكثر تكلفة.
الفصام - يأتي من مفهوم الفصام. ضغط من ويكيبيديا:
الفصام (من اليونانية الأخرى: split "انقسام" ، "انقسام" + φρήν - "عقل ، تفكير ، فكر") ، خط العرض سابقًا. الخرف praecox ("الخرف المبكر") أو الفصام هو اضطراب عقلي متعدد الأشكال أو مجموعة من الاضطرابات النفسية المرتبطة بانهيار عمليات التفكير وردود الفعل العاطفية.
هناك نقطتان مهمتان: الانقسام والخرف. التي هي أسباب الفصام.
الرمز المثالي هو الذي لم يكتب. الفصام ليسوا على دراية بهذا المفهوم.
باختصار ، إن الفصام هو رمز ينتهك مبدأ Occam's Razor.
ضغط من ويكيبيديا:
"شفرة حلاقة أوكام" هو مبدأ منهجي ، سمي على اسم الراهب الإنجليزي فرانسيسكان ، الفيلسوف الاسمي ويليام أوكهام. في صيغة مبسطة ، تقرأ: "لا يجب أن تضاعف الوجود دون الحاجة"
يتم التعبير عنه في حقيقة أن المطورين يبدأون في تعقيد الكود والهندسة المعمارية دون سبب وجيه. أو وزن الأسباب موجود فقط في مخيلتهم.
مشاكل وهمية - جذر البرمجيات السيئة
هناك نوعان من الأعراض الرئيسية: اختراع الدراجات على العكازات وتكاثر طبقات التجريد.
اختراع الدراجات على العكازات
من المعلوم أن المطورين ، بالنظر إلى ضعف القدرة على التعلم ، بدلاً من البحث عن حلول / طرق مثالية في إطار المنصة والبنية الحالية ، يبدأون في اختراع الدراجات / العكازات.
أمثلة:
- كتابة أطر CMS / ptm الخاصة بك التي تحتوي على أطر عمل عيب قاتل
- مدونة Symfony على الرغم من حقيقة أن العالم كله يستخدم WordPress لهذا الغرض.
- متاجر عبر الإنترنت على Laravel ، على الرغم من حقيقة وجود WooCommerce (رقم 1 في العالم) ، Magento (جيد أيضًا) ، 1C-Bitrix (في أسوأ الأحوال ، أفضل من Laravel)
- لقد قابلت موقفًا عندما كان التخطيط على Bootstrap ، لكن المطور قرر كتابة أنماطه الخاصة للملصقات. ما الذي منعك من إضافة فئة الملصق الموجودة بالفعل في Bootstrap؟
- الدوال والأساليب والفصول الزائدة لا تحتوي على حساب يمكن تجنبه باستخدام المكتبات والأساليب الجاهزة في المنصات المستخدمة
الانتشار غير المنضبط لطبقات التجريد: الطبقات الإضافية والميراث والأساليب
يمكن للقارئ اليقظ أن يلاحظ تعارضًا مع govnokod. في إحدى الحالات ، تكمن المشكلة في أن الوظيفة أو الفئة طويلة جدًا ، لكن المشكلة هي أنه على العكس من ذلك ، هناك تجزئة مفرطة للكيانات.
هنا تجدر الإشارة إلى أن هذا هو أحد التطرف ، ليس من السهل دائمًا مراقبة حدوده.
من ناحية ، من السيئ محاولة حل كل شيء بوظيفة واحدة في 3 صفحات أو فئة تحتوي على HTML وميكانيكا القوالب ، وفي مكان ما يكون أكثر ربحية تقسيم الشفرة إلى العديد من الوظائف / الفئات / المكونات ، كل منها يحل مشكلته الخاصة. هذا متطرف.
من ناحية أخرى ، يتم تقسيم رمز بسيط للغاية إلى 5 فئات ، كل منها يحتوي على 3-4 طرق من 3-4 خطوط ، مع العديد من الميراث عديمة الفائدة ، عندما يمكنك القيام بواحد أو اثنين مع الحد الأدنى من الميراث أو حتى بدون الميراث إذا كان من الممكن تجنب ذلك.
عواقب التجريدات الزائدة والسيئة
نشر الأساليب والطبقات والميراث بدون سبب وجيه - هذا هو رمز غير ضروري ونمو طبقات التجريد.
كل شيء له سعر ، بالإضافة إلى تجريدات إضافية:
- مدلل تدريب المطور الجديد
- لمزيد من التعليمات البرمجية ، والمزيد من نقاط الفشل ، والمزيد من الأخطاء
- التشخيص وتصحيح الأخطاء البرمجية معقدة
مشكلة الفكر
وكلما زادت طبقات التجريد والميراث والأساليب ، زادت الحاجة إلى وقود التفكير للتغييرات والتحسينات وتشخيص المشكلات.
وحجم العمل من الوقود محدود وغالباً ما ينطوي نقصه على تكاليف تطوير كبيرة جدًا.
كل مطور قام بالتشخيص وتغيير الفصام استقر على نقص وقود التفكير. ولكن لم يكن الجميع على علم بذلك.
مقطع فيديو يشرح ما يفكر فيه الوقود ويعطي تمرينًا بسيطًا لمدة دقيقة واحدة ، والذي يسمح لك بتذكر الشعور بنقص الوقود في مثال بسيط:
وهل تصطدم بـ OOP والطبقات والميراث؟
لا على الإطلاق. ومع ذلك ، هناك بعض الحقيقة في ذلك. في أسلوب وظيفي ، من السهل نوفوكوفوديت ، ولكن schizokod من الصعب هناك. يوفر OOP ، من ناحية ، العديد من المزايا ، ولكنه يفتح أيضًا مجالًا للفصام.
OOP ، والطبقات ، والميراث ليست سيئة ولا جيدة. هذه هي الأدوات. أنا شخصيا استخدمهم.
ومع ذلك ، لدي عدد من القواعد الخاصة بي:
- دائمًا ما أكتب دروسًا بسبب التغليف ، ولكن غالبًا ما يكون لدي ما يكفي من Singleton والأساليب الثابتة وعديمي الجنسية
- عندما تكون هناك طريقة شائعة الاستخدام ، أكتب وظائف غالبًا ما تكون مجرد أغلفة لطرق فئة ، ولكن في بعض الأحيان تكون الوظيفة مجرد وظيفة بدون فئة وهذا جيد عند الاقتضاء.
- فصول دراسية - نعم ، ولكن في كثير من الأحيان ومرة أخرى فقط حيث توجد أسباب وجيهة
- الميراث أكثر ندرة ، وفقط عندما يكون هناك أسباب وجيهة لذلك (أحاول تقليل طبقات التجريد وحفظ الفكر والوقود في فريق)
الملخص
نتحدث كثيرا عن كود الثابت و govnokode لأنه فهي مفهومة وملموسة بسهولة. لكن الفصام غالباً ما يفلت من العقاب ، لأنه من الصعب تحديد وفهم مقدار الضرر الناتج عنه. ومقدار الضرر منه ربما يكون أكثر مما يمكن تخيله بضربة.
بياني بسيط:
- من الأفضل تعلم مبدأ أفضل السلالات قبل اختراع دراجة عكاز أخرى لا يحتاجها أحد
- دعنا نكتب فصامًا أقل
- دعونا نتعلم الامتثال لمبدأ Occam's Razor وعدم تعقيد الشفرة بدون سبب
- دعونا حفظ أفكارنا وفريقنا
حسنًا ، يسعدني أن أعلق على كل من دعم البيان وانتقاده.