HI
RU
EN
ES
ZH
FR
DE
PT
AR
आपका Go-कोड: "काम करता है" से "स्वीकृत" तक
\n\nआपने Go में कोड लिखा है। यह कंपाइल होता है। टेस्ट ग्रीन हैं। आपको गर्व है। लेकिन फिर सीनियर डेवलपर से code review आता है, और पाँच मिनट में आपका पुल-रिक्वेस्ट लाल टिप्पणियों से ढक जाता है। परिचित लगता है?
\n\nGo एक ऐसी भाषा है जहाँ "सरलता" भ्रामक है। प्रतीत होने वाली आसानी के पीछे दर्जनों छिपे हुए खतरे हैं, जिन्हें अनुभवी आँख तुरंत देख लेती है। इस लेख में हम उन सबसे सामान्य टिप्पणियों पर चर्चा करेंगे जो सीनियर Go कोड की समीक्षा पर छोड़ते हैं। आप न केवल यह जानेंगे कि क्या गलत है, बल्कि यह भी कि कैसे इसे ठीक करें ताकि आपका कोड पहली बार में ही समीक्षा पास कर ले।
\n\nचलिए Golang code review पर सामान्य गलतियों का विश्लेषण शुरू करते हैं।
\n\n1. त्रुटि प्रबंधन: सिर्फ if err != nil नहीं
\n\nसमस्या: त्रुटियों को अनदेखा करना या "खाली" return
\n\nशुरुआती लोगों की सबसे आम समस्या - त्रुटियों का अपर्याप्त जानकारीपूर्ण प्रबंधन। केवल त्रुटि को ऊपर भेजना आधा काम है। सीनियर हमेशा पूछेगा: "क्या गलत हुआ? कहाँ?"।
\n\n// बुरा: सीनियर कहेगा "संदर्भ जोड़ें"\nfunc ReadConfig(path string) (*Config, error) {\n data, err := os.ReadFile(path)\n if err != nil {\n return nil, err // ❌ कोई संदर्भ नहीं\n }\n // ...\n}\nसही तरीका - fmt.Errorf और प्लेसहोल्डर %w का उपयोग करके त्रुटियों को लपेटना (बाद में errors.Is या errors.As के माध्यम से जाँच के लिए)।
// अच्छा: सीनियर सिर हिलाएगा\nfunc ReadConfig(path string) (*Config, error) {\n data, err := os.ReadFile(path)\n if err != nil {\n return nil, fmt.Errorf("read config file %s: %w", path, err) // ✅ संदर्भ + श्रृंखला\n }\n // ...\n}\nसमस्या: बार-बार if err != nil दोहराना
\n\nGo त्रुटि प्रबंधन में अपनी शब्दाडंबर के लिए जाना जाता है। लेकिन इसका मतलब यह नहीं है कि आपको कॉपी-पेस्ट को सहन करना चाहिए। सीनियर बार-बार होने वाली जाँचों को हेल्पर्स में निकालने या गोरूटीन के लिए "errgroup" पैटर्न का उपयोग करने का सुझाव देगा।
\n\n- \n
- ऐसा न करें: एक फंक्शन में लगातार 10 बार
if err != nil { return ... }लिखना सामान्य है, लेकिन अगर पैटर्न अलग-अलग फंक्शन में दोहराया जाता है - तो रिफैक्टर करने का समय आ गया है। \n - सीनियर की सलाह: संसाधनों को बंद करने और बंद करने की त्रुटियों की जाँच के लिए
deferका उपयोग करें (हाँ,file.Close()भी एक त्रुटि लौटाता है)। \n
2. समवर्तीता: डेटा रेस और गलत चैनल
\n\nसमस्या: बिना सिंक्रोनाइज़ेशन के shared-वेरिएबल तक पहुँच
\n\nGo एक ऐसी भाषा है जहाँ गोरूटीन सस्ती हैं, और डेटा रेस महँगी हैं। सीनियर तुरंत देख लेगा यदि आप बिना म्यूटेक्स के कई गोरूटीन से map या slice में लिख रहे हैं।
\n\n// बुरा: data race\nvar counter int\nfor i := 0; i < 100; i++ {\n go func() {\n counter++ // ❌ रेस!\n }()\n}\nसमाधान: sync.Mutex या एटॉमिक्स का उपयोग करें। लेकिन सीनियर कहेगा: "क्या चैनल का उपयोग करना आसान नहीं होगा?"।
// अच्छा: सिंक्रोनाइज़ेशन के लिए चैनल\nch := make(chan int, 100)\nfor i := 0; i < 100; i++ {\n go func() {\n ch <- 1\n }()\n}\nvar counter int\nfor i := 0; i < 100; i++ {\n counter += <-ch // ✅ बिना रेस के\n}\nसमस्या: गोरूटीन लीक
\n\nचैनल बंद करना भूल गए? गोरूटीन हमेशा के लिए अटक गई। सीनियर Go कोड की समीक्षा पर निश्चित रूप से जाँच करेगा कि क्या आपकी गोरूटीन ctx.Done() के साथ select के बिना "अटकी" हुई है।
// बुरा: गोरूटीन हमेशा के लिए अटक सकती है\ngo func() {\n for msg := range ch {\n process(msg)\n }\n}()\n// यदि ch कभी बंद नहीं होता - मेमोरी लीक\nसही पैटर्न - हमेशा context.Context पास करें और रद्दीकरण सिग्नल सुनें।
// अच्छा: लीक से सुरक्षा\ngo func(ctx context.Context) {\n for {\n select {\n case msg, ok := <-ch:\n if !ok {\n return // चैनल बंद\n }\n process(m 
