مشروع iOS أفضل الممارسات والأدوات

مع قالب مشروع مفتوح المصدر Xcode

عندما كنت أعمل على مشاريع iOS في Greenfield ، كان عليّ أن أبدأ مشروعًا جديدًا من البداية. أثناء القيام بذلك ، كنت أنا وفريقي نقضي دائمًا الكثير من الوقت في الإعداد الأساسي للمشروع مثل دمج الأدوات وإعداد هيكل المشروع وكتابة الفصول الأساسية ودمج المكتبات الخارجية وما إلى ذلك.

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

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

Cocoapods

لا أعتقد أن هذا يحتاج إلى مقدمة. هذه هي المكتبة لإدارة التبعيات الخارجية لمشاريع iOS. لقد كانت موجودة منذ فترة طويلة وتم اختبارها بقوة ومعركة في آلاف المشاريع (إن لم يكن الملايين). يوجد مديرو تبعية بديلون مثل Carthage ، لكنني قررت الذهاب مع Cocoapods لأنه يحتوي على أوسع مجموعة من مشروع مفتوح المصدر يدعمه. يعد استخدام Cocoapods أمرًا سهلاً للغاية ويأتي مع فهرس بحث يتيح لك اكتشاف الحزم التي قد تحتاج إليها بسهولة.

مشروع القالب يأتي مع Podfile بسيط يتضمن Swiftlint و R.swift. يتضمن القالب أيضًا ملف Gemfile لإدارة إصدار Cocoapods المستخدم لحل التبعيات. يعد هذا تحسينًا يتم تجاهله في كثير من الأحيان ويمنع المشكلات الناشئة عندما يقوم المطورون في فريقك بتثبيت التبعيات باستخدام إصدارات مختلفة من Cocoapods نفسها. يفرض Gemfile استخدام نفس إصدار Cocoapods عبر الفريق بأكمله.

Swiftlint

Swiftlint هي أداة مفيدة للغاية لفرض قواعد معينة وأسلوب الترميز لكل مبرمج في الفريق. يمكنك التفكير في الأمر كنظام آلي لمراجعة الكود يحذر المبرمج من الأشياء الخطرة مثل إلغاء القوة والإجبار على القوة ومحاولات القوة وما إلى ذلك ، ولكنه يفرض أيضًا أسلوب ترميز شائع من خلال التأكد من اتباع جميع المبرمجين لنفس القواعد ذات الصلة بـ "نمط الكود" مثل المسافة البادئة أو قواعد التباعد. هذا له فوائد هائلة ليس فقط في توفير وقت مراجعة الكود من خلال القيام بهذه الفحوصات الأساسية ، ولكن أيضًا يجعل جميع الملفات في المشروع تبدو مألوفة مما يزيد من سهولة قراءتها ونتيجة لذلك فهمهم من قِبل جميع المطورين. يمكنك العثور على قائمة بجميع القواعد هنا. في القالب ، يتم تثبيت Swiftlint عبر Cocoapods ويتم تضمينه في خطوة Build Phases ، بحيث يقوم بتحرير المطور وتحذيره في كل بناء مشروع.

R.swift

R.swift هي أداة للحصول على موارد كاملة الإكمال التلقائي ، مثل الصور وسلاسل الخطوط والتعريب. يقوم بذلك عن طريق مسح مشروعك وإنشاء فصول سريعة مطلوبة للحصول على الموارد. أكبر نقطة بيع في هذه المكتبة هي أنه أثناء استخدام الموارد ، فإنه يجعل الكود الخاص بك:

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

النظر في التعليمات البرمجية التالية باستخدام API سلسلة الرسمية:

اسمحوا رمز = UIImage (اسمه: "رمز مخصص")

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

واسمحوا أيقونة = R.image.customIcon ()

يمكنك الآن التأكد من أن الأيقونة موجودة بالفعل (سيحذرك برنامج التحويل البرمجي إذا لم يكن ذلك بفضل عمليات التحقق من وقت الترجمة) وأنت متأكد أنك لن تقوم بإجراء خطأ مطبعي في اسم الرمز لأنك ستستخدم الإكمال التلقائي.

يتم تثبيت R.swift عبر Cocoapods ودمجها في القالب كمرحلة بناء وسيولد فئات مجمّع Swift في كل بنية. هذا يعني أنه إذا قمت بإضافة ملف / صورة / تعريب / font / color / nib إلخ ، فسيكون متاحًا لك باستخدام R.swift بمجرد قيامك بتجميع المشروع.

AppDelegate منفصلة للاختبارات

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

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

يحتوي القالب على ملف main.swift وهو نقطة الدخول الرئيسية للتطبيق. يحتوي هذا الملف على طرق للتحقق من البيئة التي يعمل بها التطبيق حاليًا وإذا كانت هي بيئة الاختبار ، فتستحضر TestAppDelegate.

المترجم أداء التنميط الأعلام

Swift هي لغة رائعة وأسهل استخدامًا وأكثر أمانًا من الهدف C (IMO). ولكن عندما تم تقديمه لأول مرة ، كان لديه وقت سلبي كبير. مرة أخرى في Swift 2 يومًا ، كنت أعمل على مشروع يحتوي على 40 ألف سطرًا من رمز Swift (مشروع متوسط ​​الحجم). كان الرمز ثقيلًا جدًا مع الأدوية الجنيسة واستدلال النوع واستغرق الأمر حوالي 5 دقائق لتجميع بنية نظيفة. عند إجراء تغيير بسيط ، سيتم إعادة ترجمة المشروع واستغرق الأمر حوالي دقيقتين لرؤية التغيير. كانت تلك واحدة من أسوأ تجارب المطورين التي مررت بها وتوقفت عن استخدام Swift بسبب ذلك.

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

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

ديف / التدريج / تكوينات الإنتاج

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

تتمثل إحدى طرق دعم بيئات متعددة في مشروع iOS في إضافة تكوينات مستوى المشروع.

تكوينات مستوى المشروع

بمجرد تعريف التكوينات ، يمكنك إنشاء ملف Configuration.plist يحتوي على المتغيرات لكل بيئة.

Configuration.plist

عند تشغيل المشروع ، يمكنك تحديد التكوين الذي يجب استخدامه. يمكنك القيام بذلك في مخطط البناء.

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

تم تكوين كل هذا مسبقًا في القالب.

الشيء الوحيد المتبقي هو كتابة فصل يمكنه استرداد تلك المتغيرات في وقت التشغيل اعتمادًا على التكوين المحدد في نظام الإنشاء. يحتوي القالب على فئة ConfigurationManager التي يمكنها استرداد المتغيرات الخاصة بالبيئة الحالية. يمكنك التحقق من تنفيذ هذه الفئة على جيثب لترى كيف يعمل.

التمهيدي

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

Gitignore

في الوقت الحاضر ، تستخدم معظم المشروعات GIT كنظام للتحكم في إصدارها. عند استخدام GIT ، لا ترغب عادةً في تجاهل بعض الملفات أو المجلدات في المشروع مثل مجلد البناء أو مجلد البيانات المشتق. لتوفير مشكلة في البحث عن ملف gitignore الذي يلائم مشروع iOS الخاص بك ، يتضمن القالب gitignore القياسي الذي يقدمه المساهمون في Github.

فئات أساسية للتعامل مع deeplinks والإعلامات

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

ملخص

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

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