مراجعة الكود في Kotlin: ما يجب التحقق منه وكيفية تقديم الملاحظات

تعلم Python بسهولة دون إرهاق نظري. حل مهام عملية مع التحقق التلقائي واكتب الكود مباشرة في المتصفح.

مراجعة الكود في Kotlin: ما يجب التحقق منه وكيفية تقديم الملاحظات

\n\n

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

\n\n

1. ما يجب التحقق منه: قائمة مرجعية لمطور Kotlin

\n\n

عند البدء في المراجعة، لا تحاول تغطية كل شيء دفعة واحدة. من الأفضل المرور عبر الفئات الرئيسية. إليك قائمة مرجعية منظمة لـ Kotlin.

\n\n

1.1. أمان القيم الفارغة (Null Safety) والعمل مع الأنواع القابلة للفارغية

يحل Kotlin مشكلة NullPointerException (NPE)، ولكن فقط إذا لم يسيء المطور استخدام !! (تأكيد عدم الفارغية). هذه هي العلامة الحمراء الرئيسية.

ما نبحث عنه: استخدام !! في كود الإنتاج. يمكن دائمًا استبداله بـ ?.let أو ?: (elvis) أو التحويل الآمن as?.
مثال على كود سيء:

fun processUser(user: User?) {\n    val name = user!!.name // احتمالية حدوث NPE!\n    println(name)\n}

مثال على كود جيد:

fun processUser(user: User?) {\n    user?.let { safeUser ->\n        println(safeUser.name)\n    } ?: run {\n        println("المستخدم فارغ")\n    }\n}

\n\n

1.2. استخدام المجموعات و Stream API

يقدم Kotlin مجموعة غنية من الوظائف للعمل مع المجموعات. تحقق من مدى فعالية وسهولة قراءة استخدامها.

ما نبحث عنه: حلقات for غير ضرورية حيث يمكن استخدام map أو filter أو groupBy. وكذلك المجموعات القابلة للتغيير (MutableList) إذا كان يمكن الاستغناء عنها بمجموعات غير قابلة للتغيير (List).
مثال على كود سيء:

val names = mutableListOf<String>()\nfor (item in items) {\n    if (item.isActive) {\n        names.add(item.name)\n    }\n}

مثال على كود جيد:

val names = items\n    .filter { it.isActive }\n    .map { it.name } // قائمة غير قابلة للتغيير

\n\n

1.3. دوال الامتداد (Extension Functions) ونطاق الرؤية

دوال الامتداد هي أداة قوية، ولكن من السهل "توزيعها" عبر المشروع. تحقق من ملاءمة استخدامها.

ما نبحث عنه: دوال الامتداد التي تغير حالة الكائن (خاصة إذا كان ذلك غير واضح). الدوال التي يجب أن تكون طرقًا للفئة ولكن تم إخراجها كامتداد "للجمال".
سؤال للمؤلف: "لماذا هذا امتداد وليس طريقة للفئة User؟"

\n\n

1.4. استخدام `when` بدلاً من `if-else`

يشجع Kotlin على استخدام when كبديل أكثر قابلية للقراءة لسلاسل if-else الطويلة.

ما نبحث عنه: سلالم من if-else تتكون من 3 شروط أو أكثر. يجب استبدالها بـ when.

// بدلاً من هذا:\nif (status == Status.ACTIVE) { ... } else if (status == Status.PENDING) { ... } else { ... }\n\n// الأفضل هكذا:\nwhen (status) {\n    Status.ACTIVE -> { ... }\n    Status.PENDING -> { ... }\n    else -> { ... }\n}

\n\n