Swift Package Manager Series 04｜حدود الأكواد المناسبة للتضمين في الحزم

أحد الأخطاء الأكثر شيوعًا التي ترتكبها العديد من الفرق عندما تبدأ في تطبيق الوحدات لأول مرة هو:

قرر أولاً إزالة الوحدة، ثم فكر في سبب وجود الوحدة.

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

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

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

ما إذا كانت الوحدة تستحق الإزالة أم لا يعتمد على ما إذا كانت لها حدود طبيعية.

عادة ما ينعكس ما يسمى بالحدود الطبيعية في:

• ويتولى مجموعة واحدة نسبيا من المسؤوليات
• اتجاه التبعية واضح نسبيا
• لا يحتاج إلى معرفة الكثير عن سياق المشروع المضيف
• من المحتمل إعادة استخدامه في سيناريوهات متعددة في المستقبل

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

المبدأ الأول للنمطية هو “الحدود موجودة بالفعل، أنا فقط أوضحها”.

2. غالبًا ما تكون المجموعات الأقل ملاءمة للإزالة في الدفعة الأولى عبارة عن كتل أعمال كبيرة مقترنة بقوة بالصفحة.

عندما بدأت في القيام بذلك لأول مرة، عندما كنت أقوم بتطبيق الوحدات النمطية، كانت الأشياء التي كنت أميل إلى تفكيكها هي:

• الصفحة الرئيسية
• مركز الحساب
• عملية الدفع
• تفاصيل المحتوى

بالطبع هذه الوحدات مهمة، لكنها غالبًا ما تكون مقترنة بعمق بالأشياء التالية:

• التوجيه -دورة حياة التطبيق المضيف
• حالة الصفحة
• دفن النقطة
• موارد واجهة المستخدم

فإذا انطلقت من هذه الأماكن للانقسام الأول فلن تكون الحدود واضحة، وسيكون من السهل ظهورها:

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

ولذلك، فإن ما هو أكثر ملاءمة للهدم لأول مرة هو عادة “الكتلة ذات الحدود الأوضح”.

3. عادةً ما يكون للكود المناسب للتضمين في الحزمة ثلاثة أشكال نموذجية:

1. وحدة القدرة الأساسية

على سبيل المثال:

• سجل
• تغليف الشبكة
• ذاكرة التخزين المؤقت المحلية
• قراءة التكوين

السمات المشتركة لهذه الإمكانات هي المسؤوليات الواضحة واستقلالية الصفحة ومساحة إعادة الاستخدام الكبيرة.

2. نموذج المجال أو وحدة خدمة المجال

على سبيل المثال:

• نموذج المستخدم والاستعلام عن معلومات المستخدم
• كائنات مجال المحتوى ومستودع المحتوى
• ترتيب منطق المجال

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

3. وحدة المكونات الأساسية لواجهة المستخدم المستقرة

على سبيل المثال:

• تصميم المكونات الأساسية للنظام
• نظام النمط العالمي
• العديد من المكونات التفاعلية دون اقتران الأعمال

الفرضية هي أنها مستقرة حقًا ولا تسرق دلالات خاصة بالصفحة.

4. سوء فهم شائع جدًا: التقسيم حسب الدليل وليس حسب اتجاه التبعية

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

الأسئلة الأكثر شيوعًا هي: كيفية تقسيم المجلدات في الماضي هي الآن كيفية تقسيم الوحدات.

على سبيل المثال:

• Home/
• User/
• Common/
• Utils/

على السطح يبدو وكأنه وحدة نمطية، ولكن في الواقع سوف تواجه قريبا:

• Home يعتمد على User
• User يعتمد على Common
• يحتوي Common في الواقع على مجموعة من منطق الأعمال المختلط
• Utils في النهاية، أصبحت سلة مهملات بكل ما هو محشو فيها.

وهذا يدل على أن ما يتم تقسيمه هو الدليل، وليس الحدود.

