Swift Code Review: 10 चीज़ें जो मैं पहले जाँचता हूँ

Swift में Code Review सिर्फ़ नुक्स निकालना नहीं है

एक स्थिति की कल्पना करें: आप अपने सहकर्मी का पुल-रिक्वेस्ट खोलते हैं, 500 लाइनों का Swift कोड देखते हैं और पाते हैं कि 20 मिनट में डेली मीटिंग शुरू होने वाली है। परिचित लग रहा है? Code review (या कोड-रिव्यू) यह प्रतियोगिता नहीं है कि "कौन ज़्यादा टाइपो ढूँढ़ेगा"। यह प्रोडक्शन में बग्स को रोकने, आर्किटेक्चर को बेहतर बनाने और टीम को ज्ञान देने का आपका मौक़ा है।

इस लेख में मैंने Swift के लिए एक code review चेकलिस्ट इकट्ठा की है जिसका उपयोग मैं स्वयं करता हूँ। कोई बेकार की बात नहीं — केवल ठोस जाँचें, कोड उदाहरण और स्पष्टीकरण कि यह क्यों महत्वपूर्ण है। भले ही आप Python में लिखते हों, लेकिन iOS डेवलपमेंट की दुनिया में झाँकते हों — यह सामग्री आपके लिए उपयोगी होगी।

1. मेमोरी सुरक्षा और ऑप्शनल टाइप्स

Swift अपनी मेमोरी सुरक्षा पर गर्व करता है, लेकिन इसका मतलब यह नहीं है कि आप ढीले हो सकते हैं। सबसे आम समस्या है force unwrapping। हर विस्मयादिबोधक चिह्न एक संभावित क्रैश है।

क्या जाँचें:

\n
• Force unwrap (!) — केवल टेस्ट में या जब आपको मान पर 100% भरोसा हो, स्वीकार्य है। प्रोडक्शन कोड में — यह एक रेड फ्लैग है।
\n
• IUO (Implicitly Unwrapped Optionals) — इनका उपयोग केवल IBOutlet या उन प्रॉपर्टीज़ के लिए करें जो init के बाद, लेकिन पहले उपयोग से पहले इनिशियलाइज़ होती हैं।
\n
• Retain cycles — क्लोज़र्स में [weak self] या [unowned self] की जाँच करें।
\n

// बुरा: बिना जाँच के force unwrap\nlet url = URL(string: "https://pythonlib.ru")! // क्रैश अगर स्ट्रिंग अमान्य है\n\n// अच्छा: guard let\nguard let url = URL(string: "https://pythonlib.ru") else {\n    print("अमान्य URL")\n    return\n}\n\n// क्लोज़र में retain cycle की जाँच\nclass NetworkManager {\n    var completionHandler: (() -> Void)?\n    \n    func fetchData() {\n        completionHandler = { [weak self] in\n            guard let self = self else { return }\n            self.updateUI() // self अब कमज़ोर संदर्भ है\n        }\n    }\n    \n    func updateUI() { /* ... */ }\n}\n

Code review के लिए सुझाव: अगर आप ! देखते हैं — पूछें "यहाँ guard या if let क्यों नहीं है?"। यह कई क्रैश से बचाएगा।

2. एरर हैंडलिंग: एक्सेप्शन को न निगलें

Swift एक शक्तिशाली do-catch तंत्र देता है, लेकिन डेवलपर्स अक्सर इसे अनदेखा करते हैं। एक सामान्य एंटी-पैटर्न है try! या खाली catch।

क्या जाँचें:

\n
• try! — लगभग हमेशा बुरा। केवल तभी जब आप टेस्ट लिख रहे हों।
\n
• खाली catch {} — आप एरर के बारे में जानकारी खो रहे हैं। कम से कम इसे लॉग करें।
\n
• एरर को ऊपर भेजना (throws) — फ़ंक्शन को या तो एरर को हैंडल करना चाहिए या स्पष्ट रूप से इसे आगे भेजना चाहिए।
\n

// बुरा: एरर को निगलना\ndo {\n    let data = try fetchData()\n} catch {\n    // कुछ नहीं करते — एरर खो गया\n}\n\n// अच्छा: लॉग करें और उपयोगकर्ता को दिखाएँ\ndo {\n    let data = try fetchData()\n    updateUI(with: data)\n} catch let error as NetworkError {\n    showAlert(message: error.localizedDescription)\n} catch {\n    print("अज्ञात एरर: \\(error.localizedDescription)")\n    showGenericError()\n}\n

Swift के लिए code review में हमेशा जाँचें कि Error को केवल अनदेखा नहीं किया गया है। उपयोगकर्ता को समझना चाहिए कि क्या गलत हुआ।

3. आर्किटेक्चर: MVC, MVVM या VIPER?

इससे कोई फर्क नहीं पड़ता कि आपने कौन सा पैटर्न चुना है — महत्वपूर्ण यह है कि कोड उसका पालन करे। Code review में आप देखते हैं कि क्या ViewController "God Object" (एक क्लास जो सब कुछ करता है) में नहीं बदल गया है।

क्या जाँचें:

