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

परिचय: Go में कोड रिव्यू सिर्फ एक टिक-मार्क क्यों नहीं है

कोड रिव्यू कोई नौकरशाही प्रक्रिया नहीं है, बल्कि डेवलपमेंट संस्कृति का एक प्रमुख तत्व है। Go में, अपने संक्षिप्त सिंटैक्स और सख्त नियमों के साथ, रिव्यू अक्सर पहला फिल्टर बन जाता है जो शुरुआती चरण में समस्याओं को दूर करता है। Golang पर स्विच करने वाली कई टीमों को पता चलता है कि पुरानी आदतें (जैसे Python या PHP से) काम नहीं करतीं: Go टाइप से संबंधित कम गलतियाँ माफ करता है, लेकिन विवरण पर ध्यान देने की आवश्यकता होती है।

व्यवहार में, Go में कोड रिव्यू तीन कार्य करता है: टीम को प्रशिक्षित करना (नए लोग कोडस्टाइल में जल्दी घुलमिल जाते हैं), गुणवत्ता में सुधार (बग और एंटीपैटर्न खोजना) और कोड की एकरूपता (ताकि प्रोजेक्ट "पैचवर्क कंबल" न बने)। आइए देखें कि वास्तव में क्या देखना है और टिप्पणियाँ कैसे तैयार करनी हैं।

1. पहले क्या जाँचें: सिंटैक्स से लेकर त्रुटियों तक

कोई भी रिव्यू बुनियादी चीजों से शुरू होता है। Go में कुछ "हॉट स्पॉट" हैं जिन्हें स्वचालित या मैन्युअल रूप से जाँचना चाहिए।

1.1. त्रुटि प्रबंधन (error handling)

Go अपवादों का उपयोग नहीं करता - त्रुटियाँ मान के रूप में लौटाई जाती हैं। एक सामान्य समस्या: डेवलपर _ के साथ लौटाई गई त्रुटि को अनदेखा करता है। यह केवल दुर्लभ मामलों में स्वीकार्य है (जैसे, fmt.Println)।

// बुरा: त्रुटि को अनदेखा किया गया\nresp, _ := http.Get("https://api.example.com/data")\n\n// अच्छा: त्रुटि को संभाला गया\nresp, err := http.Get("https://api.example.com/data")\nif err != nil {\n    log.Printf("डेटा प्राप्त करने में विफल: %v", err)\n    return err\n}\ndefer resp.Body.Close()

क्या जाँचें:

\n
• क्या सभी त्रुटियाँ संभाली गई हैं (सिर्फ _ नहीं)?
\n
• क्या संसाधनों (फ़ाइलें, कनेक्शन) को बंद करने के लिए defer का उपयोग किया गया है?
\n
• क्या गोरूटीन में त्रुटियाँ "निगल" नहीं ली गई हैं?
\n

1.2. नामकरण और शैली (Go idioms)

Go संक्षिप्तता की मांग करता है: प्राइवेट के लिए camelCase, एक्सपोर्टेबल के लिए PascalCase। "हंगेरियन नोटेशन" और लंबे नामों से बचें।

// बुरा\nfunc GetUserDataFromDatabase(userID int) (*UserData, error)\n\n// अच्छा\nfunc GetUser(id int) (*User, error)

लाल झंडे:

\n
• temp, data, val जैसे वेरिएबल नाम (बहुत सामान्य)।
\n
• 30-40 लाइनों से लंबे फंक्शन (तोड़ने की आवश्यकता है)।
\n
• एक्सपोर्टेड फंक्शन पर टिप्पणियों की कमी (यह golint की आवश्यकता है)।
\n

1.3. गोरूटीन और सिंक्रोनाइज़ेशन

यह सबसे कठिन हिस्सा है। कंकरेंट कोड में त्रुटियाँ प्रोडक्शन में बग का एक सामान्य स्रोत हैं।

// बुरा: डेटा रेस (data race)\nvar counter int\nfor i := 0; i < 100; i++ {\n    go func() {\n        counter++ // असुरक्षित\n    }()\n}\n\n// अच्छा: म्यूटेक्स का उपयोग करें\nvar mu sync.Mutex\nvar counter int\nfor i := 0; i < 100; i++ {\n    go func() {\n        mu.Lock()\n        counter++\n        mu.Unlock()\n    }()\n}

क्या जाँचें:

\n
• क्या साझा डेटा के लिए sync.Mutex या atomic है?
\n
• क्या चैनल बंद करना भूल गए (close(ch))?
\n
• क्या गोरूटीन "लीक" हो रही हैं (टाइमआउट के साथ कोई select नहीं)?
\n

2. आर्किटेक्चरल जाँच: इंटरफ़ेस से पैकेज तक

बुनियादी सिंटैक्स के बाद, कोड की संरचना देखें। Go कंपोज़िशन को प्रोत्साहित करता है, न कि इनहेरिटेंस को।

2.1. इंटरफ़ेस: छोटे और उपभोक्ता की तरफ

Go में, इंटरफ़ेस अंतर्निहित रूप से लागू किए जाते हैं। एक अच्छे इंटरफ़ेस में 1-3 मेथड होते हैं। जाँचें कि क्या लेखक "सर्वव्यापी" इंटरफ़ेस बनाने की कोशिश नहीं कर रहा है।

// बुरा: विशाल इंटरफ़ेस\ntype Storage interface {\n    Save(data []byte) error\n    Load(id string) ([]byte, error)\n    Delete(id string) error\n    List() ([]string, error)\n    Connect() error\