يجب النظر إلى طريقة التفكيك الأكثر استقرارًا حقًا من اتجاه التبعية:

• ما هي الوحدات التي لا يمكن الاعتماد عليها إلا للأسفل
• ما هي القدرات العامة الكامنة وراءها
• ما هي طبقات منطقة الأعمال؟
• ما هي تلك الحصرية للطبقة المضيفة؟

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

5. لا تخفي تبعيات النمطية

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

• وحدات عامة كبيرة جدًا
• رسم الاتفاقيات في كل مكان
• ضعي “طبقة تجسير” في المنتصف

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

إذن ما يهمني أكثر هو:

• ما إذا كانت علاقة التبعية الحالية معقولة من الناحية التجارية
• هل تم فصل الوحدات بسبب اختلاف المسؤوليات الحقيقية؟
• أم أنها مجرد للتحايل على القيود المفروضة على الأداة؟

إن النمطية الصحية حقًا هي عندما يتم وضع أداة التوصيل بشكل واضح في الاتجاه الصحيح.

6. حكم عملي: إذا تم حذف هذه الوحدة، فهل سيظل المشروع المضيف يفهمها؟

هذه طريقة شائعة جدًا للحكم على نفسي.

إذا قمت بسحب وحدة مرشحة، اسأل نفسك:

• هل ما زال فهم المشروع المضيف له واضحا؟
• هل يحتاج المتصل الخارجي فقط إلى معرفة الواجهة دون معرفة الكثير من التفاصيل الداخلية؟ -ما إذا كان لا يزال مفهومًا كاملاً بعد مغادرة المضيف

إذا كانت الإجابة “نعم”، فعادةً ما تكون الحزمة أكثر ملاءمة. إذا كانت الإجابة “لا”، فربما لا يزال الأمر مجرد مجموعة من تفاصيل التنفيذ داخل المضيف.

7. عند التفكيك لأول مرة، من الأفضل تفكيكه بشكل أقل من تفكيكه إلى قطع.

عند القيام بالنموذجية لأول مرة، من السهل الوقوع في فخ “الآن بعد أن بدأنا في تفكيكها، فلنفككها أكثر”. لكن أحد أكثر حالات الفشل شيوعًا في المشاريع متوسطة الحجم هو أن الوحدات مجزأة جدًا.

بمجرد أن تكون الوحدة مجزأة للغاية، سترتفع التكلفة بسرعة:

• الرسم البياني للتبعية أكثر تعقيدًا
• علاقات التجميع أكثر صعوبة في الفهم
• تعد إدارة الإصدار والحدود أكثر إزعاجًا
• عند المراجعة، عليك التنقل ذهابًا وإيابًا عبر العديد من الوحدات

لذلك عند التقسيم لأول مرة، أفضل:

• قم أولاً بإزالة بعض الوحدات ذات الحدود الواضحة
• مراقبة عدة تكرارات
• قرر ما إذا كنت تريد مواصلة التحسين

الخوف الأكبر من النمطية هو أن الخطوة الأولى هي تقسيم النظام إلى العديد من القطع الصغيرة التي تبدو مستقلة ولكنها في الواقع متشابكة مع بعضها البعض.

8. الخلاصة: ما هو مناسب للتضمين في الحزمة هو “القدرة ذات الحدود الواضحة”

ولكي أختصر الأمر أقول:

إن مفتاح الحكم على ما إذا كان جزء من التعليمات البرمجية مناسبًا للتضمين في الحزمة ليس هو عدد الملفات الموجودة به، ولكن ما إذا كان لديه حدود مسؤولية واضحة نسبيًا، واتجاهات التبعية، ودلالات مستقلة.

إذن ما يهم حقًا هو:

• تفكيك
• وفقا لأي حدود؟
• هل أصبح اتجاه التبعية أكثر وضوحا بعد التفكيك؟

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