एंटरप्राइज Go: ऐसा कोड कैसे लिखें जो CTO को दिखाने में शर्म न आए

बड़े व्यवसाय में Go: यह अब सिर्फ "माइक्रोसर्विसेज की भाषा" क्यों नहीं रही

जब आप "Enterprise Go" सुनते हैं, तो आपके दिमाग में क्या आता है? उबाऊ कॉर्पोरेट नियम? अंतहीन code review? या शायद यह अहसास कि Go केवल स्टार्टअप और DevOps के लिए है?

वास्तव में, एंटरप्राइज में Go अनुशासन और इंजीनियरिंग संस्कृति का बिल्कुल अलग स्तर है। बड़ी कंपनियों (Uber, Dropbox, Salesforce, Twitch) में Go पर सिर्फ माइक्रोसर्विसेज ही नहीं, बल्कि पूरे प्लेटफॉर्म लिखे जाते हैं जो प्रति सेकंड लाखों रिक्वेस्ट प्रोसेस करते हैं। और यहाँ "बस काम करता है" पर्याप्त नहीं है।

इस लेख में हम एंटरप्राइज में Go डेवलपमेंट की प्रमुख विशेषताओं पर चर्चा करेंगे: पैकेज डिज़ाइन से लेकर production-लॉगिंग तक। बहुत सारा कोड होगा और न्यूनतम बेकार बातें।

1. आर्किटेक्चर: "माइक्रोसर्विसेज में मोनोलिथ" की गलती न दोहराएं

सबसे आम समस्या जो मैं एंटरप्राइज-स्तर के Go प्रोजेक्ट्स में देखता हूँ, वह है Java-style आर्किटेक्चर को Go पर लागू करने का प्रयास। परिणाम: सैकड़ों अनावश्यक इंटरफेस और एब्स्ट्रैक्शन की परतें जो केवल डेवलपमेंट को धीमा करती हैं।

नियम "लेयर के बजाय फीचर के अनुसार पैकेज"

/models, /handlers, /services फोल्डर बनाने के बजाय, बिजनेस डोमेन के अनुसार ग्रुप करें:

myapp/\n├── cmd/\n│   └── server/\n│       └── main.go\n├── internal/\n│   ├── user/          # उपयोगकर्ताओं से संबंधित सब कुछ\n│   │   ├── handler.go\n│   │   ├── service.go\n│   │   ├── repository.go\n│   │   └── user.go    # डेटा मॉडल\n│   ├── payment/       # भुगतान से संबंधित सब कुछ\n│   │   ├── handler.go\n│   │   ├── service.go\n│   │   ├── gateway.go\n│   │   └── payment.go\n│   └── pkg/           # सामान्य उपयोगिताएँ\n└── go.mod

यह दृष्टिकोण एंटरप्राइज के लिए Go best practices में से एक है। यह कपलिंग को कम करता है और कोड को पूर्वानुमानित बनाता है। जब कोई नया डेवलपर प्रोजेक्ट खोलता है, तो उसे तुरंत बिजनेस लॉजिक दिखता है, एब्स्ट्रैक्शन की परतें नहीं।

इंटरफेस: इंटरफेस स्वीकार करें, स्ट्रक्चर लौटाएं

यह Go समुदाय की एक क्लासिक सलाह है, लेकिन एंटरप्राइज में यह महत्वपूर्ण है। इंटरफेस छोटे (1-2 मेथड) होने चाहिए और उन्हें वहाँ परिभाषित किया जाना चाहिए जहाँ उनका उपयोग किया जाता है, न कि जहाँ उन्हें लागू किया जाता है।

// खराब: इंटरफेस कार्यान्वयन के पास परिभाषित किया गया है\npackage user\n\ntype UserRepository interface {\n    FindByID(id string) (*User, error)\n    Save(user *User) error\n}\n\ntype postgresRepo struct { ... }\n\n// अच्छा: इंटरफेस वहाँ जहाँ इसकी आवश्यकता है\npackage user\n\ntype Storage interface {\n    Get(id string) (*User, error)\n    Put(user *User) error\n}\n\ntype service struct {\n    db Storage\n}\n\nfunc NewService(db Storage) *service {\n    return &service{db: db}\n}

यह क्यों महत्वपूर्ण है? क्योंकि एंटरप्राइज में आप अक्सर बैकएंड बदलते हैं (PostgreSQL -> CockroachDB, Redis -> KeyDB)। उपभोक्ता पक्ष पर परिभाषित इंटरफेस आपको बिना दर्द के ऐसा करने की अनुमति देते हैं।

2. एरर हैंडलिंग: _ को अनदेखा करना बंद करें

Go में एक्सेप्शन नहीं हैं, और यह बहुत अच्छा है। लेकिन एंटरप्राइज प्रोजेक्ट्स में, एरर सिर्फ if err != nil नहीं हैं। यह एक पूरी संस्कृति है।

Wrap करें या न करें?

एरर चेन बनाने के लिए fmt.Errorf का %w के साथ उपयोग करें। यह कॉल स्टैक को संरक्षित करता है और डिबगिंग को सरल बनाता है।

func (s *service) ProcessOrder(ctx context.Context, orderID string) error {\n    order, err := s.orderRepo.Get(ctx, orderID)\n    if err != nil {\n        return fmt.Errorf("getting order %s: %w", orderID, err)\n    }\n\n    if err := s.paymentGateway.Charge(ctx, order.Amount); err != nil {\n        return fmt.Errorf("charging for order %s: %w", orderID, err)\n    }\n\n    return nil\n}

शीर्ष स्तर पर (handler/middleware में) एरर प्रकारों की जाँच के लिए errors.Is() और errors.As() का उपयोग करें:

if errors.Is(err, ErrNotFo