बहु-क्षेत्रीय सॉफ्टवेयर विकास पर | मूल, AI द्वारा अनुवादित
अंतर्राष्ट्रीय कंपनियों के लिए अक्सर ऐसे प्रोजेक्ट होते हैं जो कई क्षेत्रों के लोगों को सेवा देते हैं, जैसे सिंगापुर, हांगकांग, यूके, यूएसए और चीन।
मैंने कुछ प्रोजेक्ट्स पर काम किया है जो कई क्षेत्रों के उपयोगकर्ताओं की सेवा करते हैं। बैकएंड प्रोजेक्ट्स में इसे सही ढंग से करना आसान नहीं होता।
स्टैंडर्ड चार्टर्ड बैंक के लिए, जैसे एप्स हैं SC मोबाइल इंडिया और SC मोबाइल हांगकांग। मैकडॉनल्ड्स के लिए, जैसे मैकडॉनल्ड्स चीन और मैकडॉनल्ड्स यूएसए। स्टारबक्स के लिए, स्टारबक्स यूएसए और स्टारबक्स चीन। मूल रूप से, वे अलग-अलग देशों को उनके अपने एप्स प्रदान करते हैं। अक्सर, चीन के उपयोगकर्ताओं और अंतर्राष्ट्रीय उपयोगकर्ताओं के लिए लॉगिन विधियाँ अलग होती हैं। मोबाइल फोन के अलावा, चीनी उपयोगकर्ताओं के पास अक्सर वीचैट के साथ लॉगिन करने का विकल्प होता है, जबकि अंतर्राष्ट्रीय उपयोगकर्ता फेसबुक, गूगल या एप्पल के साथ लॉगिन कर सकते हैं।
इन एप्स में संभवतः अलग-अलग बैकएंड सर्वर होते हैं और कुछ अलग-अलग फीचर्स होते हैं, लेकिन वे उसी डिजाइन भाषा को बनाए रखते हैं। शायद ऐसा करना गलत है। पहले वर्षों में, यह सरल या संभव लग सकता है। लेकिन एक दशक बाद, वे जानेंगे कि यह बहुत दर्दनाक है। रखरखाव की लागत या सिंक्रनाइजेशन की लागत, टेस्टिंग की लागत—बहुत सारे डुप्लिकेट प्रयास होते हैं।
हालांकि, फेसबुक, गूगल या एप्पल पे के लिए यह कुछ हद तक सरल है। कोई कह सकता है कि वे वित्तीय एप्स नहीं हैं; उनके कुछ नियमों का पालन करना पड़ता है। यह सच नहीं है। नियमों का मतलब अक्सर डेटाबेस सर्वर, या डेटाबेस, या कुछ डेटा होता है जिसे सरकारी विभागों द्वारा जांचा जाना चाहिए या ऑडिट कंपनियों द्वारा ऑडिट किया जाना चाहिए। हालांकि, अन्य प्रयास वही होते हैं। सॉफ्टवेयर बहुत लचीला होता है। हमें कोड को एक ही रिपॉजिटरी में रखना चाहिए, हमें डेटा स्रोत कॉन्फ़िगरेशन का उपयोग करके अलग-अलग क्षेत्रों के डेटा होस्ट करना चाहिए, और हमें उतना ही संभव हो सके उतना ही समान कोड, समान डिजाइन, समान वर्कफ्लो और समान टेस्टिंग साझा करना चाहिए।
एप्पल पे एक अच्छा उदाहरण है। एप स्टोर भी एक अच्छा उदाहरण है। वे हर देश की सेवा करते हैं।
शायद बड़े टेक कंपनियों में कुछ प्रोजेक्ट्स होते हैं जो महाद्वीपों को अलग करते हैं, जैसे एशिया और प्रशांत क्षेत्र, उत्तर अमेरिका। इनके लिए भी।
मल्टी-रिजन डेवलपमेंट करने का पहला काम यह जानना है कि क्या अलग है, क्या नियम हैं जिन्हें हमें मानना होगा, और डुप्लिकेट प्रयासों को कम से कम करने का तरीका।
टेक्स्ट-टू-स्पीच के लिए, गूगल क्लाउड को अलग-अलग भाषाओं को ट्रेन करना पड़ता है। वे इसके लिए अलग-अलग मॉडल और अलग-अलग भाषाएँ प्रदान करते हैं। भाषाओं के लिए, भाषाओं के बीच अंतर उनकी ध्वनियाँ और उनके वर्णों का दिखावट है। पहले का मतलब है कि जब गूगल क्लाउड का उपयोग टेक्स्ट-टू-स्पीच करने के लिए किया जाता है, तो हमें अलग-अलग मॉडल का उपयोग करना पड़ता है। उनके वर्णों के दिखावट का मतलब है कि जब पीडीएफ जनरेशन किया जाता है, तो हमें इसके फॉन्ट चयन के बारे में सावधान रहना चाहिए।
मल्टी-रिजन प्रोजेक्ट्स के लिए, स्प्रिंग बूट प्रोजेक्ट्स में, हम उसके एलीस और अलग-अलग ऑब्जेक्ट इनिशियलाइजेशन का उपयोग कर सकते हैं। हम स्मार्ट तरीके से प्रॉपर्टी या YAML कॉन्फ़िगरेशन का उपयोग कर सकते हैं। हम सभी अलग-अलग लॉजिक को क्षेत्र के आधार पर कुछ विशिष्ट मॉड्यूल या क्लासों में रख सकते हैं।
और कोड होस्टिंग के लिए, अलग-अलग देशों के लिए अलग-अलग ब्रांचेस लगते हैं, लेकिन कुछ वर्षों बाद आप जान जाएंगे कि यह कितना दर्दनाक है। आपको अन्य क्षेत्रों के लिए गिट चेरी-पिक करना होगा। और आपको दूसरे ब्रांच में फिर से टेस्ट करना होगा। हर छोटे बदलाव के लिए, आपको ब्रांचेस में सिंक्रनाइजेशन करना होगा। और समय के साथ, अगर हम अपनी कोशिश को कोड या लॉजिक के अंतर को कम करने में नहीं लगाते हैं, तो कई क्षेत्रों या देशों के बीच कोड के अंतर इतना बड़े हो जाते हैं कि उन्हें ठीक नहीं किया जा सकता।
अच्छी खबर यह है कि अब AI हमारी मदद कर सकता है कोड को रीफैक्टर करने या बेहतर कोड लिखने में, या मल्टी-रिजन कोड डिजाइन समस्याओं को ठीक करने में। चाहे गलती कितनी भी बड़ी हो, जब हम इसे ठीक करते हैं, तो यह एक छोटी गलती होती है।
कोडिंग, डिप्लॉयमेंट और रिलीज रखरखाव के अलावा, एक्सटेंसिबिलिटी के लिए भी। सोचें कि एक नया देश या क्षेत्र जोड़ने में कितनी मेहनत लगेगी। अगर यह न्यूनतम हो या सिर्फ कुछ कॉन्फ़िगरेशन शामिल हो, तो हमारा डिजाइन बहुत अच्छा है। अगर यह कुछ महीनों का समय लेता है, तो यह भी स्वीकार्य है। अगर यह कई साल लेता है, तो क्या हम इसे आगे बढ़ाएंगे?
यिन वांग के निबंध में, ऑन लिनक्स, विंडोज़ और मैक, उन्होंने उल्लेख किया है कि एक एडोब डिजाइनर ने उन्हें बताया कि उन्होंने फोटोशॉप को विंडोज़ से मैकओएस में माइग्रेट करने में दो साल लगाए।
क्या एक नए क्षेत्र का समर्थन करने में दो साल का अनुकूलन लगेगा? कुछ प्रोजेक्ट्स के लिए, संभव है। यह एक महत्वपूर्ण डिजाइन विचार है।
दुनिया अधिक जुड़ी हुई हो रही है। चाहे हम किसी भी देश या क्षेत्र को शुरू में टारगेट करें, हमें अन्य क्षेत्रों का भी विचार करना चाहिए। शुरू से ही इसे सही करना बेहतर है। स्थापित अंतर्राष्ट्रीय कंपनियों के लिए, यह सलाह दी जाती है कि वे कम से कम दो देशों या क्षेत्रों के लिए सॉफ्टवेयर उत्पादों का विकास शुरू से ही करें। शुरू से ही इस मल्टी-रिजन मानसिकता को बनाए रखें। अगर हमारे पास अधिक इंजीनियरिंग संसाधन हैं, तो हम अधिक देशों या क्षेत्रों का समर्थन कर सकते हैं।