\n
• फ़ाइल का आकार — अगर एक फ़ाइल में 300-400 से अधिक लाइनें हैं, तो यह विभाजन के बारे में सोचने का कारण है।
\n
• क्लासेज़ की ज़िम्मेदारी — ViewController को नेटवर्क कॉल नहीं करनी चाहिए या JSON पार्स नहीं करना चाहिए। इसके लिए सर्विसेज़ और मैनेजर हैं।
\n
• डेटा फ़्लो — क्या डेटा सही दिशा में जा रहा है? क्या व्यू और मॉडल के बीच स्पष्ट अलगाव है?
\n

// बुरा: ViewController में सब कुछ\nclass UserViewController: UIViewController {\n    @IBOutlet weak var tableView: UITableView!\n    var users: [User] = []\n    \n    override func viewDidLoad() {\n        super.viewDidLoad()\n        // नेटवर्क कॉल सीधे यहाँ\n        URLSession.shared.dataTask(with: URL(string: "https://api.example.com/users")!) { data, response, error in\n            // JSON पार्सिंग यहाँ\n            // UI अपडेट यहाँ\n        }.resume()\n    }\n}\n\n// अच्छा: ज़िम्मेदारियाँ अलग\nclass UserViewModel {\n    func fetchUsers(completion: @escaping ([User]) -> Void) {\n        // नेटवर्क कॉल और पार्सिंग यहाँ\n    }\n}\n\nclass UserViewController: UIViewController {\n    let viewModel = UserViewModel()\n    \n    override func viewDidLoad() {\n        super.viewDidLoad()\n        viewModel.fetchUsers { [weak self] users in\n            self?.updateUI(with: users)\n        }\n    }\n    \n    func updateUI(with users: [User]) { /* ... */ }\n}\n

Code review के लिए सुझाव: अगर आप देखते हैं कि एक क्लास बहुत अधिक काम कर रही है, तो पूछें "क्या यहाँ SRP (Single Responsibility Principle) का उल्लंघन हो रहा है?"।

4. परफॉरमेंस: मेमोरी लीक और अनावश्यक काम

iOS ऐप्स में परफॉरमेंस महत्वपूर्ण है। Code review के दौरान, संभावित मेमोरी लीक और अनावश्यक गणनाओं पर ध्यान दें।

क्या जाँचें:

\n
• मेमोरी लीक — क्या डीइनिशियलाइज़ेशन सही है? क्या डेलिगेट कमज़ोर संदर्भ हैं?
\n
• अनावश्यक कॉपी — क्या बड़े डेटा स्ट्रक्चर को वैल्यू टाइप के रूप में पास किया जा रहा है? कभी-कभी inout या रेफरेंस टाइप बेहतर होता है।
\n
• मेन थ्रेड पर भारी काम — क्या नेटवर्क कॉल या फ़ाइल I/O बैकग्राउंड थ्रेड पर किया जा रहा है?
\n

// बुरा: मेन थ्रेड पर भारी काम\nDispatchQueue.main.async {\n    let data = try! Data(contentsOf: url) // UI फ़्रीज़\n    self.updateUI(with: data)\n}\n\n// अच्छा: बैकग्राउंड थ्रेड पर काम\nDispatchQueue.global(qos: .background).async { [weak self] in\n    guard let data = try? Data(contentsOf: url) else { return }\n    DispatchQueue.main.async {\n        self?.updateUI(with: data)\n    }\n}\n

Code review के लिए सुझाव: हमेशा जाँचें कि भारी ऑपरेशन मेन थ्रेड को ब्लॉक नहीं कर रहे हैं। इंस्ट्रूमेंट्स टूल का उपयोग करें — यह मेमोरी लीक को पकड़ने में मदद करता है।

5. कोड स्टाइल और नामकरण

Swift में एक स्पष्ट कोड स्टाइल है। यदि टीम इसका पालन नहीं करती है, तो कोड को पढ़ना और बनाए रखना मुश्किल हो जाता है।

क्या जाँचें:

\n
• नामकरण — क्या वेरिएबल और फ़ंक्शन के नाम उनके उद्देश्य को दर्शाते हैं? camelCase का उपयोग करें।
\n
• इंडेंटेशन और फ़ॉर्मेटिंग — क्या कोड सुसंगत दिखता है? SwiftLint का उपयोग करें।
\n
• अनावश्यक कोड — क्या कोई मृत कोड, टिप्पणी किया गया कोड या अनावश्यक आयात हैं?
\n

// बुरा: अस्पष्ट नाम\nfunc a(b: Int) -> String {\n    return "\\(b)"\n}\n\n// अच्छा: स्पष्ट नाम\nfunc formatNumber(_ number: Int) -> String {\n    return "\\(number)"\n}\n

Code review के लिए सुझाव: कोड स्टाइल पर बहस न करें — एक टीम स्टाइल गाइड सेट करें और स्वचालित टूल (SwiftLint) का उपयोग करें।

निष्कर्ष

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

क्या आपके पास Swift code review के लिए अपनी पसंदीदा जाँचें हैं? टिप्पणियों में साझा करें!