في رأيك، ما الذي يجعل الناس ينفد صبرهم عندما يتولون التعليمات البرمجية القديمة؟ UML معقدة للغاية؟ أنا لا أعتقد ذلك. وجوابي هو إذا كان مع أكثر من حالتين أخريين، أو التبديل مع أكثر من حالتين. ولكن هل من الطبيعي استخدام الكثير من حالات if else وتبديل الحالات في الكود الخاص بك؟ خطأ! يجب ألا تظهر معظم حالات if else وswitch التي تحتوي على أكثر من فرعين في نموذج مرمز.
من أين تأتي الفروع المعقدة؟
أولًا، السؤال الأول الذي نريد مناقشته هو سبب وجود العديد من الفروع المعقدة في الكود القديم. غالبًا ما لا توجد هذه الفروع المعقدة في الإصدار الأول من الكود، وعلى افتراض أن المصمم لا يزال لديه بعض الخبرة، فيجب عليه توقع المجالات التي قد تحتاج إلى توسيع في المستقبل وحجز الواجهات المجردة .
ومع ذلك، بعد مرور التعليمات البرمجية بعدة تكرارات، خاصة بعد إجراء عدة تعديلات على تفاصيل المتطلبات، ستظهر فروع معقدة. غالبًا لا تنعكس التعديلات التفصيلية للمتطلبات في UML، ولكنها تنعكس مباشرة في التعليمات البرمجية. على سبيل المثال، تم تقسيم الرسائل في الأصل إلى فئتين: رسائل الدردشة ورسائل النظام، أثناء التصميم، تم تصميمها بشكل طبيعي كفئتين فرعيتين من فئة الرسائل. ولكن في أحد الأيام، يتم تعديل المتطلبات بالتفصيل، حيث تكون بعض رسائل النظام مهمة ويجب أن تظهر عناوينها باللون الأحمر، وفي هذا الوقت يقوم المبرمجون غالبًا بإجراء التعديلات التالية:
أضف سمة مهمة إلى فئة رسائل النظام
أضف فرعًا حول السمة المهمة في طريقة العرض المقابلة للتحكم في لون العنوان. لماذا يقوم المبرمج بإجراء مثل هذا التغيير؟ ربما لأنه لم يدرك أنها يجب أن تكون مجردة. نظرًا لأن المتطلب ينص على أن "بعض رسائل النظام مهمة"، بالنسبة للمبرمجين الذين تلقوا المزيد من التدريب على لغات البرمجة الحتمية، فإن أول شيء قد يفكرون فيه هو بت العلم - يمكن لبت العلم التمييز بين المهم وغير المهم . مهم. ولم يتوقع أن يتم تفسير هذا المطلب بطريقة أخرى، "تنقسم رسائل النظام إلى فئتين: مهمة وغير مهمة". وبتفسيره بهذه الطريقة، عرف أنه يجب تجريد رسائل النظام.
من الممكن، بالطبع، أن يعرف المبرمج أن التجريد ممكن، لكنه لسبب ما اختار عدم القيام بذلك. هناك موقف شائع جدًا وهو أن يقوم شخص ما بإجبار المبرمجين على التضحية بجودة التعليمات البرمجية مقابل التقدم في المشروع، حيث تكون إضافة خاصية وفرع أسهل بكثير من إعادة البناء المجردة. إذا كنت تريد إجراء 10 من هذا النموذج، فهل من الأسرع إنشاء 10 فروع أم 10 تجريدات؟ الفرق واضح.
وبطبيعة الحال، إذا كان هناك عدد كبير جدًا من الحالات الأخرى، فسوف يقف بعض الأشخاص الأذكياء ويقولون: "لماذا لا نحولها إلى حالة تبديل؟" في بعض الحالات، يمكن أن يؤدي ذلك بالفعل إلى تحسين إمكانية قراءة التعليمات البرمجية، على افتراض أن كل فرع يستبعد الآخر. ولكن عندما يزيد عدد حالات التبديل، سيصبح الرمز أيضًا غير قابل للقراءة.
ما هي عيوب الفروع المعقدة؟
ما هي عيوب الفروع المعقدة؟ اسمحوا لي أن آخذ جزءًا من الكود القديم لإصدار الويب Baidu Hi كمثال.
التبديل (json.result) {
حالة "موافق":
التبديل (json.command) {
حالة "الرسالة":
حالة "رسالة النظام":
إذا (json.content.from == ""
&& json.content.content == "ركل") {
/* قطع الاتصال */
} وإلا إذا (json.command == "systemmessage"
||.json.content.type == "sysmsg") {
/* تقديم رسالة النظام */
} آخر {
/* عرض رسالة الدردشة */
}
استراحة؛
}
استراحة؛
المصدر: تجربة مستخدم بايدو