الصورة من Unsplash لـ "خط أنابيب"
النهج العام
تحية! أبدأ سلسلة من المنشورات على خطوط الأنابيب قيد التطوير وليس فقط ذلك يساعد على التحقق من جودة تطبيقات الهاتف المحمول التي يتم تطويرها. الفكرة الرئيسية هي تسليط الضوء على جميع الأساليب لتطوير المحمول ذات الصلة الآن: التطوير الأصلي لنظامي Android و iOS و React Native و Xamarin و Flutter. سوف أبدأ باستخدام Android ، لكن أولاً أود أن أقدم فكرة عامة عن كل شيء.
ضع في اعتبارك أن هذه نظرة عامة على الأدوات والممارسات التي يمكن أن تكون مفيدة في عملية تطوير تطبيقات Android ، وليس تعليميًا حول إعداد هذه الأدوات.
ما هو كل شيء ل؟
لنبدأ بالحقيقة المعروفة: كلما وجدت عيوبًا في التطبيق لاحقًا ، زادت تكلفة إصلاحها. افترض أنك اكتشفت خطأ بالفعل في الإنتاج. يحتاج المختبرون إلى إعادة إنتاج هذا الخطأ محليًا ، وتسجيله ، وتحديد أولوياته ، ونقله إلى المطورين ، وهم بدورهم بحاجة إلى إصلاحه ، وإنشاء تجميع جديد ، ونقله مرة أخرى إلى المختبرين حتى يكونوا مقتنعين بأن كل شيء ثابت ، ثم إنشاء الإصدار ، عندها فقط أرسل النسخة الجديدة إلى المستخدمين.
يمكن حفظ العديد من ساعات العمل إذا كان لديك آليات لمنع ظهور الأخطاء في البداية. أنا لا أقول أن هناك رصاصة فضية تقضي على جميع الأخطاء - وهذا مستحيل. ولكن ما هو ممكن هو إقامة حواجز (تُعرف أيضًا باسم بوابات الجودة) تزيد من احتمال اصطياد الأخطاء في الكود في أقرب وقت ممكن.
على الكمبيوتر المطور
كمطور ، فأنت تعمل دائمًا على جهازك باستخدام IDE وأدوات سطر الأوامر. دعونا نرى ما هو موجود لمطوري أندرويد.
أندرويد ستوديو
هذا هو الآن الخيار الافتراضي لمطور Android ، وبما أنه يعتمد على النظام الأساسي IntelliJ ، فهناك العديد من عمليات التفتيش لجافا و Kotlin و XML. أنصحك بالموافقة في فريق على القواعد المحددة التي تريد استخدامها ، وتهيئتها على جهاز كمبيوتر واحد ، وتحميل ملف settings.jar بهذه القواعد إلى نظام التحكم في الإصدار الخاص بك أو نوع من أداة العمل التعاوني (مثل Confluence).
إعدادات التفتيش في Android Studio
يحتوي AS أيضًا على إصلاحات سريعة يمكن تطبيقها على الكود الخاص بك عن طريق الضغط على Alt + Enter.
مثال سريع الإصلاح من Android Studio
أندرويد لينت
هذه أداة تحليل ثابتة خصيصًا لتطوير Android ، حيث توجد مئات القواعد التي يمكنك استخدامها. يمكن أيضًا تشغيل Lint من مهمة Gradle (مهمة) ، وتقديم مطالبات مباشرة في Android Studio ، وإنشاء تقرير. لديها العديد من الشيكات ، مقسمة إلى فئات - الأمن ، التدويل ، سهولة الاستخدام ، الأداء ...
لكن القدرة على إضافة القواعد الخاصة بك تجعلها قوية بشكل خاص. على سبيل المثال ، تحتوي الغرفة على مجموعة القواعد الخاصة بها ، ومكتبة تسجيل الأخشاب لها قواعدها الخاصة. يمكنك إنشاء قواعد لفريقك أو مشروعك وتأكد من أن لا أحد يرتكب أخطاء نموذجية معينة. (بالمناسبة ، في مؤتمر موبيوس قريبًا ، سيكون هناك تقرير عن ذلك ، يوضح الجانب النظري والجانب العملي).
مثال تقرير لينت لنظام Android
تحليل أكثر ساكنة
بالطبع ، هناك العديد من أدوات التحليل الثابتة المصممة خصيصًا لنظام Android ، ولكن بشكل عام لـ Java و Kotlin : PMD و FindBugs (مهجور ، استخدم SpotBugs ) و Checkstyle و Ktlink و Detekt وغيرها. اختر حسب رغبتك ، وادمجها في خط الأنابيب الخاص بك وتأكد من استخدامه الحقيقي (كيف بالضبط؟ اقرأ).
الإبلاغ عن مثال من FindBugs
لكن لا يكفي وجود أداة توفر بيانات حول ما يلزم إصلاحه. ستجد أيضًا المعلومات التالية مفيدة:
- كيف تتغير تغطية الشفرة مع الاختبارات بمرور الوقت؟
- كم من الوقت سوف يستغرق مني لإصلاح جميع المشاكل الموجودة؟
- كم رمز مكرر هناك في المشروع؟
- كيف يمكنني توسيع قواعدي لتشمل فرق متعددة؟
وغيرها الكثير. في EPAM Systems ، نركز على الجودة ، لذلك اخترنا SonarQube كأداة للإجابة على هذه الأسئلة. للحصول على مزايا SonarQube الأخرى ، انقر هنا .
اختبار وحدة
نأمل ألا تضطر إلى طمأنتك مرة أخرى بأن التعليمات البرمجية لعنة يحتاج إلى اختبارات وحدة لأسباب مختلفة . لا يهم إذا كنت تتبع TDD ، أو التمسك بمبدأ هرم الاختبار أو الفكرة الجديدة للفطر الاختبار . ليس من المهم تحديد مستوى التغطية الذي تحدده كهدف ، على أي حال ، تعتبر اختبارات الوحدة الخاصة بك مكونًا ضروريًا. لذلك ، تحتاج إلى الكتابة وتشغيلها! لحسن الحظ ، بعد أكثر من 11 عامًا من التطور ، حصلنا على آلية ملائمة جدًا لإجراء الاختبارات من المكوّن الإضافي Gradle و Android Gradle.
في مشروع Android ، يحتوي المشروع الافتراضي على مهمة testDebugUnitTest (بالنسبة لك ، بالطبع ، قد يختلف باختلاف النكهات) ، وهي التي تدير الاختبارات. تأكد من استخدامه وأن تغطية الرمز تتزايد بمرور الوقت. ميزة اختبارات وحدة Java هي أنها تعمل على محطة عمل JVM ، وليس على Dalvik / ART ، مما يعطي ميزة في السرعة.
في حالة اختبارات وحدة android ، هناك مشكلة أساسية واحدة: الاعتماد على Android SDK. هذا أحد أسباب ظهور كل هذه الطرق لطبقة واجهة المستخدم مثل MVP و MVVM و MVI و MV * الأخرى. المشكلة المحددة التي تعتمد على الفصل على نظام Android هي أن اختبارات الوحدات تقع ببساطة بسبب استخدام بذرة هذا Android نفسه ، والذي يلقي ببساطة استثناء. بالطبع ، هناك خياران: إما تخطي الاختبارات لهذه الفئة ، أو استخراج بعض المنطق في فئات أخرى ، أو إنشاء واجهات للفئات المعتمدة على Android لاختبار بعض المنطق الرفيع المستوى ، أو استخدام Robolectric (وهو أبعد ما يكون عن المثالية). خيار آخر هو استخدام الاختبارات المجهزة ، والتي قد تكون مناسبة للتحقق من سلوك النشاط ، ولكن الاتجاه الحالي هو أن النشاط يجب ألا يحتوي على اختبارات.
بالنسبة إلى مسألة التغطية: فأنت تريد أن تعرف ما هي عليه في الوقت الراهن وكيف يتغير مع مرور الوقت ، حتى تحتاج إلى أداة لذلك. بقدر ما أعرف ، jacoco هو معيار الصناعة لجافا ، ولديه دعم Kotlin.
اختبارات الآلات
تعمل هذه الاختبارات على محاكي Android ، والذي يتيح لهم استخدام Android Framework. لسوء الحظ ، فهي بطيئة وغير مستقرة (بسبب بعض المشاكل مع المحاكي) ، لذا يحاول معظم المطورين المعروفين لي تجنبها. ولكن دعمهم موجود في Gradle و Android Studio ، لذا فقد يكونون مناسبين لك.
التدقيق الأمني
بالإضافة إلى الأخطاء البسيطة ، الأخطاء المطبعية ، مشاكل النسخ واللصق وما شابه ، هناك أيضًا فئة كبيرة من المشكلات التي يجب الانتباه إليها: الأمان. بالطبع ، يوفر Android Lint بالفعل بعض النصائح ذات الصلة ، ولكن من الأفضل العناية بالأدوات المتخصصة المخصصة لهذه المهمة. يمكن أن تعمل هذه الأدوات في أوضاع ثابتة وديناميكية ؛ اعتمادًا على متطلبات الأمان الخاصة بك ، قد ترغب في استخدام أي من هذين الوضعين أو كليهما. قد ترغب في البدء ، على سبيل المثال ، بإطار أمان الهاتف المحمول ، والنظر لاحقًا في الخيارات المدفوعة.
لحسن الحظ ، هناك قائمة من أدوات التحليل الثابتة التي تم تجميعها مباشرة بواسطة OWASP. على سبيل المثال ، يمكنك اختيار Find Security Bugs أو استخدام مشروع OWASP SonarCube .
تحقق من التحقق
كما قلت ، كلما قلت مدة دورة الملاحظات ، قل الوقت الذي تنفقه على إصلاح الأخطاء. لذلك أريد أن أتأكد من أن الكود يتوافق مع جودة الإنتاج قبل أن يصل إلى المستودع أو حتى يتم الاتصال به محليًا. بالطبع ، يمكنك ببساطة أن تطلب من المطورين إجراء الاختبارات ، ولكن هناك خيار أفضل بكثير: Git hooks.
أقترح إضافة ربط مسبق لجميع عمليات الفحص التي ناقشناها أعلاه: الوبر ، تحليل الشفرة الثابتة ، واختبارات الوحدة. يمكن العثور على مثال لعملية الإعداد هنا .
CI / CD Pipeline
من الصعب للغاية تخيل مشروع Android بدون خط أنابيب CI / CD. هدفك هو تكرار جميع الاختبارات المذكورة أعلاه في مرحلة التجميع. هناك عدة أسباب لهذا:
- يمكن التحايل بسهولة على خطافات Git باستخدام الخيار - no-check
- يمكن أن ينجح الرمز بنجاح في إجراء جميع الاختبارات محليًا ، ولكنه يعرض المشاكل بعد الدمج
- تحتاج تقارير الاختبار والتغطية
تقرير المثال في bitrise.io
لحسن الحظ ، يكفي أن تذكر إما عمليات التحقق من الأمان هذه مباشرةً في البرنامج النصي لإنشاء Gradle ، أو لاستدعاء المهام المقابلة في خط أنابيب CI / CD. إذا كنت تواجه صعوبة في إنشاء خط أنابيب ، فقد قدمت مؤخرًا عرضًا تقديميًا في مؤتمر DevOops على DevOps على الأجهزة المحمولة في عام 2019.
يرجى أيضا القيام بما يلي:
- تشغيل جميع الشيكات لطلبات السحب. لا تدع دمج أي طلب ينتهك أي من القواعد. هذا مهم للغاية: إذا لم يتم تنفيذ القاعدة ، فعندئذ ، في الواقع ، لا وجود لها.
- تشغيل جميع الشيكات أثناء التجميع والنشر. لا تريد خفض شريط الجودة الخاص بك.
- إذا تم كسر البنية ، فهذه هي الأولوية الأولى. يجب على الفريق حل المشكلة على الفور ، لأنه ينتهك ممارسة التسليم المستمرة ويمنع الفريق من كتابة كود الجودة.
ونتمنى لك التوفيق في تحسين التعليمات البرمجية الخاصة بك!
إذا أعجبك هذا المقال ، فاتبعني على Twitter حتى لا تفوتك ما يلي. وإذا كنت ستصل إلى موسكو في ديسمبر أو يمكنك الحضور ، تعال إلى مؤتمر Mobius الخاص بنا واكتشف الكثير من الأشياء الأخرى حول التطوير لنظام Android (و iOS)!
ملاحظة: بفضل vixentael على معالجتها لقضايا الأمن ، إلى Alexei Nikitin للمراجعة والتعليقات ، إلى Alexander Bakanov لتصحيح التجارب المطبعية.