Swift Package Manager Series 07｜SPM طريقة الإدارة في مشاريع iOS متوسطة الحجم

إذا كنت سأستخدم SPM لإدارة مشروع iOS متوسط الحجم، فإن اهتمامي الأول لن يكون “كم عدد الحزم التي يجب إزالتها”، ولكن هذه الأسئلة الثلاثة:

• ما هي القدرات التي تستحق الاستقلال حقًا؟
• كيفية الحفاظ على اتجاه مستقر لتبعيات الوحدة
• ما الذي يجب الاحتفاظ به في المشروع المضيف وما الذي لا يجب الاحتفاظ به؟

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

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

1. لن أتابع “المزيد من الوحدات” من البداية، ولكن سأتبع أولاً “مستويات واضحة”

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

أهم شيء في هذا الوقت هو إزالة الطبقات أولاً.

عادةً ما أرى أولاً ما إذا كان يمكن فصل فئات الأشياء التالية بشكل ثابت في المشروع:

• طبقة القدرة الأساسية
• طبقة قدرة المجال
• طبقة إعادة استخدام واجهة المستخدم
• طبقة المشروع المضيفة

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

2. سأقوم أولاً بتقسيم الوحدات الأساسية إلى ثلاث فئات.

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

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

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

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

2. وحدة قدرة المجال

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

-الحساب

• المستخدم
• المحتوى
• النظام

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

3. وحدة إعادة استخدام واجهة المستخدم

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

• نظام التصميم
• المكونات المشتركة
• حاوية قائمة عالمية

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

3. ما الذي يجب الاحتفاظ به في المشروع المضيف؟

هذه مشكلة تميل العديد من الفرق إلى التغاضي عنها.

بمجرد البدء في إجراء SPM، فمن السهل أن يكون لديك ميل: “نظرًا لأنها جميعها وحدات، فمن الأفضل للمشروع المضيف أن يكون رفيعًا قدر الإمكان.”

هذا البيان هو نصف صحيح فقط.

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

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

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

4. لن أقوم بتفكيكها بدقة شديدة في البداية.

وهذا أمر أصر عليه بشدة.

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

بمجرد تجزئة الوحدة بشكل كبير، ستظهر المشكلات على الفور:

• الرسم البياني التبعية المعقدة
• يصبح مسار التصحيح أطول
• القفزات المتكررة عبر الوحدات أثناء المراجعة
• يتضمن التغيير البسيط روابط متعددة للحزم

وهذا يمكن أن يدفع الفرق سريعًا إلى الشك في النمطية نفسها.

لذلك أفضّل:

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

عادة ما يتم اختيار النظام بدقة شديدة في المرة الأولى على عجل.

5. اتجاه التبعية أكثر أهمية من عدد الوحدات

إذا طُلب مني الاختيار بين “إزالة المزيد من الوحدات” و"تسوية التبعيات"، فسأختار بالتأكيد الخيار الأخير.

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

على سبيل المثال، أنا أهتم أكثر بما إذا كانت هذه العلاقات ستستمر:

-الطبقة الأساسية لا تعتمد على طبقة الأعمال

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

طالما أن اتجاهات التبعية معطوبة وبغض النظر عن عدد الوحدات الموجودة، فسيكون النظام مجرد “اقتران متداخل متعدد الطبقات”.

6. سأكون حذرًا للغاية بشأن “الوحدات العامة العامة”

هذا هو النمط المضاد الذي يظهر بشكل متكرر في المشاريع متوسطة الحجم.

عندما يتم تقسيم المشروع إلى وحدات في البداية، غالبًا ما يكون هناك سؤال يسمى:

• Common
• Shared
• Core
• Base

وحدات فائقة مثل هذا.

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

• يمكن الاعتماد عليه في أي مكان
• ضع كل شيء هناك
• هناك وظائف الأداة ونماذج الأعمال ومكونات واجهة المستخدم

والنتيجة هي أنها تصبح نقطة الاقتران المركزية الجديدة.

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

7. أهم شيء لتقسيم المشاريع متوسطة الحجم هو الإدراك المتسق للفريق.

هذا واقعي للغاية.

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

• كل ما يتعلق بالصفحة يعتبر وحدة

بعض الناس يعتقدون:

• ينبغي تفكيك نماذج المجال بشكل منفصل

بعض الناس يعتقدون:

• يجب وضع المكونات العامة مع وحدات الأعمال لمزيد من الراحة

إذا لم يتم توحيد هذه الإدراكات لفترة طويلة، فسيستمر النظام في زيادة الصراعات الحدودية حتى مع SPM.

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

• هل تسمية مسؤوليات الوحدة متسقة؟
• هل هناك إجماع على اتجاه التبعية؟
• عند إضافة رمز جديد، هل يمكنك معرفة الطبقة التي يجب وضعها عليها؟

وهذا أكثر أهمية من مجرد “عدد الطرود التي تم فتحها”.

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

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

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

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