कोटलिन में कोड रिव्यू: क्या जाँचें और फीडबैक कैसे दें

कोटलिन में कोड रिव्यू: क्या जाँचें और फीडबैक कैसे दें

Code review केवल एक औपचारिकता या बग खोजने का तरीका नहीं है। यह ज्ञान साझा करने और कोड की गुणवत्ता बढ़ाने की एक महत्वपूर्ण प्रक्रिया है। कोटलिन में, इसके अभिव्यंजक सिंटैक्स और शक्तिशाली सुविधाओं के साथ, रिव्यू में विवरणों पर विशेष ध्यान देने की आवश्यकता होती है। इस लेख में, हम चर्चा करेंगे कि कोटलिन कोड की जाँच करते समय किन बातों पर ध्यान देना चाहिए और फीडबैक कैसे दें ताकि वह उपयोगी हो, न कि आपत्तिजनक।

1. क्या जाँचें: कोटलिन डेवलपर के लिए चेकलिस्ट

रिव्यू शुरू करते समय, एक साथ सब कुछ कवर करने का प्रयास न करें। बेहतर होगा कि प्रमुख श्रेणियों पर ध्यान केंद्रित करें। यहाँ कोटलिन के लिए एक संरचित चेकलिस्ट है।

1.1. Null Safety और nullable प्रकारों के साथ काम करना

Kotlin NPE समस्या को हल करता है, लेकिन केवल तब जब डेवलपर !! (not-null assertion) का दुरुपयोग न करे। यह मुख्य लाल झंडा है।

\n
• क्या देखें: Production कोड में !! का उपयोग। लगभग हमेशा इसे ?.let, ?: (elvis) या सुरक्षित कास्ट as? से बदला जा सकता है।
\n
• खराब कोड का उदाहरण:
\n

fun processUser(user: User?) {\n    val name = user!!.name // संभावित NPE!\n    println(name)\n}

\n
• अच्छे कोड का उदाहरण:
\n

fun processUser(user: User?) {\n    user?.let { safeUser ->\n        println(safeUser.name)\n    } ?: run {\n        println("User is null")\n    }\n}

1.2. कलेक्शन और Stream API का उपयोग

Kotlin कलेक्शन के साथ काम करने के लिए समृद्ध फंक्शन प्रदान करता है। जाँचें कि वे कितने कुशलतापूर्वक और पठनीय रूप से उपयोग किए गए हैं।

\n
• क्या देखें: अनावश्यक for लूप जहाँ map, filter, groupBy का उपयोग किया जा सकता है। साथ ही mutable कलेक्शन (MutableList) जब immutable (List) से काम चल सकता है।
\n
• खराब कोड का उदाहरण:
\n

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

\n
• अच्छे कोड का उदाहरण:
\n

val names = items\n    .filter { it.isActive }\n    .map { it.name } // Immutable सूची

1.3. Extension-फंक्शन और दृश्यता का दायरा

Extension-फंक्शन एक शक्तिशाली उपकरण है, लेकिन इन्हें प्रोजेक्ट में बिखेरना आसान है। जाँचें कि उनका उपयोग उचित है या नहीं।

\n
• क्या देखें: Extension-फंक्शन जो ऑब्जेक्ट की स्थिति बदलते हैं (खासकर यदि यह स्पष्ट न हो)। फंक्शन जो क्लास के मेथड होने चाहिए, लेकिन "सुंदरता" के लिए extension में रखे गए हैं।
\n
• लेखक से प्रश्न: "यह extension क्यों है, न कि User क्लास का मेथड?"
\n

1.4. if-else के बजाय when का उपयोग

Kotlin लंबी if-else श्रृंखलाओं के अधिक पठनीय विकल्प के रूप में when के उपयोग को प्रोत्साहित करता है।

\n
• क्या देखें: 3+ शर्तों वाली if-else सीढ़ियाँ। इन्हें when से बदलना चाहिए।
\n

// इसके बजाय:\nif (status == Status.ACTIVE) { ... } else if (status == Status.PENDING) { ... } else { ... }\n\n// बेहतर तरीका:\nwhen (status) {\n    Status.ACTIVE -> { ... }\n    Status.PENDING -> { ... }\n    else -> { ... }\n}

2. फीडबैक कैसे दें: आलोचना से सहयोग तक

तकनीकी भाग केवल आधा काम है। दूसरा आधा भाग संचार है। खराब फीडबैक टीम को हतोत्साहित कर सकता है। अच्छा फीडबैक विश्वास को मजबूत कर सकता है।

2.1. "क्यों, न कि क्या" का नियम

बस यह कहने के बजाय "यह खराब है", समझाएँ कि यह क्यों खराब है और इसे कैसे ठीक करें।

\n
• खराब: "यहाँ !! है — इसे बदलो