Swift Package Manager Series 02｜قم بإنشاء أول حزمة Swift

تركز العديد من البرامج التعليمية التي تتحدث عن “إنشاء حزمة Swift الأولى” على الأوامر أو إجراءات Xcode.

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

نظرًا لأنها كانت المرة الأولى التي أقوم فيها بإنشاء حزمة Swift الخاصة بي، فإن ما بدأ يتغير حقًا هو الطريقة التي فكرت بها في الأمر:

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

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

1. لا تتعجل في بناء الحزمة أولاً. اسأل أولاً ما إذا كان يجب أن يستمر هذا الرمز في البقاء في المشروع الرئيسي.

هذه هي الخطوة التي أهتم بها أكثر.

من المواقف الشائعة أن نقول: “دعونا نجعلها نموذجية”. ولكن ما يستحق التساؤل حقاً هو:

لماذا يجب فصل هذا الكود عن سياق المشروع الحالي ويصبح وحدة مستقلة؟

تشمل الأسباب المشروعة الشائعة ما يلي:

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

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

الحزمة لا تستخدم لتخزين الملفات، بل تستخدم للتعبير عن الحدود.

2. أنسب شيء لاستخراجه لأول مرة هو عادةً القدرات الصغيرة ذات الحدود الواضحة.

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

• الصفحة الرئيسية كاملة
• نظام الحساب كاملا
• وحدة الدفع بأكملها

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

تلك التي تكون أكثر ملاءمة للدفعة الأولى من الحزم عادةً ما تتمتع بالإمكانيات التالية:

-القدرات الأساسية لطبقة الشبكة

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

السمات المشتركة لهذه الوحدات هي:

• اعتماد أقل
• مسؤولية واحدة
• الحدود واضحة نسبيا

إنها أكثر ملاءمة لمساعدة الفريق في تكوين إحساس بـ “ما هي الوحدة المستقلة”.

3. عند إنشاء حزمة لأول مرة، الشيء الأكثر أهمية هو الواجهة العامة

الموقف الشائع هو أنه بعد إنشاء الحزمة الأولى، ستركز على الفور على كيفية ترتيب الدليل. لكن من منظور هندسي، الأهم حقًا هو:

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

يمكنك التفكير في إنشاء حزمة كضبط للنفس:

• ما هي الأنواع التي تستحق التعريض لها كـ public؟
• ما هي الوظائف المساعدة التي يجب أن تظل داخلية فقط؟
• ما هي التبعيات التي لا ينبغي أن تكون معروفة للمتصل

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

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

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

من السهل أن تخطئ في هذا التسلسل.

الترتيب الصحيح يجب أن يكون عادة:

1. قم أولاً بتوضيح مسؤوليات هذه القدرة
2. دعونا نرى ما إذا كانت تستحق أن تكون وحدة مستقلة.
3. أخيرًا قم باستضافته في شكل حزمة

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

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

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

5. القضايا الأربع التي أهتم بها كثيرًا عند إنشاء الحزمة لأول مرة

إذا كنت أقوم بمراجعة الحزمة الأولى للفريق، فإن الأسئلة الأربعة التي أطرحها غالبًا هي:

1. هل تتضمن هذه الوحدة مسؤولية واحدة واضحة؟

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

2. ما إذا كانت تبعياتها قليلة بما فيه الكفاية

عند إنشاء حزمة لأول مرة، كلما قل عدد التبعيات، أصبح النجاح أسهل. عندما يكون هناك الكثير من التبعيات، تصبح الحدود غير واضحة.

3. هل الواجهة العامة أصغر بكثير من الواجهة الداخلية؟

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

4. هل يستحق الأمر إجراء اختبار مستقل؟

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

6. معيار النجاح لأول مرة هو “التفكيك المستقر”

عندما تقوم العديد من الفرق بتطبيق الوحدات لأول مرة، فمن المرجح أن يسعوا وراء “الإحساس بالنتائج”، مثل:

• إزالة 10 وحدات دفعة واحدة
• يتم إدخال كافة التعليمات البرمجية العامة في Package
• المشروع الرئيسي فقد الكثير من الوزن على الفور

ولكن في المشاريع الحقيقية، عادة ما تكون المعايير الأكثر أهمية للنجاح لأول مرة هي:

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

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

7. الخلاصة: حزمة Swift الأولى تعلمنا حقًا كيفية تنظيم التعليمات البرمجية وفقًا للحدود.

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

المعنى الحقيقي لإنشاء أول حزمة Swift هو إجبارك على الإجابة بجدية لأول مرة “لماذا يستحق هذا الرمز أن يكون وحدة مستقلة”.

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