عند تطوير تطبيقات الهاتف المحمول ، اضطررت لإنشاء مشاريع من البداية أكثر من مرة. في الوقت نفسه ، قضيت أنا وفريقي دائمًا الكثير من الوقت في الإعداد الأساسي للمشروع ، مثل دمج أدوات الجهة الخارجية ، وإعداد هيكل المشروع ، وكتابة الفصول الأساسية ، ودمج المكتبات الخارجية ، إلخ.
قررت أن الوقت المستغرق لبدء المشروع يمكن تقليصه ، ويمكن أتمتة الجزء الرئيسي من العملية. في نفس الوقت ، جمعت أفضل الممارسات والأدوات التي استخدمناها ، وقمت بإعداد
قالب مشروع نستخدمه عند بدء مشروعات جديدة. يجب أن يوفر هذا القالب وقت المطور لتكوين مشروع جديد ، بالإضافة إلى توفير هيكل مشروع مشترك يعتاد عليه كل عضو في الفريق ، بحيث لم تعد مضطرة للتفكير ودراسة بنية مشروع جديد له. الآن هو نفسه دائما.
تستحق كل أداة أو طريقة تمت إضافتها إلى القالب مقالة منفصلة ، لكنني أود أن أحاول تلخيص كل فقرة وتقديم شرح موجز عن سبب إدراجها في هذه المقالة.
Cocoapods
لا أعتقد أن Cocoapods يتطلب تقديم.
هذه مكتبة لإدارة التبعيات الخارجية لمشاريع iOS. لقد كانت موجودة لفترة طويلة وهي موثوقة ومثبتة بالآلاف في المشروعات (إن لم تكن الملايين) من المشاريع. يوجد أيضًا مدراء تبعية بديلون ، على سبيل المثال:
Carthage ، لكنني قررت المتابعة مع Cocoapods ، لأنه يحتوي على أوسع مجموعة من المشاريع المفتوحة المصدر المدعومة. يعد استخدام Cocoapods بسيطًا جدًا ويأتي مع
فهرس بحث يسهل العثور على الحزم التي يمكن أن تكون مفيدة في أي وقت.
يتم توفير مشروع قالب مع
Podfile بسيط يحتوي على Swiftlint و R.swift. يتضمن القالب أيضًا
ملفًا متحكمًا لإدارة إصدار Cocoapods المستخدم لإدارة التبعية. غالبًا ما يتم تجاهل هذا الحل من قبل المطورين ، ولكنه يمنع المشكلات التي تحدث عندما يقوم مطورو فريقك بتثبيت التبعيات باستخدام إصدارات مختلفة من Cocoapods. يستخدم Gemfile بالقوة نفس الإصدار من Cocoapods للفريق بأكمله.
Swiftlint
Swiftlint هي أداة مفيدة للغاية لفرض قواعد معينة ونمط الكتابة لكل مطور في نفس الفريق. يمكن اعتبار هذا النظام نظامًا للتحقق من الشفرة تلقائيًا يحذر المطور من اللحظات الخطيرة ، على سبيل المثال ، القوة الإجبارية ، محاولات القوة ، وما إلى ذلك ، ولكن بالإضافة إلى ما سبق ، يطبق هذا النظام نمطًا عامًا من شفرة الكتابة والمراقبة بحيث يتبع جميع المطورين القواعد نفسها المرتبطة بـ "نمط الشفرة" ، على سبيل المثال: المسافات البادئة أو الفواصل الزمنية. هذا النهج له مزايا كبيرة ، ليس فقط توفير الوقت في التحقق من الكود ، ولكن أيضًا جعل ملفات المشروع قابلة للتعريف ، مما يزيد من سهولة قراءتها ، وبالتالي فهمهم من قبل جميع أعضاء فريق التطوير. يوفر هذا
الرابط قائمة بجميع القواعد. في قالب Swiftlint ، يتم تثبيته باستخدام Cocoapods ويتم تضمينه في خطوة "Compilation Phases" ، لذلك سيظهر تحذير للمطور في كل مرة يتم فيها تجميع المشروع.
R.swift
R.swift هي أداة للحصول على موارد مكتوبة بشكل قوي
ومعبأة تلقائيًا ، مثل الصور وشرائح الخطوط والتعريب. ينفذ جميع الإجراءات المذكورة أعلاه عن طريق مسح المشروع وإنشاء الفئات اللازمة للحصول على الموارد. أكبر ميزة لهذه المكتبة هي أنه عند استخدام الموارد ، فإنه يجعل رمز البرنامج:
- مكتوب بالكامل - سيتم إرجاع عدد أقل من القوالب والافتراضات حول الطريقة التي سيتم إرجاعها
- ترجمة الوقت المحدد - لم تعد الخطوط غير الصحيحة التي تمنع التطبيق من العمل أثناء تنفيذ التعليمات البرمجية
- الإكمال التلقائي - لا حاجة لتخمين اسم الصورة / المنقار / القصة المصورة مرة أخرى
النظر في التعليمات البرمجية التالية باستخدام API سلسلة الرسمية:
let icon = UIImage(named: “custom-icon”)
إذا ارتكبت خطأ في اسم الصورة ، فستحصل على صفر. إذا غير أي عضو من أعضاء فريقك اسم مورد الصورة ، فسوف يُرجع هذا الرمز صفرًا أو سيتم إيقاف تنفيذه إذا فرضت الصورة على التوسع. عند استخدام R.swift ، يبدو كما يلي:
let icon = R.image.customIcon()
يمكنك الآن التأكد من أن الأيقونة موجودة بالفعل (سيحذرك برنامج التحويل البرمجي إذا لم يكن كذلك ، وذلك بفضل عمليات التحقق من وقت الترجمة) ، وسوف تكون متأكدًا من أنك لن تقوم بإجراء خطأ مطبعي باسم الرمز ، لأنك ستستخدم الإكمال التلقائي.
يتم تثبيت R.swift باستخدام Cocoapods ويدمج في القالب في مرحلة التجميع وسيتم إنشاء فئات قذيفة سويفت لكل تجميع. هذا يعني أنه إذا قمت بإضافة ملف / صورة / تعريب / font / color / pen ، إلخ ، فسيكون كل هذا متاحًا من خلال R.swift بعد تجميع المشروع.
ملف AppDelegate منفصل للاختبارات
غالبًا ما ينسون الممارسة الجيدة المتمثلة في استخدام فصل TestAppDelegate منفصل عند إجراء الاختبارات. لماذا هذه فكرة جيدة؟ عادةً ما تقوم فئة AppDelegate بالكثير من العمل عند بدء تشغيل التطبيق. يمكن أن يكون له منطق لتكوين النافذة ، وتكوين العرض الأساسي لواجهة مستخدم التطبيق ، وتنفيذ منطق التسجيل لتلقي الإخطارات ، والحصول على رمز إعداد اتصال قاعدة البيانات ، وحتى في بعض الأحيان إجراء مكالمات API للخادم. يجب ألا يكون لاختبارات الوحدة آثار جانبية. هل تريد حقًا إجراء مكالمات عشوائية لواجهة برمجة التطبيقات وتخصيص بنية واجهة المستخدم بالكامل لتطبيقك فقط لتشغيل اختبارات الوحدة؟
TestAppDelegate هو أيضًا خيار مناسب للحصول على الكود الذي تريد تشغيله مرة واحدة فقط أثناء تنفيذ مجموعة الاختبار. قد يحتوي على رمز يولد كائنات وهمية ، أو دعامات طلب شبكة ، إلخ.
يحتوي القالب على ملف main.swift ، وهو نقطة الإدخال الرئيسية للتطبيق. هناك طرق في هذا الملف تختبر بيئة التطبيق ، وإذا كانت بيئة اختبار ، فإنها تستدعي TestAppDelegate.
المترجم أداء التنميط الأعلام
Swift هي لغة رائعة وأسهل استخدامًا وأكثر أمانًا من Objective-C (IMO). ولكن عندما تم تقديمه لأول مرة ، كان لديه وقت كبير لتجميع الخلل. مرة أخرى في الأيام التي كنت أعمل فيها في مشروع في سويفت ، والذي كان به حوالي 40 ألف سطر من كود سويفت (مشروع متوسط الحجم). كان الكود ثقيلًا جدًا ، مع إعدادات ونوع الاستدلال ، واستغرق تجميع التجميع النظيف حوالي 5 دقائق. إذا قمت بإجراء تغييرات صغيرة ، فسيتم إعادة ترجمة المشروع ويستغرق الأمر حوالي دقيقتين لرؤية التغييرات. كانت هذه واحدة من أسوأ التجارب التي مررت بها على الإطلاق ، ولهذا السبب توقفت تقريباً عن استخدام Swift.
ثم كان الحل الوحيد هو محاولة تحديد وقت التحويل البرمجي للمشروع وتغيير الكود الخاص بك حتى يعمل المترجم بشكل أسرع. للمساعدة في حل مثل هذه المشكلات ،
تقدم Apple بعض إشارات المحول البرمجي غير الرسمية التي تحذر المطور من أن يستغرق الأمر وقتًا طويلاً في تجميع نص الأسلوب أو تحديد نوع التعبير. أضفت هذه العلامات إلى مشروع القالب للتحذير من وقت التحويل البرمجي الطويل للتطبيق الخاص بك.
في الوقت الحاضر ، انخفض وقت الترجمة بشكل كبير ، ونادراً ما يضطر المطورون إلى تحسين الكود الخاص بهم فقط لتقليل وقت الترجمة. ولكن لا يزال من الأفضل معرفة كل شيء مقدمًا بدلاً من محاولة حل هذه المشكلة عندما يصبح المشروع كبيرًا جدًا.
ديف / التدريج / تكوينات الإنتاج
هناك طريقة جيدة أخرى (أو ، قد يقول أحدهم ضرورة) تتمثل في وجود متغيرات تهيئة وبيئة منفصلة لبيئات التطوير والاختبار النهائي ونشر التطبيق. حاليًا ، يجب أن يعمل كل تطبيق تقريبًا مع خادم ، وعادةً ما يتم نشر هذه الخوادم في بيئات متعددة. يتم استخدام بيئة التطوير للنشر اليومي بواسطة المطورين لاختبار التعليمات البرمجية الخاصة بهم. يتم استخدام بيئة الاختبار النهائية لإنشاء إصدارات مستقرة أو للاختبار من قبل المختبرين والعملاء.
تتمثل إحدى طرق دعم بيئات متعددة في مشروع iOS في إضافة التكوينات على مستوى المشروع.
تكوينات مستوى المشروعبعد تحديد التكوينات ، يمكنك إنشاء ملف Configuration.plist يحتوي على متغيرات لكل بيئة.
Configuration.plistعند بدء مشروع ، من الممكن الإشارة إلى التكوين الذي يجب استخدامه. يمكنك القيام بذلك في مخطط تجميعي.
ثم تحتاج إلى إضافة خاصية أخرى إلى ملف المشروع Info.plist. سيتم استبدال قيمة هذه الخاصية ديناميكيًا في وقت التشغيل باسم التكوين الحالي.
تم تكوين كل هذا مسبقًا في القالب.يبقى فقط كتابة فصل يمكنه استخراج هذه المتغيرات في وقت التشغيل ، اعتمادًا على التكوين المحدد في نظام التجميع. يحتوي القالب على فئة
ConfigurationManager ، والتي يمكنها استرجاع المتغيرات الخاصة بالبيئة الحالية. يمكنك أيضًا التحقق من تنفيذ هذا الفصل على جيثب لترى كيف يعمل.
التمهيدي
يجب أن يحتوي كل مشروع على ملف Readme ، والذي يحتوي على الأقل على إرشادات حول تثبيت التبعيات وبدء المشروع. يجب أن يحتوي أيضًا على أوصاف لبنية المشروع ووحداته. لسوء الحظ ، لا يحب المطورون كتابة الوثائق (ملف الملف التمهيدي جزء من هذا العمل) ، وقد رأيت مشروعًا تم تطويره منذ شهور ، وحتى أنه يحتوي على ملف المستند التمهيدي. لإزالة عبء كتابة الملف التمهيدي ، يحتوي القالب على
ملف التمهيدي القياسي الذي يغطي تثبيت وهيكل المشروع. عند إعداد مشروع جديد باستخدام القوالب ، تقوم تلقائيًا بتضمين ملف المستند التمهيدي.
Gitignore
تستخدم معظم المشروعات حاليًا GIT كنظام للتحكم في الإصدار. عند استخدام GIT ، لا يرغب المطورون في تجاهل بعض الملفات أو المجلدات في المشروع ، مثل مجلد الإنشاء أو مجلد البيانات المشتق. لحفظ المطور من الاضطرار إلى العثور على ملف gitignore المناسب لمشروع iOS الخاص به ، يحتوي القالب على gitignore القياسي الذي يوفره أعضاء Github.
فئات أساسية للتعامل مع الروابط والإشعارات الخارجية
في الوقت الحاضر ، يجب أن يتعامل كل تطبيق تقريبًا مع الروابط والإعلامات الخارجية. للقيام بذلك ، يجب على المطور كتابة بعض التعليمات البرمجية القياسية في فئة AppDelegate. يحتوي هذا القالب على وصف لكيفية القيام بذلك ، كما أنه
يحتوي على فئات أساسية تسهل العمل مع الارتباطات والإعلامات الخارجية.
استنتاج
للتلخيص ، يحتوي
القالب الموصوف على أفضل الأساليب ويتكامل مع أدوات الجهات الخارجية المفيدة. كل هذا يجب أن يوفر وقت تطوير فريقك الذي يقضيه في إنشاء مشروع جديد ، وكذلك توفير أساس مشترك وقوي لبقية المشروع.
دع هذا القالب يخدمك أنت وفريقك لصالحك!