من مشروع إلى آخر ، نلاحظ أن الكود الخاص بنا يؤدي نفس الوظائف ويشبهه تقريبًا. هذا يجعلنا نتساءل - ألا نقوم بالعمل الإضافي من خلال إعادة كتابة نفس الشيء؟ نبدأ في نسخ الفصول من المشاريع السابقة وما زلنا نفهم أننا نقوم بشيء خاطئ وأننا على صواب - مجرد نسخ الفصول من مشروع إلى مشروع ، يمكننا أن نفقد / نستبدل / نمسح شيئًا ما بسهولة ، وإذا قاد فريقنا عدة مرات أخرى في نفس الوقت ، سيتطلب اكتشاف الأخطاء في الفصول المستعارة تغييرات يدوية في جميع المشروعات. لقد سئمنا من الدخول في هذا البرنامج ، نقرر أننا نحتاج إلى رمز مشترك سيتم مشاركته على جميع مشاريعنا وسيتم سحب أي تغييرات في ذلك بسهولة. نعم ، نحن بصدد إنشاء مكتبتنا من المكونات القابلة لإعادة الاستخدام! سوف تتعلم عن طرق مختلفة لتنظيم مكتبتك ، عن جميع إيجابيات وسلبيات النهج تحت القط :)

هناك عدة طرق لتنظيم قاعدة الشفرة الشائعة لدينا:

1. مكتبة Android (aar / jar)
2. بوابة حيلة
3. بوابة الشجرة

مكتبة Android (aar / jar)

أي مكتبة للتطبيق لدينا هي مجرد الكثير من الفصول المنظمة بطريقة معينة. في كل مرة نقوم بتوصيل بعض Retrofit أو Dagger في build.gradle ، نقوم بتحميل المكتبة كأرشيف aar / jar من أحد منصات نشر المكتبة. أشهر منصات نشر المكتبات هي JCenter و MavenCentral. يعمل مطورو المكتبة في المستودع الخاص بهم على الإصدار الجديد ، وعندما تصبح النسخة جاهزة للانطلاق إلى العالم ، ينشرونها على أحد الأنظمة الأساسية ويقولون "مرحبًا ، لقد أصدرنا إصدارًا جديدًا من أفضل مكتبة لدينا!". كل ما تبقى يجب القيام به للمطورين الذين يستخدمون هذا lib في مشاريعهم هو تغيير الإصدار في build.gradle والاستمتاع بميزات جديدة. هل هي مريحة؟ كلمة خاطئة!

ولكن ما مدى ملائمة هذا النهج إذا كانت مكتبتنا قيد التطوير ويتم تحديثها كل يوم بميزات جديدة بواسطة مطورين مختلفين من مشاريع مختلفة من فريقنا؟ دعونا نرى كيف يبدو في الممارسة العملية.

نقوم بإنشاء مستودع لمكتبتنا ، وإضافة بعض الميزات هناك ، وتصحيحه ، ونحن على استعداد لمشاركته مع فريقنا. بعد ذلك سنتعرف على كلمات مثل JCenter و MavenCentral و Bintray و Jitpack.io ... كل هذه هي منصات لنشر المكتبات. الآن المنصة الرئيسية لمشاريع أندرويد هي JCenter. إذا قمت بإنشاء مشروع ، فسترى أنه في build.gradle (مستوى المشروع) في المستودعات ، يتم تحديد JCenter

repositories { google() jcenter() } 

أي إذا أراد المطور توصيل مكتبتك ، فستكون كافية له لتوصيلها بمستوى الوحدة النمطية build.gradle .

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

كيفية تنظيم العمل الجماعي على المكتبة

إذا أنشأنا مكتبة وقمنا بتحميلها إلى المستودع ، فلن يكون لدى بقية فريقنا سوى أرشيف jar / aar المستلم. لكي يتمكن الفريق بأكمله من العمل على أي - يجب على كل مطور تفريغ مستودع المكتبة وإجراء تغييرات عليه.

الإصدارات

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

التحقق من المكتبة في المشروع

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

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

بوابة حيلة

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

كيف يعمل؟

تسمح لك الوحدات الفرعية باحتواء مستودع Git على أنه دليل فرعي لمستودع Git آخر. هذا يجعل من الممكن استنساخ مستودع آخر داخل المشروع ، وتخزين الالتزامات الخاصة بهذا المستودع بشكل منفصل.

ببساطة ، لدينا مستودعين: مشروع ومكتبة. مستودع المشروع يخزن كود المكتبة ورابط لحالة مستودع المكتبة. لذلك فهم جيت ما هي حالة (نسخة) المكتبة التي يحتاجها المشروع.

اقرأ المزيد حول كيفية عمل Git Submodule هنا.

كيفية تنظيم العمل الجماعي

في منهج Git Submodule ، يتم تنظيم العمل الجماعي في المكتبة على النحو التالي:

1. عند إنشاء مشروع جديد أو توصيل مكتبة بمشروع موجود ، يتم إنشاء فرع Git جديد من الرئيسي باسم المشروع.
2. عندما يحين الوقت لتجديد المكتبة ببعض الوظائف ، يتم إنشاء فرع للمهمة (من فرع المشروع) وإجراء تغييرات هناك.
3. يتم إجراء مراجعة ، ويتم ضخ مجمعات في فرع المشروع. عند كتابة تغييرات كافية لإصدار الإصدار ، يتم إنشاء تجمع عند دمج فرع المشروع في الفرع الرئيسي للمكتبة.
4. بعد اجتياز المجمع للمراجعة من قبل الفريق المسؤول عن المكتبة وسكبها في الفرع الرئيسي ، سيتم إعلام فرق المشروع المتبقية بتحديث المكتبة الذي سيظهر وسيقرر التحديث.

الإصدارات

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

نعم ، لا يعرف الاستوديو كيفية الالتزام بشكل منفصل بالرمز المتصل بالوحدة الفرعية. يمكنني استخدام SourceTree لحل هذه المشكلة. هذا التطبيق مخصص لنظامي التشغيل Windows و Mac ، وهناك نظام GitKraken لنظام Linux.

بوابة الشجرة

Git Subtree هو نسخة محسنة من Git Submodule. حاولنا في Git Subtree حل المشكلات التي واجهها المطورون أثناء العمل مع Git Submodule ؛ هناك مقالة جيدة على المحور تصف الاختلافات بين الأدوات. على الرغم من أنها تعمل بشكل مختلف ، إلا أنها تحل مشكلة واحدة.

استنتاج

تعد أدوات Git Submodule / Subtree كبيرة لحل مشكلة إنشاء قاعدة تعليمات برمجية مشتركة لفريق مشترك في العديد من المشاريع. إحدى الميزات المهمة هي التحقق الفوري من التعليمات البرمجية الجديدة في المشروع بعد إجراء تغييرات على المكتبة. في هذا ، النهج القياسي لنشر مكتبة إلى JCenter أو MavenCentral هو أدنى. إذا قررت نقل Git Submodule / Subtree إلى فريقك ، فكر مقدمًا في نظام الإصدار ، وخلق قواعد / مكونات إضافية للتحكم في الإصدار.

إعادة استخدام كبيرة للجميع!