Kotlin में कोड रिव्यू: क्या जाँचें और शुरुआती लोगों को फीडबैक कैसे दें

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

Code review (कोड रिव्यू) सिर्फ एक औपचारिकता नहीं है, बल्कि प्रोजेक्ट की गुणवत्ता और टीम के विकास को बढ़ाने का एक शक्तिशाली उपकरण है। Kotlin में शुरुआती डेवलपर्स के लिए, रिव्यू प्रक्रिया अक्सर डर पैदा करती है: "कहीं मैं कोई बग तो नहीं छोड़ दूंगा?", "मैं सहकर्मी को कैसे बताऊं कि उसका कोड खराब है?"। इस लेख में, हम चर्चा करेंगे कि Kotlin कोड की जाँच करते समय किन बातों पर ध्यान देना चाहिए और टिप्पणियाँ कैसे तैयार करें ताकि वे उपयोगी हों, न कि आपत्तिजनक।

हम आपको सिंटैक्स की मूल बातें नहीं सिखाएंगे - यह माना जाता है कि आप पहले से ही Kotlin में लिख रहे हैं। इसके बजाय, हम शुरुआती लोगों के कोड में पाई जाने वाली सामान्य समस्याओं और फीडबैक देने के तरीके पर ध्यान केंद्रित करेंगे, बिना कर्म को खराब किए।

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

Kotlin को अपनी टाइप सिस्टम पर गर्व है, जो कंपाइलेशन के समय अधिकांश NullPointerException को समाप्त कर देती है। हालांकि, शुरुआती लोग अक्सर !! (not-null assertion) ऑपरेटर का दुरुपयोग करते हैं या nullable-मानों को गलत तरीके से संभालते हैं।

क्या जाँचें:

\n
• क्या !! का उपयोग बिना किसी वैध कारण के किया जा रहा है? यदि आप something!! देखते हैं, तो लेखक से पूछें: "आपको यकीन क्यों है कि यहाँ null नहीं होगा? क्या ?.let या ?: का उपयोग करना बेहतर होगा?"।
\n
• क्या ?. के माध्यम से कॉल की चेन सही ढंग से संभाली जा रही है? उदाहरण के लिए, user?.address?.city सुरक्षित है, लेकिन यदि city की आवश्यकता है, तो डिफ़ॉल्ट मान के लिए ?: का उपयोग करना बेहतर है।
\n
• क्या lateinit var का उपयोग करने से पहले इसे इनिशियलाइज़ करना भूल गए हैं? जाँचें कि सभी lateinit फ़ील्ड पहली बार पढ़ने से पहले निश्चित रूप से इनिशियलाइज़ हो जाएंगे।
\n

// खराब\nfun getUserCity(user: User?): String {\n    return user!!.address!!.city // NPE का जोखिम\n}\n\n// अच्छा\nfun getUserCitySafe(user: User?): String {\n    return user?.address?.city ?: "Unknown"\n}\n

फीडबैक कैसे दें: "आपने खराब कोड लिखा है" कहने के बजाय कहें: "यहाँ null हो सकता है, आइए !! को सुरक्षित कॉल से बदलें ताकि रनटाइम पर क्रैश से बचा जा सके"। एक विकल्प सुझाएं - यह सिखाता है, आलोचना नहीं करता।

2. Kotlin की मुहावरेदारता: कलेक्शन, scope-फ़ंक्शन और sealed class

Kotlin सिर्फ "अलग सिंटैक्स वाला Java" नहीं है। कई शुरुआती लोग Kotlin में ऐसे लिखते हैं जैसे वे अभी भी Java में काम कर रहे हों: कलेक्शन फ़ंक्शन के बजाय for लूप का उपयोग करते हैं, apply, let, run के बारे में भूल जाते हैं, और स्थितियों को प्रस्तुत करने के लिए sealed class का उपयोग नहीं करते हैं।

क्या जाँचें:

\n
• क्या मैन्युअल लूप के बजाय कलेक्शन फ़ंक्शन (map, filter, firstOrNull) का उपयोग किया जा रहा है? यह कोड को अधिक संक्षिप्त और पठनीय बनाता है।
\n
• क्या कोई अनावश्यक अस्थायी वेरिएबल हैं? उदाहरण के लिए, val result = list.filter { ... }.map { ... } म्यूटेबल लिस्ट के साथ तीन चरणों में विभाजित करने से बेहतर है।
\n
• क्या उन पदानुक्रमों के लिए sealed class का उपयोग किया जा रहा है जहाँ सभी विकल्पों को संभालने की आवश्यकता है (जैसे, Result, UiState)? आधुनिक Kotlin प्रोजेक्ट्स में यह एक अनिवार्य आवश्यकता है।
\n

// खराब (Java-शैली)\nfun getEvenSquares(list: List<Int>): List<Int> {\n    val result = mutableListOf<Int>()\n    for (i in list.indices) {\n        if (list[i] % 2 == 0) {\n            result.add(list[i] * list[i])\n        }\n    }\n    return result\n}\n\n// अच्छा (Kotlin-मुहावरेदार)\nfun getEvenSquaresIdiomatic(list: List<Int>): List<Int> {\n    return list.filter { it % 2 == 0 }.map { it * it }\n}\n

फीडबैक कैसे दें: एक विशिष्ट मुहावरे की ओर इशारा करें: "for लूप के बजाय, आप filter + map का उपयोग कर सकते हैं, यह छोटा और स्पष्ट है। क्या आप चाहते हैं कि मैं एक उदाहरण दिखाऊं?"। थोपें नहीं - चर्चा का प्रस्ताव रखें।

3. आर्किटेक्चर और परीक्षण योग्यता

भले ही प्रोजेक्ट छोटा हो, code review जाँचने का एक शानदार अवसर है