من مبتدئ إلى مساهم: أول طلب سحب (PR) لك في مشروع Kotlin

لماذا يجب أن تبدأ المساهمة في مشاريع Kotlin الآن؟

لقد كنت تكتب بلغة Kotlin لعدة أشهر. تعلمت عن coroutines، وفهمت دوال extension، بل وتستخدم sealed classes. لكنك تشعر أنك واقف في مكانك؟ هذا مألوف. المصادر المفتوحة ليست "عملاً مجانياً". إنها تتعلق بتسريع نموك بمقدار 10 أضعاف. عندما تساهم في مشاريع حقيقية، فإنك:

\n
• تحصل على مراجعة كود (code review) من مطورين بمستوى JetBrains وGoogle؛
\n
• تتعلم قراءة وفهم كود الآخرين (وهذا يمثل 80% من وقت عمل المطور الكبير (senior))؛
\n
• تضيف إلى محفظتك (portfolio) حالات حقيقية، وليس مهام تدريبية؛
\n
• تكوّن علاقات مفيدة في المجتمع.
\n

في هذه المقالة، سأوضح لك كيفية اتخاذ الخطوة الأولى. بدون خوف، بدون نظريات معقدة - فقط ممارسة. سنناقش أين تبحث عن المهام، وكيف تكتب أول طلب سحب (PR) ذي معنى دون أن تخطئ.

من أين نبدأ: اختيار مشروع يتناسب مع مستواك

الخطأ الرئيسي للمبتدئين هو محاولة المساهمة فوراً في Kotlin Compiler أو Ktor. توقف. هذا طريق للإرهاق. أنت بحاجة إلى مشاريع حيث:

\n
• يوجد وسم good first issue أو help wanted؛
\n
• يتم دعم إصدار حديث من Kotlin (1.9+)؛
\n
• يوجد ملف CONTRIBUTING.md مفهوم؛
\n
• يجيب المجتمع على الأسئلة في غضون 1-3 أيام.
\n

أفضل 5 مشاريع للبدء في المصادر المفتوحة بلغة Kotlin

إليك مستودعات (repositories) موثوقة أوصي بإلقاء نظرة عليها:

\n
• detekt — محلل كود ثابت. الكثير من المهام المتعلقة بالتوثيق والقواعد البسيطة؛
\n
• Kotlinx.serialization — مكتبة من JetBrains. توجد good first issue للمبتدئين؛
\n
• Ktor — إطار عمل (framework) للخوادم والعملاء. غالباً ما يحتاج مساعدة في التوثيق والاختبارات؛
• Exposed — ORM للغة Kotlin. مثالي إذا كنت قد عملت مع قواعد البيانات؛
• Anko — على الرغم من أن المشروع متوقف، إلا أنه لا يزال هناك العديد من المشكلات (issues) المفتوحة المتعلقة بالتوثيق.

هام: لا تحاول فعل كل شيء دفعة واحدة. اختر مشروعاً واحداً يثير اهتمامك حقاً. إذا كنت تحب كتابة الاختبارات، فاذهب إلى Ktor. إذا كنت ترغب في جعل الكود أنظف، فإن detekt هو خيارك.

كيف تجد مهمتك الأولى: تحليل GitHub Issues

لنفترض أنك اخترت مشروعاً. اذهب إلى قسم Issues. هدفك هو العثور على مهمة:

\n
• موسومة بـ good first issue أو beginner friendly؛
• غير مخصصة لمطور آخر (لا يوجد assignee)؛
• نشطة (آخر تعليق ليس أقدم من أسبوعين).

مثال من الواقع. دخلت إلى مستودع detekt ووجدت مشكلة (issue): "إضافة توثيق للقاعدة الجديدة: MagicNumber". المهمة: كتابة توثيق بالروسية أو الإنجليزية للقاعدة الجديدة. هذا أول PR مثالي - لا يتطلب معرفة عميقة بالكود، لكنك بالفعل تقدم فائدة حقيقية.

نقوم بعمل Fork، Clone، وإعداد البيئة

عند اختيار المهمة، نعمل وفق المخطط التالي:

\n
1. نقوم بعمل Fork للمستودع (زر Fork في الزاوية اليمنى العليا)؛
2. نقوم بعمل Clone للـ Fork محلياً: git clone git@github.com:YOUR_USERNAME/detekt.git؛
3. نضيف upstream: git remote add upstream https://github.com/detekt/detekt.git؛
4. ننشئ فرعاً (branch): git checkout -b docs/add-magic-number-rule.

يجب أن يكون اسم الفرع ذا معنى. استخدم البادئات: docs/ للتوثيق، fix/ لإصلاح الأخطاء، feat/ للميزات الجديدة.

كتابة الكود: مثال حقيقي بلغة Kotlin

لنفترض أننا وجدنا خطأ (bug) في مكتبة Kotlinx.serialization. مكتوب في المشكلة (issue): "المُسلسِل (Serializer) لـ LocalDate يرمي استثناء عندما تكون السنة سالبة". دعنا نحلل كيف يمكن إصلاح ذلك.

أولاً، نبحث