Swift Package Manager Series 05｜الوصول إلى حزم الطرف الثالث وإدارتها في مشاريع iOS

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

• هل يمكن الوصول إلى هذه المكتبة من خلال SPM؟
• هل يستطيع Xcode التعرف عليه؟
• كيفية كتابة رقم الإصدار

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

لأنه بمجرد دخول تبعيات الطرف الثالث إلى المشروع، فسوف يؤدي ذلك إلى سلسلة كاملة من المشكلات طويلة المدى:

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

لذا فإن الصعوبة الحقيقية في “إدارة حزم الطرف الثالث” تكمن في الإدارة.

1. قبل قبول تبعيات الطرف الثالث، أول شيء يجب طرحه هو “هل ستدخل الحدود الأساسية؟”

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

• كم عدد النجوم هناك؟
• هل الوثيقة جميلة؟

بدلاً من ذلك:

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

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

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

لذلك أنا قلق أكثر بشأن ما إذا كان يدخل “طبقة الحافة” أو “طبقة العمود الفقري”.

2. لا تدع كود العمل يعرف بشكل مباشر الكثير من التفاصيل الخاصة بمكتبة الطرف الثالث

هذه هي التجربة الأكثر سهولة التي يمكن التغاضي عنها، ولكنها الأكثر أهمية.

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

• عرض طبقة الواردات مباشرة
• يعرف ViewModel أيضًا نوعه
• طبقة الأداة تعتمد عليها أيضًا

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

لذلك عادة ما يكون النهج الأكثر استقرارًا هو:

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

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

3. يجعل SPM الوصول أسهل، ولكنه يمكن أيضًا أن يجعل “إضافة تبعية” أمرًا تافهًا للغاية.

هذا هو أحد الآثار الجانبية الحقيقية للغاية.

نظرًا لأن الوصول إلى SPM سهل للغاية، فإن العديد من الفرق ستطور هذه العادة ببطء:

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

إنها فعالة جدًا على المدى القصير، لكن المشاكل طويلة المدى سوف تتراكم تدريجيًا:

• توسيع التبعية
• تصبح سلسلة التجميع أطول
• بعض المكتبات لم تتم صيانتها لفترة طويلة
• تتداخل وظائف المكتبة المتعددة
• هناك تبعيات كثيرة في المشروع “لا يستطيع أحد تفسير سبب وجودها”

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

4. يكمن جوهر إدارة الإصدار في ما إذا كانت استراتيجية الترقية واضحة أم لا

عندما علمت لأول مرة بهذا المحتوى الخاص بإصدار SPM، كنت أولًا انتبه إلى ما يلي:

• النسخة الدقيقة
• نسخة النطاق
• upToNextMajor

يجب معرفة هذه القواعد، لكن الأسئلة الهندسية الأكثر أهمية هي في الواقع:

• ومن المسؤول عن الارتقاء بهذه التبعية؟
• كم مرة لمراجعة الإصدارات
• هل يجب أن تتبع الترقية احتياجات العمل أم يجب إدارتها بانتظام؟
• كيفية تقييم التأثير بسرعة عند فشل الترقية

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

لذا فإن الاعتماد على إدارة الإصدار يعد في الأساس مشكلة تتعلق بإيقاع الإدارة.

5. أكثر ما يخيفني بشأن الاعتماد على الطرف الثالث هو “لن ينظر إليه أحد بعد الدخول إلى النظام”

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

• التحديثات الأمنية متخلفة لفترة طويلة
• ينفجر تراكم تغيير واجهة برمجة التطبيقات (API) إلى ترقية
• لا أحد في الفريق يعرف من يعتمد أيضًا على هذه المكتبة
• يتم فرض مكتبات ذات قدرة مماثلة بشكل مستمر

ثم سيدخل المشروع ببطء إلى الحالة:

• التبعيات ليست غير صالحة للاستعمال
• ولكن لا أحد يجرؤ على التحرك

يعد هذا أكثر شيوعًا وأصعب في التعامل معه من “اختيار المكتبة الخاطئة في المقام الأول”.

6. ما أقدره أكثر هو ما إذا كانت قائمة التبعيات “قابلة للتفسير”

إن قائمة التبعيات السليمة للمشروع ليست بالضرورة قصيرة، ولكن يفضل أن تكون قابلة للتفسير.

بمعنى آخر، عند اختيار التبعية، يمكن للفريق أن يذكر بوضوح:

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

إذا أصبحت التبعية:

• “لقد كان هناك من قبل”
• “يبدو أنه يستخدم في مكان ما”
• “احذفه خوفا من حدوث شيء”

ثم دخلت بالفعل منطقة خارجة عن السيطرة فيما يتعلق بالحوكمة.

7. استراتيجية عملية: معالجة تبعيات الطرف الثالث في طبقات

عادةً ما أقوم بتقسيم التبعيات إلى ثلاث فئات:

1. التبعية الهامشية

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

2. تبعية النظام الأساسي

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

3. التبعيات المقترنة بعمق مع إمكانية الاستبدال الضعيفة

بمجرد اتصال بعض المكتبات، فإنها ستؤثر على عدد كبير من تصميمات واجهة برمجة التطبيقات (API). وهذا النوع من الاعتماد يتطلب حدودًا واضحة في البداية، وإلا فإن تكلفة الاستبدال ستكون مرتفعة جدًا في المستقبل.

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

8. الخلاصة: جوهر حزمة الطرف الثالث هو الحوكمة طويلة المدى

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

عند إدارة حزم الجهات الخارجية في مشروع iOS، ما يهم حقًا هو “بعد دخولها إلى النظام، هل يمكنك التحكم في حدودها وترقية الإيقاع وتكاليف الاستبدال؟”

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