SwiftUI Series 15｜قم ببناء مشروع SwiftUI قابل للصيانة من البداية

إذا طُلب مني إنشاء مشروع SwiftUI من الصفر، فإن أول شيء سأفكر فيه لن يكون شكل الدليل، ولن أقلق عليه أولاً:

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

ما أفكر فيه أولاً هو هذه الأشياء:

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

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

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

لذا فإن ما تريد “قابلية الصيانة” حله حقًا هو الاستقرار بعد النمو، وليس سرعة التطوير في الأسبوع الأول.

1. لن أبني إطارًا ثقيلًا من البداية، لكن أوضح المسؤوليات أولاً.

أحد أكثر حالات سوء الفهم شيوعًا عند بدء مشروع من الصفر هو:

• العمل لم يبدأ بعد
• قم أولاً بوضع مجموعة كاملة من الهياكل التي تبدو كاملة

وهذا ليس خطأ بالضرورة، ولكن الخطر يكمن في:

• مجردة في وقت مبكر جدا
• الهيكل لا يتطابق مع العمل الحقيقي
• سيستمر الفريق في تجاوزه لاحقًا

لذلك أفضّل:

• اجعل حدود المسؤوليات واضحة أولاً
• أضف الطبقات تدريجيًا مع زيادة التعقيد

بدلاً من “أن أكون كبيراً ومكتملاً في اليوم الأول”، فإنني أقدر “أن أكون سلساً في الشهر الأول” أكثر.

2. أول شيء أفهمه عادة هو الطبقات الثلاث: طبقة الصفحة، وطبقة الحالة، وطبقة القدرة.

1. طبقة الصفحة

مسؤول عن:

• الهيكل
• مزيج المكونات
• تعيين حالة الصفحة

2. طبقة الدولة

مسؤول عن:

• الوضع التجاري
• العمليات غير المتزامنة
• تبديل الحالة الدلالية للصفحة

3. طبقة القدرة

مسؤول عن:

• الشبكة
• التخزين
• خدمات المجال
• المكونات المشتركة وقدرات التصميم

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

3. سأكون حذرًا جدًا من “المناظر العملاقة”

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

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

بالطبع يبدو الأمر سريعًا جدًا في المراحل الأولى، ولكن بمجرد أن يصبح المشروع معقدًا، سيصبح العرض سريعًا:

• صعوبة القراءة
• صعوبة التغيير
• لا يمكن التنبؤ به

المشكلة هنا هي أن العرض يتحمل الكثير من المسؤوليات غير المتعلقة بالعرض.

4. سأتعمد إبطاء عملية إعادة استخدام المكونات بدلاً من بذل جهد كبير في البداية.

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

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

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

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

تقضي العديد من المشاريع الكثير من الوقت في الجدال في البداية:

• الميزة أولاً أو الطبقة أولاً
• كيفية تقسيم المجلدات

بالطبع هذه الأمور مهمة، لكن ما يهمني أكثر هو:

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

لأن ما يحدد تكاليف الصيانة حقًا هو غالبًا ما إذا كانت الحالة قيد التشغيل.

6. جوهر قابلية الصيانة هو في الواقع السماح لكل طبقة “بشرح ما هي مسؤولة عنه بوضوح”

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

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

لذلك بالنسبة لمشروع SwiftUI الذي يمكن صيانته، فإن أكثر ما أقدره عادةً هو:

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

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

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

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

لبناء مشروع SwiftUI قابل للصيانة من الصفر، الشيء الأكثر أهمية هو الحصول على حدود الحالة ومسؤوليات الصفحة وتجريد المكونات بشكل صحيح.

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