سلسلة Swift Package Manager 01｜موقع وأهمية SPM

المرة الأولى التي يتواصل فيها العديد من مطوري iOS مع Swift Package Manager غالبًا ما تكون بسبب “رغبتهم في توصيل مكتبة تابعة لجهة خارجية”. من السهل استخلاص نتيجة ضيقة للغاية:

أليس SPM مجرد بديل لـ CocoaPods؟

وهذا الاستنتاج صحيح جزئيا فقط.

يمكن لـ SPM بالتأكيد تثبيت التبعيات، ولكن إذا فهمتها فقط كمدير تبعية، فسوف تقلل من شأن ما يتغير بالفعل. ما يتغير هو في الواقع كيفية تعريف مشاريع Swift للوحدات النمطية، وكيفية تنظيم التبعيات، وكيفية إنشاء حدود المشروع.

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

1. SPM هو في المقام الأول المدخل الرسمي لنظام الوحدة النمطية لـ Swift، وليس مجرد أداة تنزيل.

القيمة الأساسية للعديد من الأدوات تأتي من البيئة، والقيمة الأساسية لبعض الأدوات تأتي من “ما إذا كان هذا مسارًا رسميًا”.

SPM أقرب إلى الأخير.

وأهميته تنبع أولاً من ثلاث حقائق:

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

هذه النقاط الثلاث مجتمعة تعني أنها أصبحت تدريجيًا اللغة الافتراضية للمؤسسات الهندسية في Swift.

هذا ليس تغييرًا بنفس حجم “أمر آخر لتثبيت التبعيات”.

2. ما يواجهه بالفعل هو مشكلة “الحدود”.

ما يصعب إدارته حقًا في مشروع ناضج هو دائمًا المشكلات التالية:

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

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

• ما هي الواجهة العامة للوحدة؟
• ما هي الوحدات التي يعتمد عليها
• ومن يعتمد عليه
• كيف ينبغي اختباره

لذلك، أقول إن جوهر SPM هو إجبارنا على التفكير بجدية أكبر حول حدود الوحدات.

##أسباب زيادة الأهمية

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

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

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

أصبحت SPM أكثر أهمية لأنها توفر مسارًا قياسيًا أكثر من “مواصلة تكديس الدلائل في المشروع الرئيسي”. يسمح بتغيير حدود الوحدة من اتفاقية إلى بنية هندسية حقيقية.

4. الفرق الأكبر بين إدارة الأداء الاستراتيجي (SPM) وأدوات الاعتماد في العصر القديم لا يقتصر على الخبرة فحسب، بل على تحديد موقع الدور

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

• ساعدني في تثبيت مكتبة الطرف الثالث
• ساعدني في الإصدارات والتكاملات

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

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

في هذا الوقت، لم تعد القضايا المثيرة للقلق تقتصر على:

• هل يمكن تثبيته؟

بدلاً من ذلك:

• كيفية تحديد واجهة الوحدة النمطية
• كيفية إخفاء التنفيذ الداخلي
• كيفية الحفاظ على التبعيات في اتجاه واحد
• ما هي الوحدات التي تستحق الاختبار المستقل

هذا هو المكان الذي يبدأ فيه النضج الهندسي في الزيادة.

5. ستصل العديد من الفرق إلى SPM عاجلاً أم آجلاً

ظاهريًا، يبدو الأمر وكأنه “مُحدَّث”، لكنه في الواقع أقرب إلى كيفية تنظيم مشاريع Swift الحديثة.

طالما أن الفريق يبدأ في القيام بهذه الأمور بجدية، فمن الطبيعي أن يقترب من SPM:

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

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

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

يجب تجنب سوء فهم آخر هنا: عند ذكر موضوع SPM، فمن السهل مساواة ذلك بـ “الفريق الناضج المعياري”.

وهذا في الواقع غير دقيق.

SPM في حد ذاته لا يؤدي تلقائيًا إلى بنية جيدة. إذا لم تفكر في الأمر بوضوح في المقام الأول:

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

لقد أدى ذلك إلى نقل الفوضى الأصلية من دليل المشروع الرئيسي إلى دليل الحزمة.

ولذلك، فإن قيمة SPM لا تكمن في “جعلها حديثة”، ولكن في أنها تجعل العديد من القضايا الحدودية التي كان من الممكن أن تكون غامضة في الماضي لم تعد في النهاية قادرة على أن تكون غامضة.

7. لن يحل أي شيء تلقائيًا

وهذا مهم أيضًا. لا يساعد SPM تلقائيًا في حل ما يلي:

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

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

إذا لم يكن لدى الفريق وعي بالحدود في البداية، فقد ينتهي الأمر بـ SPM إلى تغليف المشكلة بطريقة أكثر “حداثة”.

8. الخلاصة: أصبح SPM أكثر أهمية. ظاهريًا، يبدو أنه يمكنه تثبيت المكتبات، لكنه في الواقع أقرب إليه وأكثر ملاءمة لاستضافة المشاريع المعيارية.

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

السبب وراء تزايد أهمية SPM هو أنه يبدو ظاهريًا أنه يسمح لنا أخيرًا بتثبيت عدد أقل من CocoaPods. في الواقع، إنه أقرب إلى تسهيل الأمر على مشاريع Swift لتحويل حدود الوحدات والتبعيات وهياكل المشروع إلى تصميمات واضحة.

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

• وحدات
• التقييس
• جعل الحدود واضحة

ولهذا السبب يستحق الأمر أن يؤخذ على محمل الجد بشكل متزايد.