سلسلة Swift Package Manager 06｜السيناريوهات والقيود المطبقة على SPM

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

من السهل على SPM أن يقع في هذا الإيقاع أيضًا.

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

لذلك أنا لا أحب أبدًا هذا النوع من الاستنتاج العام:

• “حان الوقت لنقل كل شيء إلى SPM”
• “إذا لم تستخدم SPM، فسوف تتخلف عن الركب.”

السؤال الأكثر عملية يجب أن يكون:

ما إذا كان المشروع مناسبًا حاليًا لترحيل إمكانات معينة إلى SPM، وما إذا كان سيكون أكثر استقرارًا بعد اكتمال الترحيل.

1. الشرط الأساسي لكي تكون مناسبًا لـ SPM هو أن تكون الحدود واضحة.

إذا كان المشروع حاليًا في هذه الحالة:

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

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

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

لذا فإن الترتيب الذي أفضّله هو:

1. دع الحدود تصبح واضحة أولاً
2. إعادة استخدام SPM لاستضافة هذه الحدود

وبدلاً من العكس، توقع أن يساعد SPM تلقائيًا في إنشاء الحدود.

2. ما هو أفضل وقت لبدء استخدام SPM؟

أعتبر بشكل عام الإشارات التالية التي تشير إلى أن المشروع جاهز لتقديم أو توسيع SPM:

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

إذا ظهرت هذه الظروف تدريجيًا، فغالبًا ما يصبح SPM خطوة تالية طبيعية.

3. متى يكون من غير المناسب “إجبار نفسك”؟

يشير مصطلح “التعزيز” هنا إلى النهوض بحركة SPM كمهمة سياسية.

سأكون حذرًا جدًا في المواقف التالية:

1. لا يزال المشروع صغيرًا جدًا، ونقطة الألم الرئيسية ليست حدود الوحدة على الإطلاق.

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

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

2. ليس لدى الفريق إجماع أساسي على الحدود.

إذا كنت متصلاً الآن:

• كيفية التمييز بين الطبقة الأساسية وطبقة الأعمال
• كيفية التمييز بين طبقة الصفحة وطبقة الخدمة
• كيفية التمييز بين الوحدات العامة والوحدات المضيفة

إذا لم يكن هناك إجماع حتى الآن، فلن تقوم SPM إلا بكشف هذه النزاعات مقدمًا، لكنها قد لا تحلها.

3. فقط لكي “تبدو بمظهر متقدم”

وهذا هو أخطر أنواع الدوافع. إذا كان سبب اعتماد SPM هو فقط:

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

هناك احتمال كبير بأن يصبح في النهاية “شكلًا مطورًا وهيكلًا دون تغيير”.

4. الجانب الأكثر سهولة في المبالغة في تقديره في SPM: الاعتقاد بأنه سيؤدي تلقائيًا إلى إنشاء بنية جيدة

لن يحدث ذلك.

نقاط القوة في SPM هي:

• استضافة حدود الوحدة
• التبعيات الصريحة
• جعل تطور الوحدة أكثر طبيعية

لكنها لن تجيب على الفريق:

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

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

5. استراتيجية الهجرة أكثر أهمية من “هل يجب أن تهاجر أم لا؟”

لقد فشلت العديد من المشاريع بسبب “التغييرات الجذرية في القانون”.

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

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

بدلاً من مجرد الخروج:

• تفريغ المستودع بالكامل
• تم فرض جميع التعليمات البرمجية العامة في Package
• ترحيل جميع تبعيات الطرف الثالث مرة واحدة

تعتبر الوحدات مشروعًا طويل المدى وغير مناسب للتقدم بخطوة واحدة.

6. معيار الحكم العملي: بعد استخدام SPM، هل سيكون المشروع أكثر وضوحًا أم أكثر تعقيدًا؟

إذا تم إجراء تغيير بعد الترحيل:

• اتجاه التبعية أكثر وضوحا -مسؤوليات الوحدة أكثر وضوحًا
• من الأسهل الحكم على نطاق التأثير أثناء المراجعة
• حدود الاختبار أكثر طبيعية

إذن هذه الهجرة تستحق العناء على الأرجح.

إذا بعد اكتمال الترحيل:

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

وهذا يعني أن المشكلة ليست في الأداة، بل في تصميم الحدود نفسها.

7. الاستنتاج: SPM يستحق الاستخدام، لكنه لا يستحق استخدامه كهجرة شكلية

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

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

لذا فإن النهج المستقر حقًا هو:

• استخدامه في الوقت المناسب
• ابدأ بالحدود المناسبة
• يستخدم لحمل الهياكل التي تم التفكير فيها بوضوح

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